Transient levels, persistence, and the customization system

[domq]

Hi, I just discovered transient levels (for the -A / --autostash option to magit-pull) and the way they are persisted (i.e. transient-levels-file).

I'd like be able to turn on -A availability from my .emacs.d/init.el instead (or in addition to) doing it by hand as currently offered. I use my .emacs.d/init.el as the sole source of truth for the way my Emacs should behave, so that I only need to restore that one file from backup to get everything else going (thanks to use-package, quelpa et al.)

I'm thinking that setting transient-levels-file to the custom symbol, could have the effect of using Emacs' customization setting as the persistent source of the transient-levels variable. Would you accept a pull request that does that?

(I'm not asking for the detailed structure of transient-levels to be made public / documented, and I'm fine with the possibility that my transient-related :custom stanzas in my use-package statements might break every now and then.)

[tarsius]

There are many packages that store "data" (including "settings" that cannot trivially be recreated) in separate files. I recommend you just accept that as a fact instead of making such requests as you keep running into these packages.

I use my .emacs.d/init.el as the sole source of truth for the way my Emacs should behave, so that I only need to restore that one file from backup to get everything else going (thanks to use-package, quelpa et al.)

I recommend putting that file (and the others) in a git repository instead.

I'd like be able to turn on -A availability from my .emacs.d/init.el instead

You can already do that. This is how the variable is initialized:

(defvar transient-levels
  (transient--read-file-contents transient-levels-file)
  "Levels of transient commands.
The value of this variable persists between Emacs sessions
and you usually should not change it manually.")

If you make sure to set that variable before transient is loaded (using setq in your init file), then defvar won't override that value. (defvar only sets a variable if that is still unbound by the time the defvar form is evaluated.)

[domq]

Thanks for your reply and suggestion, and I'm glad I started a discussion (actually I'm using this feature of GitHub for the first time) before reaching out for a pull request!