search

oantolin / embark

Emacs Mini-Buffer Actions Rooted in Keymaps
GNU General Public License v3.0
946 stars 56 forks source link

Action, target finder, target collector and exporter wishlist #95

Open oantolin opened 3 years ago

oantolin commented 3 years ago

I think I might be missing many opportunities for target finders, target collectors and exporters. Let's list some here in this issue:

Target finders

Target collectors

Enhancements to existing collectors:

Exporters

oantolin commented 3 years ago

We should also think about exporters run from non-mini buffers. One that has been suggested is that in an eww buffer, export could make a list of all the links. I'm not so sure about that, probably a consult-link command is better and you can always run embark export from inside that hypothetical consult-link.

But I'm sure there are some good opportunities for export from regular buffers I'm missing. Currently the only ones are kind of boring: dired buffers export their files, ibuffers export their buffers, *Completions* buffers export their completions. Of course, dired and ibuffer are full-featured and you can also act on completions in a *Completions* buffer, so all of these exports are kind of pointless ---although I guess you do gain grid and zebra views in all cases, and the direct action minor mode might be useful for *Completions*.

minad commented 3 years ago

Is there also a target finder wishlist? Or is the list already exhautive?

oantolin commented 3 years ago

The target finder list is not exhaustive at all! Should I make a separate issue for that or just broaden this one?

minad commented 3 years ago

I would use one wishlist as I have in consult. I think this works quite well as some kind of general discussion thread before the details are then discussed in a separate dedicated issue.

oantolin commented 3 years ago

Earlier when I mentioned eww links I was really talking about just collecting them and forgot to say what kind of buffer they should export to: maybe an eww-bookmark-mode buffer is reasonable, even though they aren't bookmarks.

oantolin commented 3 years ago

OK, I've broadened this issue on your advice @minad. (I don't want the wishlist to also cover new commands, since in fact, I'm pretty skeptical about adding any new top-level commands to Embark at this point, except possibly the resume functionality, if we think it fits better in Embark.)

oantolin commented 3 years ago

Oh, I just remembered some actions for variables I often miss: set-variable and customize-set-variable, maybe even customize-variable.

oantolin commented 3 years ago

Good news: now consult-line, consult-outline, consult-mark and consult-global-mark export to occur mode buffers and e (for occur-edit-mode) works in them!

minad commented 3 years ago

@oantolin This is amazing! I already have it mentioned here: https://github.com/minad/consult#integration-with-embark. Now I can remove the work in progress note :partying_face:

oantolin commented 3 years ago

Oh, I just remembered some actions for variables I often miss: set-variable and customize-set-variable, maybe even customize-variable.

I added these for variables, and for commands I added execute-extended-command, global-set-key and local-set-key. 846cfbd7212ba3a3a47a059ba35400d534968815

protesilaos commented 3 years ago

I am just sharing this good idea for targeting video links: https://jao.io/blog/2021-01-09-embarking-videos.html. Natural complements are audio files and an action to yt-dl the target (audio could call mpv with the --no-video flag).

Maybe this is something that can be of use.

sheijk commented 3 years ago

