I also use rainbow-delimiters, but they are a bit too bright in my dark theme, so I:
(use-package rainbow-delimiters
:config
;; Darken them a bit
(cl-loop for f in (face-list)
if (and (string-prefix-p "rainbow-delimiters" (symbol-name f))
(face-foreground f)) do
(set-face-foreground f (color-darken-name (face-foreground f) 15))))
See also color-lighten-name to go the other way.
This package does nothing with C-n. Smooth scrolling at high speed can certainly take some CPU, nothing new there.
Makes sense. I thought in the past the default completion system stripped out text properties? But I dimly recall that situation changed recently (v29?).
I’d also worry that an eq test is a bit fragile, and could go mysteriously wrong if any step in the chain decided down the road to copy or duplicate the string.
You can also use this approach:
(add-hook 'text-mode-hook
(defalias 'my/fancy-mode-setup
(let (some-closure-var)
(lambda () ...))))
Advantage is that there can be only one alias, and it's added by name to the hook. So you can alter and re-run add-hook without duplication, and you can easily remove it by name. Best of all, you can create a closure (the let there) if you need that gives you "local storage in the function" that persists between runs (without cluttering the namespace with global variables).
Note that debug-on-error is disabled for process filter functions and post-command hooks:
Quitting is suppressed while running ‘pre-command-hook’ and
‘post-command-hook’. If an error happens while executing one of these
hooks, it does not terminate execution of the hook; instead the error is
silenced and the function in which the error occurred is removed from
the hook
You can turn error debugging back for culprit functions; see this gist.
You could mount all the files with sshfs and point the language server at that.
Thanks for the report.
That's the whole problem with using use-package forms for configuration! use-package is centered around a single feature at a time, whereas many configurations involve tying multiple features together.
What would you propose as a better design? It seems like you hope that pretty much all users of such a mythical package system would converge on precisely the same init structure, given the same feature requirements. Given the complexity of the system, I don't see how that's possible. I mean not even for simple toml/yaml configs is that ever the case.
In this case, it doesn't matter if I put the configuration in project's use-package form or in magit's use-package form--in either case, one of the forms will be misleading because it will seem like all of the configurations related to that package is in that form, but it won't be true because something about it is being configured in the other package's form.
You have two packages, and you'd like them to be tied together in some manner. Where should this config go so as to avoid such confusion? It has to go somewhere. The cleanest approach I know is to create a separate small package whose sole purpose is to make that integration happen, and use-package it. Some of these "tie-in" packages in fact do exist, for example:
;;;;; embark-consult: Tie the two together
(use-package embark-consult ...
You could create your tie-ins as small user packages, and group them under a joint heading in your init. This is not as hard as it sounds: at base a package is just some .el file on the load-path which does (provide 'something). But even still, this requires you or a user of your init to notice this "combiner" package, and realize they need it if they want the joint functionality.
So, do they go in the vertico use-package, or do they go in an emacs or simple.el use-package, or do they just go at the top level somewhere?
This is kind of like asking whether socks go in the top drawer or the bottom :). Wherever you'd best remember them! Vertico makes the most sense to me. I use-package builtins all the time, so as to organize them in a way I will remember. I do all my completion category stuff in my orderless stanza, and for any "special" completion setups (e.g. eglot), do those in the relevant package stanzas. M-x find-library will show you all the things you can use-package.
Since, project.el is built-in to Emacs, it's probably most reasonable to do that config in the magit use-package form
A key tip which took me a while to internalize: you can create use-package stanzas for built-ins. I do so all the time. E.g.:
;;;;; emacs server
(use-package server
:config
(unless (server-running-p)
(message "Starting Emacs server...")
(setq server-client-instructions nil)
(server-start)))People seem to be missing the point that no conceivable package loading tool — use-package, general, straight, by-hand gnarly lisp using eval-after-load, etc., etc. — will solve the original problem as stated. You want a binding to appear, tying project to magit. That binding is specified at the top level in one of magit's many lisp files. You want this binding to appear without loading magit. There is no approach which will accomplish this, other than excerpting that binding yourself, as you've done in the "clever/hacky" solution (though I'd put it in the project :config stanza for better organization).
The way simple extension loading works in other applications in my experience is "fully load all configured extensions at startup". This solves many problem (including this one), but is slow. You have the option to defer loading and much more with Emacs; the price you pay is complexity and the need to understand how the pieces fit together.
org-modern is nice but its best feature (block brackets, IMO) is missing when org-indent is enabled; you could give org-modern-indent a try to get those back (disclaimer: o-m-i author).