Select action/sub-action after running generic command

[noctuid]

Some links are straightforward and only have one way to act on them. Others may have a way to open, copy, or take some other action on them, and some may have multiple ways to open them (e.g. paradox: open package info, view homepage, and view commit list).

Link hint should support adding actions for specific link types and have a generic command for selecting a link (and then choosing the action). If only 1 action is available for the selected link, it should be taken. Otherwise there would be some way for the user to select the action afterwards. The reason I wouldn't want to use a link hint version of avy-dispatch-alist for this is because the link type isn't necessarily known until it is selected. It could maybe be used for selecting the type of action (copy or open).

The main new command would be link-hint-select-link, a generic command to select a link then select the type of action and specific action (all actions would be available from one prompt grouped under the types; the type could maybe selected in a manner similar to how avy-dispatch-alist works). It would also be possible to have a command link-hint-open-link that would only consider open type actions built on top of this new command.

I'll have to think about what the best interface for choosing the action would be.

I'll work on this after #12.

[jb55]

an obvious thing I find myself wanting is opening github patch links from my email client. right now it opens my browser, it would be great if I could just open it in a buffer.

[noctuid]

I've started working on rewriting link-hint for #12 and am rethinking how I want to handle this issue. For one, I can't think of a circumstance in which a user would only want to select the action after selecting a link. Allowing the user to select the action is useful because there could potentially be a lot of actions or combinations of actions/# of links to open, so it makes sense to be able to do this all from one command. That said, selecting before would allow selecting from all actions and then only putting overlays on supported links.

As for what interface I'm going to use, there is avy-menu, hydra, magit-popup, and avy-dispatch-alist (I'll also support ivy separately at some point for choosing instead of avy). Whatever menu is used needs to stay present so both the link action and the # to open can be changed. I don't think avy-menu can do this, so that leaves hydra and magit-popup. magit-popup is going to be deprecated, so I'll probably go with hydra.

Using avy-dispatch-alist would be nice, since the user could go with some sensible default (like open one link) and potentially settings without always having to deal with some menu. The issue is that if the action changes, the supported links would to, which would mean it would be necessary to redo the collection/avy overlays (and I'm not sure if this is possible with avy-dispatch-alist; maybe with some hack).

an obvious thing I find myself wanting is opening github patch links from my email client. right now it opens my browser, it would be great if I could just open it in a buffer.

After #12 is done, you'll be able to change the open action on a per-link basis. There will also be open-internal and open-external.

[jb55]

my hacky solution to run a generic command that opens a link inside emacs. please excuse my noobish elisp, wasn't sure how to detect when copy-link was cancelled. This seems to work though.

(url-handler-mode 1)

(defun link-hint-download ()
  (interactive)
  (let ((before (current-kill 0)))
    (link-hint-copy-link)
    (let ((after (current-kill 0)))
      (if (not (eq after before))
          (find-file after)))))

[noctuid]

To do that, you can create a new open command that always opens inside emacs (e.g. :open-internal; see creating new commands). For many commands the :open-internal function could just copy the :open function. I'll add this new command directly to link-hint at some point.