@oantolin the actions for variables and commands are not available here. I checked that the commit you referenced is applied, value of embark-keymap-alist set accordingly, etc. But when I act on something like (defcustom e|mbark-keymap-alist (point at "|" char) I don't see customize or set variable options, same with commands like embark-act (version 20210111.1408). Can I see which map has been selected somewhere?

[edit: (embark--target) returns (symbol . "name") when invoked from source code. It works in C-h v etc. So an extended classifier for elisp variables/commands would be great]

sheijk commented 3 years ago

org-mode classifiers and actions would also be great. Or would this be better for an external package?

oantolin commented 3 years ago

@sheijk The variable and command specific actions are currently only available from minibuffer commands for those categories. For example you get the command actions for candidates in M-x in recent Emacsen. If you use Marginalia, then you get the command actions in M-x even on older Emacsen. And again, with Marginalia, you get the variable actions from describe-variable, for example, or from customize-variable.

The point is that, as you found, they are not supposed to work on symbols in regular buffers... yet! I've been thinking about refining the type. It would be much better once the multiple-targets stuff is finished #92, but for now I guess I could just pick an order: prefer command over variable if the symbol is both things. If Emacs were extended in Guile we wouldn't have these problems... 😛

oantolin commented 3 years ago

org-mode classifiers and actions would also be great. Or would this be better for an external package?

Possibly a separate package would be better, I'm not sure. I mean Org does come with Emacs. But that can be decided later, the first thing is to decide what kinds of targets and actions would be useful in Org buffers. Did you have any thing in mind? For a target type to be really useful ideally it should have several associated actions.

sheijk commented 3 years ago

Separate package makes sense, or at least a separate elisp file to not require loading org-mode when embark gets used in other buffers. I've recently made a little transient based menu for org, I think most actions offered there would be good embark candidates. Some examples for actions would be:

oantolin commented 3 years ago

I think your suggested org targets and actions are very good and that a separate embark-org (or org-embark?, how does that work?) package with them would be reasonable, but, wow, your org-menu package looks fantastic, @sheijk! I'd say your package takes the pressure off Embark to provide similar functionality with a different interface. 😄

minad commented 3 years ago

You could create an embark-org.el file similar to consult-flymake.el in order to retain lazy loading but distribute it as part of embark melpa.

sheijk commented 3 years ago

@oantolin or maybe start it with the actions I already made. Are you looking for contributions (no promise!)?

oantolin commented 3 years ago

@sheijk I added a transformer to refine symbol to command or variable if possible, for when you act on the symbol at point in a regular buffer. 296ad8077092ff839029c0bdb53c279e921e5354

oantolin commented 3 years ago

I am just sharing this good idea for targeting video links: https://jao.io/blog/2021-01-09-embarking-videos.html. Natural complements are audio files and an action to yt-dl the target (audio could call mpv with the --no-video flag).

Thanks for pointing this out, @protesilaos. I wrote to jao to suggest a slightly different implementation which he wrote about, and I noticed he also wrote an async Spotify client using Consult and Marginalia!

protesilaos commented 3 years ago

oantolin: I wrote to jao to suggest a slightly different implementation which he wrote about, and I noticed he also wrote an async Spotify client using Consult and Marginalia!

Yes, I have read them. My plan is to copy and adapt the video targeting part (never used spotify). More generally, I am excited to see what kind of solutions, tips and tricks the community comes up with for those packages.

minad commented 3 years ago

@oantolin @protesilaos Regarding the spotify client, it is exciting that they implemented a web access using the async api! I have some small experiments in the consult websearch branches as well, but they turned out to be not useful.

astoff commented 3 years ago

I think the way Embark works on a regular buffer is too Elisp-centric. Hopefully most people spend most of their time in Emacs doing other things!

For the purposes of embark-target-symbol-at-point, I would argue that symbol should mean a symbol in the current major mode. So the d action would be bound to xref-find-definitions. It's less clear what to bind to h, since there's no “describe thing at point” in xref (or whatever Emacs component this would fit into). Anyway, I suggest binding the h key to display-local-help. This is mostly useless in itself, but at least the user can remap that command to suitable major-mode specific values (describe-symbol in Elisp, cider-doc in Cider, etc.). Plus, it would work out-of-the-box with Eglot, which does precisely that remapping in its own mode-map.

On the other hand, I'm fine with the eval-region binding in embark-region-map because there's no better option, and, as above, one can use remaps to improvise a generic interface to the “send to repl” action across major modes.

There could still be an embark-target-emacs-lisp-symbol-at-point, but it should probably check if the buffer is in Elisp mode. Then it wouldn't work in random places like help buffers, but at least Embark would not capriciously (not) recognize words in regular text or other programming languages just because they happen to (not) have a meaning in Elisp.

minad commented 3 years ago

@astoff I agree! But I guess thing-at-point is also elisp centric. Unfortunately elisp is somehow more first class in Emacs then the other major modes. But that is natural since you can see it as a whole programmable environment.

astoff commented 3 years ago

@minad thing-at-point uses the syntax table to decide what is a symbol. (So in most prog-modes, but not in lisp-mode, (thing-at-point 'symbol) just after the text x-y returns y.)

minad commented 3 years ago

@astoff Thanks! Good to know!

sheijk commented 3 years ago

Another suggestion: support find-file-at-point for embark-become

oantolin commented 3 years ago

Those are all very good points, @astoff. I think the symbol stuff is so Emacs Lisp centric because I used it to develop it 😛

I've been thinking that the symbol target finder shouldn't check to see if the symbol is bound anyway. It uses (thing-at-point 'symbol) so it already takes syntax into account. I'll just remove the check for bindings from the target finder.

As for the actions, I use it all the time to lookup help or definitions for Emacs Lisp symbols in non-Emacs Lisp buffers (mostly help, markdown, org and message buffers) and I'd really, really hate to lose that. I guess I could make the configuration that ships with Embark more "politically correct" along the lines you suggest, and put a proper Emacs Lisp-centric configuration in my personal init.el. 😛

Or maybe I could still bind those Emacs Lisp centric commands, to different keys. I can't be the only one who wants to go to the definition of an Emacs Lisp symbol in a help buffer and is frustrated that xref-find-definitions prompts you for a tags table.

minad commented 3 years ago

xref-find-definitions prompts you for a tags table.

You can fix that by disabling the obsolete etags backend.

oantolin commented 3 years ago

Another suggestion: support find-file-at-point for embark-become

I don't understand this suggestion, @sheijk. Do you mean you want find-file-at-point bound in the embark-file+buffer-map? I don't think it would be very useful: find-file-at-point is basically the same as find-file, except the default is the file at point. As soon as you type something at the prompt, which embark-become does for you, it becomes just like find-file.

Could you explain what you meant?

oantolin commented 3 years ago

You can fix that by disabling the obsolete etags backend.

I'm confused: disabling that backend makes xref think that help buffer contain Emacs Lisp symbols?

sheijk commented 3 years ago

If I call find-file I can move to other file contexts. But if I call find-file-at-point embark-become doesn't offer any targets to jump to

astoff commented 3 years ago

From Elisp buffer, does xref work for you, @oantolin? xref-find-definitions has the additional benefit that you can go back to where you were before with xref-pop-marker-stack. Those things also have nice and prominent keybindings anyway, but it would be nice for the sake of consistency if Embark knew about them.

I use it all the time to lookup help or definitions for Emacs Lisp symbols in non-Emacs Lisp buffers

Fair enough. You could recover this behavior in one of two ways: (1) remapping xref-find-definitions and display-local-help in enough modes, or (2) introducing embark-target-emacs-lisp-symbol-at-point, which could or could not be on by default, and could perhaps also check if the major mode derives from one in a customizable list.

oantolin commented 3 years ago

@sheijk

If I call find-file I can move to other file contexts. But if I call find-file-at-point embark-become doesn't offer any targets to jump to

Gotcha! You don't want it so other commands become it but for it to become other commands. That makes perfect sense, sorry I didn't see that at once. I added it. 9fa6d6adc0086a97d82bf36723d44490bb6c9aa1

oantolin commented 3 years ago

@astoff

From Elisp buffer, does xref work for you, @oantolin

Yes, of course. I use it there instead of Embark actions so I can use xref-pop-marker-stack, as you mentioned. I use the Embark actions on Emacs Lisp symbols in a variety of non-Emacs Lisp buffers.

I use it all the time to lookup help or definitions for Emacs Lisp symbols in non-Emacs Lisp buffers

Fair enough. You could recover this behavior in one of two ways: (1) remapping xref-find-definitions and display-local-help in enough modes, or (2) introducing embark-target-emacs-lisp-symbol-at-point, which could or could not be on by default, and could perhaps also check if the major mode derives from one in a customizable list.

Or (3), having both xref-find-defintions and embark-find-definition bound to different keys in the symbol action map. They do, after all, do different things. And I have wanted both in the same buffer at times.

I wouldn't really want a separate embark-target-emacs-lisp-symbol-at-point, specially one that's not on by default. Does really no-one else want Emacs Lisp symbol actions to be on by default in *Help* buffers? I'd find that very hard to believe.

minad commented 3 years ago

Does really no-one else want Emacs Lisp symbol actions to be on by default in Help buffers? I'd find that very hard to believe.

:+1:

Would it make sense to add a possibility to select keymaps based on some predicate? This way you could exchange keymaps depending on the major mode for example.

oantolin commented 3 years ago

Would it make sense to add a possibility to select keymaps based on some predicate?

Seems unnecessary, just use a transformer to change the type based on the major mode. Something like:


(defun refine-symbol-type-by-major-mode (target)
  (cons (or (alist-get major-mode '((java-mode . java-symbol)
                                    (cc-mode . c-symbol)))
            'symbol)
        target)

And associate java-symbol, etc. to whatever action map you want.

astoff commented 3 years ago

Does really no-one else want Emacs Lisp symbol actions to be on by default in Help buffers? I'd find that very hard to believe.

Me too. And maybe this is a bug in xref! But then, as you mentioned, there are other places beyond Help buffers where it's perfectly reasonable to want actions on Elisp symbols. I'm not against special treatment to Elisp, but I'm arguing for staying as generic as possible, given certain limitations of Emacs itself.

Or (3), having both xref-find-defintions and embark-find-definition bound to different keys in the symbol action map.

I wouldn't really want that, I'm afraid... the xref stuff already has nice keybindings. I think the interesting thing here is to make the action context-dependent. So just one key for “show documentation”, and it does what you mean everywhere.

We're discussing the tail of embark-target-finders here, and maybe this is not even a super interesting case, so it shouldn't be overengineered :-). Don't you think a embark-target-emacs-lisp-symbol-at-point, placed as the next-to-last` finder, and of the shape

(when (apply 'derived-mode-p embark-modes-containing-stray-elisp-symbols)
  ...)

would be reasonable? The very last finder would then be the one for symbols as per the major mode, which relies on xref (plus display-local-help on h as long as xref doesn't offer anything suitable).

oantolin commented 3 years ago

Do you want a separate finder for Emacs Lisp symbols because you want it always recognize Emacs Lisp symbol syntax independent of the major mode syntax for symbols? I've been just using (thing-at-point 'symbol) in all major modes.

The very last finder would then be the one for symbols as per the major mode, which relies on xref (plus display-local-help on h as long as xref doesn't offer anything suitable).

Just to make sure I understand you: you don't literally mean the finder would depend on xref, right? The finder would use (thing-at-point 'symbol), and what you mean is that the actions offered would include xref-find-definitions on d and display-local-help on h?

astoff commented 3 years ago

Do you want a separate finder for Emacs Lisp symbols because you want it always recognize Emacs Lisp symbol syntax independent of the major mode syntax for symbols?

No, all that I care about is for M-x embark-act RET h to do the right thing on any buffer. It doesn't on a Python buffer. (Even weirder, if you look for help on assoc in a Clojure buffer and believe what you see, you'll be thoroughly confused!) And just to clarify, I can easily fix this for myself, I was just wondering if there's a nice, generic, unsurprising approach that requires no configuration. Seems quite tricky, though.

Just to make sure I understand you: you don't literally mean the finder would depend on xref, right?

Yes, right, maybe I put it a bit confusingly. I was imagining separate keymaps for Elisp symbols and for "symbols according to the major mode". This could be achieved through separate finders, but not only that way, as you pointed out above.

My quibble here is that every major mode agrees on how to choose the syntax highlight colors, but there's no unified interface for something as fundamental as requesting documentation on a symbol.

oantolin commented 3 years ago

OK, I think I understand and agree now. What actions are appropriate for non-Emacs Lisp symbols besides xref-find-definitions and display-local-help? Should they only get those two (plus the actions in embark-general-map, of course).

astoff commented 3 years ago

What actions are appropriate for non-Emacs Lisp symbols besides xref-find-definitions and display-local-help?

That's all there is, I think.

oantolin commented 3 years ago

OK. Got it. Will do. I'll call that new non-Emacs Lisp symbol type identifier, which is the term xref-find-definitions uses.

astoff commented 3 years ago

Good, now that I think about it, "identifier" is really the standard terminology. Symbols go by the weird name of "string" in most languages these days :rofl:

oantolin commented 3 years ago

OK, @astoff. I made the change. Now (thing-at-point 'symbol) is always recognized as a valid target and it is classified as either symbol (meaning Emacs Lisp symbol), or as identifier. The ones classified as symbols are those either were found in an Emacs Lisp buffer (whether or not they are bound), or are interned in the Emacs Lisp environment and were found in a buffer whose major mode does not inherit from prog-mode. Does that sound OK? beb5dd604890f4920e39bebefdd5619c81626fdc

oantolin commented 3 years ago

For identifiers the only actions you get are, as you suggested, xref-find-definitions and that lovely function display-local-help which is used to print the message "No local help at point". 😛

TxGVNN commented 3 years ago

Hello everyone. I'm thinking about adding an action run M-x when I run find-file

With this action I can :

WDYT?

oantolin commented 3 years ago

Do you mean you want to be able to run find-file, maybe navigate to some directory, and then run embark-act but instead of choosing one of the actions in the file map, use M-x to run whatever command you wan. @TxGVNN? If that's what you mean you can already do it!

If you use the keymap prompter, just type M-x and the command; if you use the completing-read prompter, when it prompts you for a command just type the command you want, it does not need to be one the list, those are just suggestions.

TxGVNN commented 3 years ago

Thank @oantolin, That is possible, right. I just suggest adding this action to the package if you think it is useful for everyone. I will build it for me.