"Floating" the prompt-buffer

Nyxt Questions
1

Opening the prompt buffer repositions a lot of elements, e.g. making it difficult to see what element hints points to.

I’d like to change it to “float” at the bottom instead, but I’m not sure how to do this. When I open the inspector, I’m unable to look at the prompt-buffer, which makes me think it’s somehow another part of the GUI and not added to the main html. In that case, I guess it’s impossible to make it float on top of the content?

2

@simendsjo it is possible to open the inspector for the prompt buffer, if you start Nyxt from the Common Lisp REPL. We don’t provide a user-facing way of doing it, but you can request it from us (it’s trivial to add it).

From the REPL, assuming you have a proper dev env:

(asdf:load-system :nyxt/gi-gtk)
(nyxt:start)
;; open the prompt buffer and issue
(ffi-inspector-show (current-prompt-buffer))

The prompt buffer is a buffer, just like the buffer that loads web pages. When you’re calling the Inspector, you’re calling it with respect to the web page buffer, not the prompt buffer. So, indeed, it is a separate entity.

It is possible to draw the prompt buffer elsewhere.

Nonetheless, let me try to approach your issue in a different way. You claim that when you call the follow-hint command, the prompt buffer occupies an important part of the screen. You should try our non-default hinting system.

(define-configuration nyxt/mode/hint:hint-mode
  ((nyxt/mode/hint:hints-alphabet "KDJFLSAIEUROWPQCMVXZ")
   (nyxt/mode/hint:hinting-type :vi)
   (nyxt/mode/hint:show-hint-scope-p nil)))

From the hinting-type docstring:

Set the hinting mechanism.
In :emacs, hints are computed for the whole page, and the usual prompt-buffer
facilities are available.
In :vi, the prompt-buffer is collapsed to the input area, hints are computed
in viewport only and they're followed when user input matches the hint string.

Another thing that you may want to request from us is a command that would toggle collapsing the prompt buffer to the input area. With that command in place, setting hinting-type to :emacs would be saner.

I’d be eager to listen to your experience on hint-mode. Our users are frequently confused about the default behaviour of the mode. You may find this discussion interesting.

3

Thanks! I’ll have to look at the prompt buffer inspection later.

:vi is pretty much what I’m used to from other browsers. But I do like that I can search for texts too though!

So I’d like a combination preferably:

  • No prompt buffer (:vi)
  • Only hints in viewport is added (:vi, mostly because it’s confusing otherwise)
  • Hints not matched is hidden (:vi)
  • Can search for other content too (:emacs)
  • Have to press enter to choose hint (:emacs, necessary because we can search for text)

I really doubt there can be one size fits all (or two sizes) here. Maybe we can identifiy features like the above and make them configurable separately? Runtime configurable would be best, because the :vi behavior is quickest when I don’t need the “search for text” feature.

4

I understand your sentiment, and we used to provide several options (but that approach has its shortcomings too).

There’s one conclusion that I’ve made to myself some time ago, and you have reached that very same conclusion. :vi and :emacs shouldn’t be a either/or kind of thing. We must provide a way to issue command follow-hint and be able to switch between these two hinting-types.

I’ll have to have a very deep and long thought about it. Probably not soon.