`switch-buffer` UI may be misleading about nyxt HOT 15 CLOSED

from nyxt.

We're discussing too many things. Let's stay on topic to find a solution before thinking too much ahead. All agree that the current state of the matter needs to be addressed as soon as possible.

Solutions

(@lansingthomas) I don't like having two sources here

Me neither, and my favorite solution is number 1 (from my top post). But the final decision is yours @lansingthomas obviously.

(@lansingthomas) If I look for an open buffer and then realize it has been closed, the next logical action is to create a new one

We agree on the what, but disagree on the how. If the user invokes the command switch-buffer only to realize that the buffer they're looking for doesn't in fact exist then:

1. The user must exit the prompt buffer that was raised when invoking switch-buffer;
2. Call the right command, among a universe of several possible ones - set-url, set-url-new-buffer, set-url-new-nosave-buffer, set-url-from-bookmark, etc.

In short, I think that the idea to add a way to open a new buffer from the context of switch-buffer is shortsighted. Also, the kind of solution you proposed (solution 3) is outside the scope of this issue. We don't support such a UI and this not the right place to discuss it.

Configuration

Making it configurable is an option, but it makes little sense to discuss configuration before settling on the default behavior.

(@MaxGyver83) Can't we just make this configurable? Something like: (define-configuration buffer ((switch-buffer-suggest-new-buffer t)))

A slot that sets the behavior of a command seems inappropriate to me.

(@aartaka) We had discussed configuring sources for commands elsewhere. That'll be the most reliable solution.

Yes, but that's outside the scope of this issue since it's a general topic.

from nyxt.

I also strongly prefer 1 as the default. It feels unnatural to scroll through open buffers and find that one of them creates a new buffer. And, as mentioned, there are numerous ways you may create a new buffer, but this limits you to only one. switch-buffers should only switch-buffers, by default, in my view.

from nyxt.

This time while searching for a buffer you thought was open, but actually wasn't.

For this use case, it would be nice if the set-url-new-buffer key binding would also work in the switch-buffer prompt. Even better if the typed filter query would be used as start value for the set-url-new-buffer prompt. (Obviously, the new prompt buffer should replace the old prompt buffer.)

from nyxt.

I didn't take note that this number is the buffer count plus one. I agree that this sum of buffers plus the "create new buffer" count is not so useful.

I don't need this "Create new buffer" source in switch-buffer. I had already asked in the forum how to remove it: Switch-buffer: Longer buffer list - Nyxt / Configuration Questions - Atlas. I use set-url-new-buffer when I want to open a URL in a new buffer. But I can understand that people want two commands in one, thus I wouldn't revert cc91712. Can't we just make this configurable? Something like:

(define-configuration buffer
  ((switch-buffer-suggest-new-buffer t)))

from nyxt.

from nyxt.

Good report @aadcg,

• I don't like having two sources here | (it seems cluttered, which distracts from the main task at hand {re-surfacing information})
• I do like having the option to create a new buffer in the switch-buffer menu | (If I look for an open buffer and then realize it has been closed, the next logical action is to create a new one)

Solution 3

present set-url or set-url-new-buffer as a suggestion (with some visual differentiation)

Could look like:

from nyxt.

We had discussed configuring sources for commands elsewhere. That'll be the most reliable solution.

I am interested in this. Can you point me in that direction? @aartaka

from nyxt.

#3032 this one?

from nyxt.

@irthomasthomas Thanks for chiming in. I agree with you.

@lansingthomas, we're awaiting your final decision.

from nyxt.

from nyxt.

decision

Good discussion here. I am convinced that Solution 1 is the best course of action at this time.

Reasoning:

1. one clear command for one clear purpose: switch-buffer ⇒ menu for switching buffers
2. reduces visual clutter created by extra bars in prompt buffer, to allow important space for buffer suggestions

thoughts for the future discussion about potential configurability of this feature

• I see including set-URL here as a shortcut that sometimes reduces keystrokes at the cost of clear separation of actions. So for some advanced workflows it could be a helpful feature.
• seems like a low priority to me, but my mind is easily changed by good arguments. (I commit to discussing it briefly with a few people on the team and reporting back here, or opening another issue if I hear any strong arguments).

Thank you all!
Nyxt forever!

from nyxt.

Good idea @MaxGyver83,

I too would like to access regular commands from an open prompt buffer like this.

My understanding is that the prompt buffer commands will supersede main buffer commands, but I don't know why the prompt buffer doesn't pass these commands through.

• currently prompt buffers will stack nicely if you create new ones without closing the first. Which effectively "replaces" the old one, then closes both when a selection is made.

from nyxt.

sometimes it will allow you to do both commands in a row, for example, run set-url twice, and it should stack two prompt buffer prompts.

from nyxt.

sometimes it will allow you to do both commands in a row, for example, run set-url twice, and it should stack two prompt buffer prompts.

That is possible when the focused buffer at the moment of issuing the "overlapping" command is not the prompt buffer. Example: try pressing C-l M-o M-l with the emacs keyscheme enabled. But that is not what @MaxGyver83 suggested. Our model doesn't allow what he suggested, and I don't think we should. Having the user explicitly exiting the prompt seems reasonable. If the user calls execute-command followed by set-url, what do they mean? Should executed-command be resumed or forgotten, once they exit set-url? In case of ambivalence, offloading the responsibility to the user is better. On top of that, a different set of commands is bound when the prompt buffer is being used. Again, it seems reasonable as to have more keys available for prompt buffer specific tasks. In short, I think the model we have is a good and solid basis for anyone that wants to change it (via extensions and/or configuration).

from nyxt.