!ZmUSesoOjmVsKbzFbp:nixos.org

Nix Emacs

747 Members
All things Nix/Emacs! https://github.com/nix-community/emacs-overlay | For Doom Emacs: https://matrix.to/#/#doom-emacs:nixos.org170 Servers

Load older messages


SenderMessageTime
20 May 2024
@gekoke:envs.netgekokeit's what nixpkgs' emacs tooling does under the hood to load dependencies into emacs - you can browse any emacs package's Nix output directory and see what's going on02:57:35
@gekoke:envs.netgekoke
In reply to @gekoke:envs.net
I played around with writing a derivation that outputs a .el script based on your package dependencies that you can eval to add paths to your load path a few days ago
which would make it so you can develop the package in your own environment, whilst still having it be sourced from Nix code
02:58:29
@gekoke:envs.netgekoke* maybe create a Nix package for your package and then use `pkgs.emacsWithPackages`?02:58:40
@bestlem:matrix.orgbestlemOn a similar thing is there a way of loading non emacs packages so that they are only on the path for emacs e.g. not using home.packages = []08:09:40
@bestlem:matrix.orgbestlemThe complication is that I am on macOS and so use exec-path-from-shell.el which replaces the path that the emacs build sets up 10:06:10
@bestlem:matrix.orgbestlemand I use direv via envrc.el which again replace exec-path 10:38:32
@bestlem:matrix.orgbestlem * and I use direnv via envrc.el which again replace exec-path 10:40:25
@gekoke:envs.netgekokeI use envrc.el as well, and I know I can still call binaries from my path after entering devShells because I can start LSP sessions.12:26:32
@gekoke:envs.netgekokeso I suspect there is some way to wrap the program, likely with the wrapProgram shellhook that would work12:27:11
@gekoke:envs.netgekokethough I haven't investigated and I'm not on macOS12:27:27
@lxsameer:matrix.orglxsameerhey folks, while building a package, is it us (nix derivation) that calles loaddefs-generate on a package?16:21:20
@lxsameer:matrix.orglxsameer

all the generated autoload files contains the same expression:

;;; haskell-autoloads.el --- automatically extracted autoloads (do not edit)   -*- lexical-binding: t -*-
;; Generated by the `loaddefs-generate' function.

;; This file is part of GNU Emacs.

;;; Code:

(add-to-list 'load-path (or (and load-file-name (directory-file-name (file-name-directory load-file-name))) (car load-path)))


;;; End of scraped data

(provide 'haskell-autoloads)

;; Local Variables:
;; version-control: never
;; no-byte-compile: t
;; no-update-autoloads: t
;; no-native-compile: t
;; coding: utf-8-emacs-unix
;; End:

;;; haskell-autoloads.el ends here
16:37:54
@lxsameer:matrix.orglxsameeris that expected?16:38:04
@lxsameer:matrix.orglxsameerhmmm surprisingly there is two autoload files for each lib in different locations17:28:26
@me:linj.techlinj
In reply to @lxsameer:matrix.org
is that expected?
it is part of the installation process of package.el, see package-unpack function, which elpaBuild and melpaBuild calls
17:29:46
@lxsameer:matrix.orglxsameercheers17:30:01
@me:linj.techlinjtwo autoload files in one package do not look right17:32:42
@lxsameer:matrix.orglxsameer
In reply to @me:linj.tech
two autoload files in one package do not look right
one is in site-lisp for example site-lisp/haskell-mode-autoloads.el and the otherone is in site-lisp/elpa/haskell-mode-20231115.1812/haskell-mode-autoloads.el
17:35:42
@lxsameer:matrix.orglxsameerthe second one contains the correct autoloads17:35:56
@lxsameer:matrix.orglxsameerthe one that I posted above is the first one17:36:12
@lxsameer:matrix.orglxsameerbut for some reason, emacs does not load the second autoloads 17:36:34
@lxsameer:matrix.orglxsameeroh found the reason, there was a zombie file with the same name lurking around17:42:07
@me:linj.techlinj
In reply to @lxsameer:matrix.org
one is in site-lisp for example site-lisp/haskell-mode-autoloads.el and the otherone is in site-lisp/elpa/haskell-mode-20231115.1812/haskell-mode-autoloads.el
I only have one in site-lisp/elpa. looks an error in your config?
17:42:11
@lxsameer:matrix.orglxsameerbut still use-package does not respects the autoloads file17:42:27
@me:linj.techlinj emm, use-package has nothing to do with package loading 17:48:00
@me:linj.techlinj it is a way to organize your init.el config 17:48:51
@lxsameer:matrix.orglxsameer (use-package foo) will require foo unless :defer t is provided 17:50:52
@lxsameer:matrix.orglxsameeror other keys17:51:01
@me:linj.techlinj
In reply to @lxsameer:matrix.org
but still use-package does not respects the autoloads file
what do you mean by "not respect"
17:55:58
@me:linj.techlinjautoload files are loaded before your init file17:58:07

Show newer messages


Back to Room ListRoom Version: 6