minad
consult-register: Set register-command-info (Emacs 30)
Emacs recently changed how register jumping/loading is handled. The variable register-use-preview may be used to adjust that behaviour; it's read and acted upon by (e.g.) register-read-with-preview. That function (which we call inside of consult-register-load) checks which command called it and gets some information about that via the register-command-info defmethod. If (say) the command indicates that it just wants to jump to some register, an additional confirmation is skipped when register-use-preview is set to an appropriate value.
Thus, to completely restore how Emacs used to handle register, we need consult-register-load to signal that all it does it jump to the register.
N.b.: I didn't change the changelog yet, as I don't know if this qualifies as something that should be in there.
Thanks for this. I noticed the debates regarding the register changes. I am not sure if everything is settled regarding that matter?
For now I won't merge the change. I will do so after I had time to test the new register behavior and the interaction with Consult. This will likely happen when the emacs-30 branch is created. Do you have an idea when that might happen? Then I will also bump Compat to compat-30 and finalize Emacs 30 support in my packages.
Thanks for this. I noticed the debates regarding the register changes. I am not sure if everything is settled regarding that matter?
Yeah it was quite a heated discussion, but people seem to have cooled off a bit now and this commit is—to my knowledge—the end of that story. There is actually another option to register-use-preview now (which I missed at first): traditional. That one does not require downstream packages to change and essentially restores the old Emacs 29 functionality. However, the register-command-info is still used for other values of register-use-preview. Some of these, like a value of nil (how descriptive), add some eye-candy and so I think downstream packages should still adjust and support that use-case.
For now I won't merge the change. I will do so after I had time to test the new register behavior and the interaction with Consult. This will likely happen when the emacs-30 branch is created. Do you have an idea when that might happen? Then I will also bump Compat to compat-30 and finalize Emacs 30 support in my packages.
Okay, fair enough, thanks for considering! I have no idea when emacs-30 is going to be cut, but I'd imagine that it'll take a few more months.
I've just migrated to Emacs 30. Is this PR still needed? I don't see any change in behavior with register-use-preview=nil.
Is this PR still needed?
I believe so. Without this change, even setting register-use-preview=nil, one has to give Emacs an additional confirmation when using consult-register-load. E.g., given a register on a, with this change (and before Emacs 30) one would just have to execute consult-register-load a to jump to the register, while on Emacs 30 without this change it's now consult-register-load a RET.
It seems to me that the change is unnecessary. One can simply set register-use-preview to traditional (the default) and everything keeps working as is. What is the advantage of setting register-use-preview to never or nil?
With traditional the preview window does not show up until register-preview-delay has passed, so one would have to set that variable as well. Judging from the documentation of register-use-preview, it seems like this is mostly legacy behaviour. The docs for nil do say
When nil, show a preview buffer without navigation and highlighting, and exit the minibuffer immediately after inserting response in minibuffer.
Emphasis mine. I guess people might find it surprising if consult does not behave in this way. Plus, the message one gets for nil upon pressing a is "[Overwrite register a]", which is not what's happening when trying to load a register.
I see why the change has been controversial. There seem to be zero advantages if you set register-use-preview=nil over traditional mode with a delay. The traditional behavior cannot be legacy and is here to stay, since otherwise you cannot use a non-zero delay. I think traditional+delay is the best behavior, similar to which-key if you hesitate for too long pressing the next key. Also note that Consult offers both commands for immediate exit (consult-register-load) and with navigation via completing-read (consult-register), so even register-use-preview=t does not add anything new for us if I understand correctly?
So the only advantage of this addition is that never and nil work as expected, despite that these settings are not beneficial. It may make sense to instead recommend just setting register-preview-delay.
Okay, I close this for now. I will reconsider, in the case I discover that there are actual advantages of the settings never and nil.
To be clear, the new register UI works if used as intended by Thierry (preview=t). The only settings which are affected are preview=never and preview=nil, but as far as I understand they are some kind of half-way compromise between preview=traditional and preview=t.
In any case, I am happy to hear further explanations, which may help me see through this a little better.