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.
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.
You have the wrong target. I don’t think you are (or should be) actually complaining about use-package, but about the setup of various cross-package “tie-in features”. So magit knows about project.el. It kindly offers to add a special command to project-switch-commands, but (quite reasonably) only after project.el is loaded, and if project-prefix-map is defined. Luckily the latter is a builtin autoload, so it’s just a matter of ensuring project is required with magit before you can use the tie-in, whenever you want that to happen.
As already pointed out, you could add (require 'project) directly in magit’s use-package :config stanza to make this tie-in happen right away after magit loads. Or, perhaps even better, identify a hook (magit has many) to do this “just in time” before you use magit in some meaningful way. If you want this tie-in to happen somehow magically without loading magit, good luck with that; it’s a literal top-level (with-eval-after-load 'project) in magit-extras.el! You only option is therefore to do what you did: boost that logic out into your config. Or how about this: (require 'magit-extras) in your (use-package project :config). That way you’re only loading a tiny part of magit when project.el is loaded.
The bottom line: how is use-package or any other config paradigm supposed to know when you’d like magit’s project.el tie-in to activate? Some people would like to have project -> magit interaction on demand the very first time they invoke the project menu in a git-controlled file. Others want that tie-in command available only if they have already been working with magit in a session. You apparently want it active and ready to go without loading either package. This is way beyond use-package’s scope. The only solution is to investigate the nature of the tie-in, and configure it yourself to work the way you want. Which is what you did ;).
Can you comment on what the future for this JSON-handling-in-a-separate-thread emacs fork looks like, currently? Any hope of upstreaming some perhaps more general version of limited multi-threaded support of this kind? Other “downstream” forks (like emacs-mac) miss the benefits.
A variable watcher maybe.
(add-variable-watcher
'myvar
(lambda (sym val op buf)
(when (eq op 'set)
(push val (get sym 'prior-values)))))
Try emacs-mac, works great there.
Did you either succeed with debugpy.listen()? Is that suitable to call interactively then quit (like iPDB)?
M-x find-library python, followed by C-s outline- shows what’s happening: python-base-mode sets the local outline variables locally, in its mode body. Since mode hooks always run after the body of their mode definitions, you could add a bit of code to the python-base-mode-hook (or a parent of it, like prog-mode-hook) setting your desired outline config there (i.e. overwriting what python mode did).
I do that using outli simply (in a use-package stanza):
:hook ((prog-mode text-mode) . outli-mode))
BTW, here’s a handy guide (from this epic answer) to what runs in which order upon invoking a derived major mode like python-ts-mode:
So when we call (child-mode), the full sequence is:
(run-hooks 'change-major-mode-hook) ;; actually the first thing done by
(kill-all-local-variables) ;; <-- this function
,@grandparent-body
,@parent-body
,@child-body
(run-hooks 'change-major-mode-after-body-hook)
(run-hooks 'grandparent-mode-hook)
(run-hooks 'parent-mode-hook)
(run-hooks 'child-mode-hook)
(run-hooks 'after-change-major-mode-hook)
Not sure your definition of easy, but this kind of setup (and much more) is certainly possible: https://www.masteringemacs.org/article/demystifying-emacs-window-manager
Start with the Elisp intro; it’s great. M-x shortdoc buffer gives a nice overview of buffer commands. I love consult-info for general searching of the Elisp (and other) info files. But M-x apropos-function is builtin and useful too.
No need for a package, this is a great chance to learn some elisp. To get you started:
(let ((cur (current-indentation)))
(push-mark nil t t)
(while (and (not (eobp)) (= (current-indentation) cur))
(forward-line 1)))
Seems like in-process debuggers like iPDB are far more practical for interactive debugging of long running shells.
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).