I've set `lexical-binding` to `nil` in all Emacs Lisp files to suppress
the warnings introduced in Emacs 31 requiring all elisp files to have a
`lexical-binding` comment.
This retains the default behavior of dynamic binding when no
`lexical-binding` comment is present. With it set to `t` across the
board, various things break, and fixing those is a task for another day.
Makes cmd+shift+p open the command palette and cmd+/ toggle comments, as
they do in VSCode.
This should ease my recent usage of Cursor/VSCode alongside Emacs, as
certain keybindings I have in Emacs cannot be setup in VSCode to work in
all contexts. Hence I've had to get used to cmd+shift+p instead of C-x
C-m, as the later does not want to play ball when a terminal is active
in VSCode.
This somewhat works around some changes to cape, which I was abusing to
effectively get a capf yasnippet function that would only return results
on exact matches. This allows normal lsp completion to work just fine,
except for exact matches against specific snippets.
Now we use the yasnippet-capf package instead, no longer needing the
company-yasnippet package, and hacking it to also only give a single
result back, with some caveats.
This reverts commit 2dfc86b610.
Removing navigate action on {} pair has a lot more side effects which
are very annoying. I will need to find another workaround.
When the global-treesit-auto-mode is enabled, was getting lots of errors
related to an infinite loop whenever opening a buffer supported by one
of `*-ts-mode` modes. Instead, I now take a more manual and intentional
approach to using the built-in treesit modes for specific languages.
Enabling tree-sitter-mode in markdown buffers led to tree-sitter-mode
failing to load when editing pull request descriptions with forge.
As tree-sitter seemed to have no effect on markdown files, we might as
well just disable it.
The prog-mode snippets are very basic, a bit a annoying, as they
contain a couple of single-character snippets which conflict with common
variable names in Go.
Packages that need to be loaded on emacs startup, should just be loaded
through use-package in a non-deferred manner.
It makes no real difference to startup, loading the packages either
slows down emacs before "startup" is complete, or right after it
completes. End result is that Emacs is unresponsive for basically the
same amount of time regardless.
