Prompt buffer polishing

[Ambrevar]

Follow-up to atlas-engineer/nyxt#1157.

Left to be done:

• Ensure paging works as expected. Have C-p recenter on suggestion?

  See if we can keep
  2eeafbac2bea481b04fce0e7e5f8dbfbdcb70acc ("prompt-buffer.lisp: remove
  element-in-view-port code"), or else revert it.

  See Support Page-Up / Page-Down keys in minibuffer nyxt#454.

  Make it configurable like in Emacs, whether we should re-center or not when going off-screen.

• Remove make-source?

  Looks like we are only using make-instance 'prompter:source.

• [ ] Remove constructor / destructor slots, see Make mode constructors/destructors composable nyxt#1005.
  But do we need instance-specific overrides?
  See Turn the prompter function slots into methods? #29.

• Should we have C-h m to explain how the prompt buffer works?

• VI bindings

• Extend support for input history.

  • set-url has it, add support for all commands.
  • Make sure duplicates are not inserted.

• Highlight portion of matching text.

• Enable follow-mode in multi-buffer search.

• Make meta command which allows for selecting sources, then drop into new
  prompt buffer with given sources.

• Rename properties to attributes to avoid confusion with symbol.
  Use strings as keys.

  Suggestion properties should be an alist, so that properties can have
  arbitrary names and casing.
  I suggest un-dotted alists since they are shorter, more readable, more
  beginner-friendly.

  So replace (:name "foo" :desc "bar") by
  (("Name" "foo") ("My description" "bar")).

• Cosmetic: Option to not display the column names. For instance in "New
  URL" source. Simply don't display when there is only one attribute?

• Cosmetic: Don't display source header when there is a single source. Instead, display the source name in the prompt.

• Cosmetic: Display marks / counts per-source too.

• Add with-prompt helper to avoid having to (let ((result (first (prompt ...)))) (when result ...)) for each prompt. We could even support
  chained prompts, like sera:and-let*.

• Echo message when no source has any suggestion (nor do they allow for raw
  user input) instead of showing a useless prompt-buffer.

  Actually, it may be useful to show an empty prompt buffer to emphasize
  what's happening (echo messages are not always seen), and to display the
  list of sources.

• Add action to sort by column.
  Would be great if we had mouse support, i.e. click on the column name to
  sort by this column in ascending / descending order.

• Add action to only show (un)marked suggestions.

• Add column filters.

  This one is tricky, because we want to make it both flexible and
  explorable.
  We could add actions, but it can be a bit tedious to go through multiple
  menus just to filter, say, by today's date or the +foo tag.

  One option would be that the action actually inserts a special syntax in
  the prompt which does the filtering.
  This special syntax could be started from (.

  Example:

  ;; first arg is column name
  (filter "URL" (match-host "example.org") (match-port "80"))
  (filter "tags" (match "lisp" "games") (match-not "racket"))

  Could also be cool to enable column and predicate completion.

  Refer to old tags.lisp and bookmark.lisp from pre-release-5.

• Remove object-display and replace object-string with attribute-default.

• Remove must-match-p.
  See Prompt buffer (minibuffer overhaul) nyxt#1157 (comment)

• Don't expose suggestion-maker, revert to suggestion-filter-funtion and
  rename it attribute-function.

  Update: We still expose suggestion-maker since object-attributes alone does
  not enable us to implement prompt-buffer-command-source.

  Update 2: Maybe we can implement prompt-buffer-command-source with
  initialize-instance :after. If so, then we can unexport suggestion-maker.

• Support multiple persistent actions, and add action to choose which one to
  enable.
  See also Multiple persistent actions emacs-helm/helm#1926.

  Update: For now we support a list of "follow mode functions".
  What's missing is a command to change which one is first.

  Update 2: We now have nyxt/prompt-buffer-mode:set-action-on-current-suggestion.

• 3 types of functions can be run from the prompt buffer:

  • actions
  • persistent actions
  • commands (bound to keys)

  Can we conflate these into just 2 types, e.g. should all commands be actions?
  If so, we need to away to set a bunch of default actions with their keymap.
  Inheritance? Store actions in prompter?

  But isn't the job of the prompt-buffer-mode to deal with keymaps? It would
  be more consistent for the user.

  We can list actions and the previous point will allow us to list persistent
  commands.
  We need a way to list commands. C-h b mentioned above?

  Add command to list all functions? Multi-source?

  Update: "actions" are not well defined above. What we have:

  • Bound function-symbols (not necessarily commands, should they be?).
  • Returning function-symbols: listed in M-return and exiting the prompt buffer.
    • Rename "actions" to "returning functions".
  • Follow mode / C-j function: just like the bound function-symbols, except that it's automatically executed in follow-mode, or expectedly bound to C-j.
    • Should be a list and the first function is the one that's executed. Add a function to change which one is the first.
    • Rename persistent-action to follow-mode-functions.

  Done, but we're keeping the "action" term (for now) for returning functions.

• Style: Refactor update-suggestion-html and a few other functions in
  prompt-buffer.lisp.

• Replace -new-buffer and -new-window commands with action bound to a
  well-known key.

  For instance, instead of having C-l and M-l, have just set-url and
  bind shift-return to the "new buffer" action.
  Also bind C-shift-return to the "new window action".

  We can do this for all commands that have the option to open something in
  a new buffer or a new window. This approach draws from Helm.
  One of the benefit is that you only need to decide as a last action
  whether to open the URL in the current buffer or not. This is convenient,
  because depending on the suggestion results you might change your mind.

  This would also close the following TODO:

  ```lisp
  (focus-on-reopened-buffer-p t ; TODO: Replace this with prompt-buffer Helm-style actions.
  ```
  

  Finally, we could get rid of all the new-buffer-load* and new-nosave-buffer-load*. Maybe turn them into lambdas?
  Update: This last point is done.

• Conflate history commands into the following
  - history-forwards (unchanged)
  - history-backwards (unchanged)
  - history-forwards-query: Use all sources from
  history-forwards-direct-children and history-forwards-all.
  - history-backwards-query: Use all sources from
  history-backwards-query and history-all.
  - history-forwards-maybe-query: Same but use history-forwards-query instead.

• Maybe use history-backwards-source in add-domain-to-certificate-exceptions.

• Style: Rename suggestion's value slot to maybe data? But then we
  would need to rename the matching-data slot (which is a poor name anyways).

• Maybe move if-confirm.lisp to configuration.lisp.

• Move set-url-from-bookmark source to set-url, then remove
  set-url-from-bookmark.

  Update: set-url now uses the bookmark source, but we still have the
  set-url-from-bookmark command. Remove?

• Add tag suggestion source to the bookmark-url-* commands.

• Add support for regular expression matching.
  Should be easy with custom filter.

• Add options to not prompt when there is only one or zero suggestion.
  Two cases:

  • If zero, raise condition as if the prompt buffer was canceled.
  • If one, proceed directly with this value.
    I suppose this only works if constructor is synchronous.

  Update: We now have the auto-return-p slot, but does it work for async sources?

• Add prompt-buffer mocking for testing.

• Element-hinting functions need a custom filter to match against the hints.

• Re-enable search-engine completion.
  I suggest adding a command / argument that, when non-nil, prompt for a
  search-engine to load the input with.
  We could prompt for an engine either before or after prompting for text.

  This means we could drop the special "search-engine" prefix syntax, which
  is a bit arcane / unstructured in my opinion.

• Make sure update threads are killed when hiding buffer.

  Add tests when prompt buffer is interrupted.
  What if it's never interrupted, just left in the background?

  Should be fixed if we switch to Lparallel and use conditions to interrupt threads.

• Implement suggestion-limit?
  Trivial with sera:take, but do we need it?
  See Unused prompter source slots #30.

• Should prompter really have keymaps?

• Fix yes/no race condition in prompter tests.

• Add an option to remember the follow-mode state. Should we do it per-prompt, per-window, per-browser?

• Add a binding to display the prompt-buffer help / documentation (without closing it?)

[Ambrevar]

@jmercouris Please let me know if you have answers / suggestions to any of these
points.

As usual, I'll push what's uncontroversial directly and send pull requests for
the rest.

[jmercouris]

OK!

[aadcg]

Sorry if the following suggestion is already in your list and I missed it. I suggest that the highlighted entry in the prompt buffer should be in the middle. At the moment it's in the lower part. As you can see below: 5 top entries, the current one, 1 below and another "half one".

[Ambrevar]

It's not in the list and yes, there is a slight "problem" with it :)
To be clear, the selection position is currently "unconfigured", I just added some javascript to make sure it's in the view, that's it.

To go even beyond what you suggest, I propose to make the paging configurable, a bit like Emacs allows. Some users would like the selection to remain in the middle, others would like it to go to the bottom when they call "next page", etc.

[aadcg]

Makes sense to me. Btw, can we already page down in the prompt buffer?

[Ambrevar]

Nope (it's the first item on the list), but it shouldn't be hard! :) I was thinking something along the lines "scroll until it runs out of view". Maybe there is a better way to implement it in Javascript though.

[aadcg]

Nope (it's the first item on the list), but it shouldn't be hard! :)

Right, excuse my blindness!

Can't give much advice regarding the scrolling.

[aartaka]

• Mouse support (while we don't necessarily use it, it's what people are used to)
  • At least at the level of clicking suggestions.

[aadcg]

Note to self, TODO:

• Add detailed section to the manual (see Manual section on prompt buffer. nyxt#2772)
• Expand test suit to test actions-on-*

[aadcg]

Quote by @Ambrevar:

Full text search would be better. Montezuma could help.
Otherwise Xapian would be better, but there are no cl-xapian bindings as of this writing.