Customizable Prompt Buffer Placement (Top/Bottom) about nyxt HOT 3 OPEN

@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}.

from nyxt.

@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 #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.

from nyxt.

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.

from nyxt.