Leverage actions-on-current-suggestion as a list.

[aadcg]

Description

After #2555, we can now think about how this new feature translates into something useful for users!

I'd like to collect ideas from you on this topic. @Ambrevar @jmercouris @aartaka

I've added a dumb example with respect to hint-mode. When actions-on-current-suggestion is a list, you can set the default action that runs when the current suggestions changes.

Example:

• issue follow-hint and notice that issuing select-next and select-previous runs the default action on selection change (highlighting the hint on the web page's buffer)
• issue set-selection-action and set for instance scroll-to-selected-hint
• notice that now you get highlighting plus scrolling.

Checklist:

Everything in this checklist is required for each PR. Please do not approve a PR that does not have all of these items.

• I have pulled from master before submitting this PR
• There are no merge conflicts.
• I've added the new dependencies as:
  • ASDF dependencies,
  • Git submodules,

    cd /path/to/nyxt/checkout
    git submodule add https://gitlab.common-lisp.net/nyxt/py-configparser _build/py-configparser

  • and Guix dependencies.
• My code follows the style guidelines for Common Lisp code. See:
  • Norvig & Pitman's Tutorial on Good Lisp Programming Style (PDF)
  • Google Common Lisp Style Guide
• I have performed a self-review of my own code.
• My code has been reviewed by at least one peer. (The peer review to approve a PR counts. The reviewer must download and test the code.)
• Documentation:
  • All my code has docstrings and :documentations written in the aforementioned style. (It's OK to skip the docstring for really trivial parts.)
  • I have updated the existing documentation to match my changes.
  • I have commented my code in hard-to-understand areas.
  • I have updated the changelog.lisp with my changes if it's anything user-facing (new features, important bug fix, compatibility breakage).
  • I have added a migration.lisp entry for all compatibility-breaking changes.
• Compilation and tests:
  • My changes generate no new warnings.
  • I have added tests that prove my fix is effective or that my feature works. (If possible.)
  • New and existing unit tests pass locally with my changes.

[aartaka]

Does it actually make sense as a selection action?

A crazy idea: make both selection-actions and return-actions accessible in the return-marks-action and set-selection-action?

[aadcg]

You're referring to copy-selected-hint* right? Actually I had this idea written down and I know I took it from you! It could very well be that I misunderstood you somehow. Note that right now it's not very useful since the URL might be relative (e.g. #potatoes), but that's an issue orthogonal to this PR...

A crazy idea: make both selection-actions and return-actions accessible in the return-marks-action and set-selection-action?

I think I understand what you mean and I agree. The only obstacle is that return-actions run over marks whereas selection-actions run over a single element (the suggestion).

Actions should be defined in such a way that it could be used in both cases. If we look at the particular of hint-mode, then we could use for instance focus* in whatever context.

[aartaka]

Are NIL values deleted from the selection-actions list? Maybe they should be...

[aadcg]

That's a good point! I think they should. Should have been part of #2555...

[Ambrevar]

Looks reasonable to me :)

[aadcg]

Let's postpone this for later, since there are more pressing issues at the moment.

[aadcg]

Closing this PR as there isn't much interest in these features as of now.