When Emacs is first started ‘treesit-extra-load-path’ is empty and any
‘(treesit-language-available-p ...)’ will return nil. But calling, for example,
‘bash-ts-mode’ will work if the package is installed in Guix and will fill the
variable.
- Set the ‘treesit-extra-load-path’ to the value of ‘TREE_SITTER_GRAMMAR_PATH’.
Emacs doesn't seem to do this automatically, but Guix sets that variable when
grammars get installed.
- Add ‘bash-ts-mode’ to the ‘interpreter-mode-alist’. In his article[1] about
tree sitter support in Emacs Mickey Petersen mentions that it's best to use
‘major-mode-remap-alist’, however in his example he remaps ‘bash-mode’ to
‘bash-ts-mode’, but there is no ‘bash-mode’. Setting the
‘interpreter-mode-alist’ like this still works.
[1]: https://www.masteringemacs.org/article/how-to-get-started-tree-sitter
It always confuses me that it's defined in ‘lisp-interaction-mode’, but not in
‘emacs-lisp-mode’. ‘emacs-lisp-mode’ has the same basic snippet under the key
‘def’.
This section is meant to come right after the first “hello” section. The hooks
should be set up in pre-new and post-new to make sure that everything that needs
to run before and after works as expected.
I haven't been using Gnus for a while and have been using notmuch instead.
Having my email sending settings be a part of the gnus configuration makes it
impossible to send email without loading gnus.
Right now this doesn't seem to work at all... It works fine when I evaluate this
using ‘eval-defun’ or ‘eval-last-sexp’, but when I try to byte-compile it
doesn't work.
I've added my own custom macro that expands to the same thing that
‘(setf (map-elt ...) ...)’ should. I have forgotten how to write macros properly
so I may have made some mistakes.
This should only be temporary until I figure out why this is happening... it
might just be that I'm using a version of Emacs built from a faulty commit.
This way archives don't keep growing indefinitely and opening the archive
doesn't load every single language I've ever used because there are code blocks
in there.
When everything is interpreted it all works fine because ‘consult’ is loaded
before the ‘with-eval-after-load’ part is run, but when byte compiling the byte
compiler doesn't know that ‘consult-customize’ is a macro unless ‘consult’ is
loaded, which it isn't when Guix compiles it.
When it's byte-compiled as if it's a function ‘consult-buffer’ is assumed to be
a variable that's passed in, so I'm guessing it's trying to dereference it first
before passing it on to a non-existent function? But of course ‘consult-buffer’
is only a function (Emacs Lisp is a Lisp-2 after all), so it fails, but only
when byte compiled (and even only when byte-compiled in a clean environment
where there are no packages loaded that aren't explicity said to be).
Hopefully this fixes my issue with being unable to switch buffers until I
explicitly load ‘consult’.
This reverts commit 961651e575.
It works in an interactive session, but still fails while starting up. Probably
has to do with autoloads not having finished loading yet, perhaps?
This macro seems to work fine when expanded at run-time even when ‘consult’
hasn't been loaded, but it doesn't work after it's been byte-compiled... Perhaps
putting it in the top-level will help. I'm wondering if somehow the byte
compiler closes over a reference to ‘consult-buffer’ during compilation that's
not available when it executes?
In the Groovy used with Jenkins it seems quite common for there to be top-level
functions that aren't explicitly in classes (they still are implicitly).
The ‘get-multifile-module-version’ and ‘get-module-version’ functions open up
the given Emacs Lisp file and search for a “Version” header, parses it out, and
then returns the file name of the module as it should look in the package
archive.
