Customizable Prompt Buffer Placement (Top/Bottom)

[chaorace]

Is your feature request related to a problem? Please describe. I've moved the status buffer to the top position using the window.status-buffer-position slot. I want a similar slot which allows for moving the prompt buffer into an equivalent "top" position.

I want this new functionality because I dislike the way the prompt buffer currently obscures element hints which would appear near the bottom of the window. I'd rather the prompt buffer instead appear at the top because my workflow is not as negatively affected when element hints near the top are obscured. I also just happen to think that the UI flows better when both the status buffer & prompt buffer are spacially grouped together (currently only possible using bottom status buffer placement)

Describe the solution you'd like The new slot should shift the layout order of prompt-buffer-container within root-box-layout in a way similar to window.status-buffer-position (see referenced code below). More specifically: the prompt buffer should render directly below where the "top" position of the status buffer is currently.

https://github.com/atlas-engineer/nyxt/blob/3f5d1bdada48296182c14966ad07994b972e65db/source/renderer/gtk.lisp#L483-L484

Describe alternatives you've considered I tried to manually reorder the root layout to suit my own needs, but I couldn't seem to figure it out. The only thing I managed was causing the UI to momentarily flicker:

(let ((window (current-window)))
  (gtk:gtk-box-reorder-child
    (nyxt/renderer/gtk::root-box-layout window)
    (nyxt/renderer/gtk::prompt-buffer-container window)
    1))

Additional context Naming of this slot may be tricky due to the fact that window.status-buffer-position will be renamed to status-buffer.placement in v4. On the one hand, you might name the slot prompt-buffer.placement since that's evidently now a more correct naming scheme. On the other hand, you might name the slot window.prompt-buffer-position for the sake of parity and only rename it later on at the same time as window.status-buffer-position.

[aadcg]

@chaorace thanks for your report.

I dislike the way the prompt buffer currently obscures element hints which would appear near the bottom of the window

Are you aware that you can configure the hint-mode so that the prompt buffer doesn't take that space?

Try to add the following to your config file:

(define-configuration nyxt/mode/hint:hint-mode
  ((nyxt/mode/hint:hinting-type :vi)))

---

Regarding adding the ability to place the prompt buffer elsewhere, my opinion is as follows:

1. Nyxt's core should maintain and curate a single UI design. From top to bottom: main buffer, prompt buffer (when applicable), status buffer and message buffer.
2. If we were to provide a proper configurable UI parameter, then we must guarantee that it the acceptable values result in a proper UI as a whole (where the main, prompt, status and message are taken into account collectively). In other words, adding configurable parameters for each of the UI elements and allow the user to mix and match sounds like a bad idea to me. The idea is not to limit what is possible, but rather that a simple configuration parameters must lead to a proper and functional UI.

For context, I was against when we added the placement slot (see https://github.com/atlas-engineer/nyxt/pull/2713) for the status-buffer precisely because it leads to a half-baked solution. Again, if we were to add a simple configurable parameter that changes the UI then it would need to be a functional UI as a whole. The current state of affairs allows the status-buffer to be drawn at the top, but then the message-buffer is left in the wilderness.

I'm leaning towards reverting #2713 and encouraging interested parties to either write a Nyxt extension that provides an alternative UI or send a patch with a good alternative UI.

[chaorace]

I'm aware of the setting and that's indeed what I've resorted to doing. I'd still prefer to be using the default emacs-style prompt if only I could move it to where it would be least intrusive.

As for future stuff, I have two basic opinions as an end-user:

1. I think my ideal outcome would be having a way to functionally compose the layout & I'd argue that this would be most in the "Emacs spirit"
2. I acknowledge that a fully composable UI complicates the design process and makes the project as a whole less enjoyable to work on. If things need to be locked down, I personally think that's acceptable granted that a fixed set of sanctioned UI variants (no more than 3-4) exist that effectively cover reasonable usecases.

[aadcg]

@chaorace Thanks for your feedback. I'll take your view into account and sleep over it.

I have another tip as well, but you may be aware of it too. When the prompt buffer is up, you can scroll the main buffer with the keyboard. See commands scroll-other-buffer-{up,down}.