• 1 Post
  • 27 Comments
Joined 1 year ago
cake
Cake day: October 1st, 2023

help-circle







  • 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.



  • 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 ;).






  • 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)