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.
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.
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
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)))
How would you attach a DAP python debugger to a running instance of (i)Python? Is there some import debugpy; debugpy.start() command or similar?
Set a window-configuration-change-hook
temporarily, see if the (selected-frame)
matches. If so do the split, and remove the hook.
When I hear of a package that may be interesting, I immediately check its repo page to see how many issues and PRs are still open. I look to see whether they have garnered any responses, especially if the submissions are of high quality. Years of issues building up isn’t a good sign. This isn’t 100% reliable, as different skilled developers approach issues and PRs quite differently, but it gives you some information. And there are outliers, like multiple-cursors, whose developer is very skilled and motivated, but whose popularity overwhelmed his resources.
For simple package, “no updates” for 5 years is usually fine. But before investing energy in a larger new package, I want to know whether it will still be working well in the next 5 years.
There are a variety of “self-quoting” constructs in elisp (including all :keywords
!).
(eq (quote nil) nil) ; ==> t
(eq (quote t) t) ; ==> t
(eq (quote :some-keyword) :some-keyword) ; ==> t
Outline mode works well for this. I use my own small outli package to set this up automatically with nice formatting and “speed key” access at the beginning of headlines. Tab to fold.
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.