rework register functions

[minad]

rework register functions

[oantolin]

Oh, I see what you mean: you could handle a special keybinding for direct access to register in consult-register. That makes sense, maybe it's even a good idea.

[oantolin]

The new register preview is lovely! And I take back what I said about consult-register, I'll think use it sometimes for the consult preview functionality and without even typing anything: just scrolling through the registers is so much fun!

[oantolin]

I'll try to summarize some of the discussion.

• The best thing about consult-register is that it unifies insert-register and jump-to-register. We definitely want these operations to be unified, since they make sense for disjoint types of registers.

• The register previews for markers are not very informative. A display similar to consult-mark's would be preferable.

• There is a question if whether completing-read is really the best interface for this: do people really want to filter registers by typing part of the description? Compare with the built-in register-read-with-preview which lets you select a register with a single keystroke. On the hand if you use Embark you might want register actions and selecting registers with a single keystroke does not give you opportunity to trigger an action instead.

[minad]

There is a question if whether completing-read is really the best interface for this: do people really want to filter registers by typing part of the description? Compare with the built-in register-read-with-preview which lets you select a register with a single keystroke.

I think I want that. This is like the kill ring, which I would also like to search through.

[oantolin]

I think I want that. This is like the kill ring, which I would also like to search through.

Mmh. I guess that all the previews except the one for markers do contain text I could see myself filtering on. If the marker preview looked like consult-mark, then filtering the descriptions would probably be useful for all types...

Maybe consult-register is fine as is, and we only need to override the marker description.

[oantolin]

With a completion-style that supports regexps, selecting a register by name is not to bad either: ^w then RET...

[minad]

There is a question if whether completing-read is really the best interface for this: do people really want to filter registers by typing part of the description? Compare with the built-in register-read-with-preview which lets you select a register with a single keystroke.
I think I want that. This is like the kill ring, which I would also like to search through.

This would also make it more similar to evil style marks, or doesn't it? I am not an evil user.

Maybe consult-register is fine as is, and we only need to override the marker description.
With a completion-style that supports regexps, selecting a register by name is not to bad either: ^w then RET...

Agree, the display needs improvement.

Another question - would it make sense to have some support to edit registers? This is missing from the current discussion. The existing register interface is already good for that, except that you don't see immediately which registers are free. And then the default register preview is not informative. So we may also need this.

[minad]

I pushed an improved version of consult-register. It highlights markers similarly to consult-mark. I still wonder if we should do something about editing. I like the current register keybindings for editing, but I don't like the register-read-with-preview display. I would like to have a more informative display also for editing, similar to what consult-register offers.

Fortunately Emacs provides the register-preview-function. Maybe I can offer an enhanced consult version which can be used instead of the dumb default version. I will try that now. This will give us a very consistent interface.

[oantolin]

What don't you like about the register-read-with-preview display? Is it just the display for markers? Because I would love a consult-mark display in the regular register-read-with-preview. I think the display for other types of registers isn't all that improvable.

[oantolin]

And you did it while I was typing that comment! 😆

[minad]

Oh, I like it now. I just need a consistent display! I only improved the marker display as we discussed and some minor improvements to some others, take a look at the code :)

Furthermore there is configurable narrowing to register types (since you can define your own types via clos). And markers are also previewed.

EDIT: For me the defining property of registers is that they have these very fast convenient keybindings. We only enhance it with a better preview and a completing-read search. That's all we should do!

[oantolin]

I'll test it soon. I suspect I'll love consult-register-preview but probably still won't use consult-register because the whole idea of not being able to select a register with a single letter still sounds off to me.

[minad]

It is a neat feature, also for discoverability/demo purposes. But similar to consult-mark it won't be used very often, since, I suspect, situations where you would want to search for a register are rare. For quick access you should still use the standard keybindings. But as you wrote, ^a is not that bad.

One could certainly discuss if some rarely used commands like consult-register are worth it and should even be part of Consult. If the footprint of those functions is not too large I am not against having them here. If it turns out that the whole package gets too large we can always consider categorizing the functions and splitting up the package accordingly.

[oantolin]

I don't think anyone benefits by you removing consult-register. It's not like its going to be an ongoing maintenance burden, and maybe someone does use it.

It's not just ^a, by the way, you also need to press RET. 😉

[minad]

It's not just ^a, by the way, you also need to press RET. wink

I typed it, but you cannot see it since it is a whitespace char ;)

You can also scroll through the entries and use the preview to jump. You can use registers like volatile bookmarks.

[oantolin]

I forgot about preview. That's already reason enough to use consult-register! Plus you can always do something like this to save one key and additionally not need to press shift for ^:

(define-key minibuffer-local-map (kbd "\\")
  (defun select-register (reg)
    (interactive "cRegister: ")
    (insert (format "^%c" reg))
    (minibuffer-force-complete)
    (exit-minibuffer)))

(You'd have to rewrite if you are not using a completion-style with support for ^ or if you are using Selectrum, but you get the idea.)

[minad]

Well, if adding keybinding, it may make more sense to throw an error and catch it outside. Is there no function like minibuffer-force-exit-with-candidate? Then this would be independent of the completion style.

[oantolin]

Well, if adding keybinding, it may make more sense to throw an error and catch it outside. Is there no function like minibuffer-force-exit-with-candidate? Then this would be independent of the completion style.

Wouldn't that function, if it existed, need to receive the full candidate? I want to only type the first letter of it. The minibuffer-force-complete is the means to acquire the full candidate. (There is also a minibuffer-force-complete-and-exit, which surprsingly is not exactly the same as (progn (minibuffer-force-complete) (exit-minibuffer)).)

[minad]

Yes, the function would have to get the full candidate but I could do the lookup myself in the select-register function.

[minad]

How would you implement it if you have the full candidate. Via throw or is there a better possibility to force minibuffer exit with this particular candidate?

[oantolin]

I think throw is how you are supposed to do it; exit-minibuffer uses throw itself.

[minad]

I experimented a bit with such a select-register keybinding. I think it is not worth the effort and complexity. I also tried to add the possibility to store when a key is not yet used. See register-experiment branch.

[hmelman]

I've played with the melpa released version. I like the display and the ability to filter on the content of the register though I agree that typing a letter and RET and not having that inserted/jumped is odd. I get why. I added :inital "^" to consult-register and of course that brought that behavior. I think I like it better. Maybe it should be an option to include that (or an ARG).

I agree that the value of consult-register over the builtin commands insert-register and jump-to-register is the filtering on content (and narrowing), so maybe this it just be used (and optimized) for that case and people should use the builtin for other uses. Even the display of register values is done by register-read-with-preview so that's not added value.

FYI, I tried narrowing briefly and got options thats included buffer and file which didn't seem right to me.

I think the doc string or an FAQ should be explicit about the use case. Use this to filter on the content and use the standard register commands for quick access to a register.

[minad]

I think I like it better. Maybe it should be an option to include that (or an ARG).

You can always do that by modifying consult-config for consult-register. No need to add anything to the package :)

FYI, I tried narrowing briefly and got options thats included buffer and file which didn't seem right to me.

This is intensional. Marker registers are silently transformed to file-query entries, when the corresponding buffer is closed. Maybe I should transform them back to markers for the consult-register preview.

I think the doc string or an FAQ should be explicit about the use case. Use this to filter on the content and use the standard register commands for quick access to a register.

Good idea.