quit-prompt-buffer keybinding does not show in the bindings column about nyxt HOT 7 CLOSED

I think it does make sense to invoke this command from the prompt-buffer (where else? :P)

I think I wasn't clear. Indeed, prompt buffer commands are invoked from the prompt buffer, but the question is: should they be listed in execute-command (or, in other words, should they be called by name)?

Remember that a command can be invoked by pressing the corresponding keybinding or by name (via execute-command). My point is that, generally speaking, it makes no sense to call prompt buffer commands by name. Imagine that you'd call command next-suggestion (bound to down arrow key) by name from execute-command - can you see what would go wrong?

Unless there is some other reason to maintain separation between prompt-buffer-commands and non-prompt-buffer-commands? -- I don't see this distinction in elsewhere in the documentation... please let me know if it exists and I am missing it, which is totally possible :D

As you soon as you answer the question I've left above, I think it will click. Does it make sense now?

We agree that quit-prompt-buffer should be called by name.

from nyxt.

I don't think this is a bug. All prompt buffer commands, such as quit-prompt-buffer, are excluded from the commands listed in executed-command. The reason is that is makes little sense to to invoke prompt buffer commands from the prompt buffer. Think about the consequences of listing command next-suggestion in execute-command. In short, this is a deliberate design decision.

What may be open to discussion is that quit-prompt-buffer, a very particular prompt buffer command, should be listed in execute-command. It would easy to do it. Does that confuse the user? If most prompt buffer commands are not shown, should we make this one exception? The prompt buffer can be intuitively closed via the mouse.

from nyxt.

Ciao @aadcg ,
thx for clarification.

I think it does make sense to invoke this command from the prompt-buffer (where else? :P) → we should list it in the Bindings Column

Unless there is some other reason to maintain separation between prompt-buffer-commands and non-prompt-buffer-commands? -- I don't see this distinction in elsewhere in the documentation... please let me know if it exists and I am missing it, which is totally possible :D

BONUS effect:
users typing familiar commands into the prompt buffer (part of exploring a new system) will see the name of the command "quit-prompt-buffer" associated with esc

• this connection between the familiar keybinding and our special name for the magical window (prompt-buffer) could be a gentle clue for them that they are using a thing called prompt-buffer

from nyxt.

After taking a deeper look at this, the key observation is that prompt buffer commands can be called by name via run-prompt-buffer-command - a command that isn't also listed in execute-command, i.e. it can't be called by name.

When it comes to calling commands by name, why are prompt buffer commands special? Because they behave differently. For example, compare make-window and next-suggestion and notice that the latter doesn't exit the prompt buffer.

There are at least two ways to think about this.

Prompt buffer commands would be listed in execute-command, granted that they would be handled differently. While possible, it feels goofy. When the user calls execute-command, prompt buffer commands are not what he's looking for.

The model we follow says that prompt buffer commands are excluded from execute-command. Prompt buffer commands can be called by name via command run-prompt-buffer-command. I think this model is great.

The only thing that may be lacking is that, while quit-prompt-buffer and run-prompt-buffer-command are prompt buffer commands, it would make sense to list them in execute-command so that they can be called by name.

EDIT: My attempt to add some exception commands (such as quit-prompt-buffer) proved to be harder than I've expected. In short, Nyxt's architecture is deeply committed to the command schism and introducing an ad-hoc exception mechanism would be even worse.

To do it properly, it would require some more time and thinking but we can't afford at the moment since there are more pressing issues.

If anyone is interested, my attempt can be seen in this branch.

from nyxt.

Thank you for getting into this Andre.

When I first reported this I was seeing the name quit-prompt-buffer... named in the execute-command menu! With no binding information.

However, today (3.6.0), I do not see it. Which is fine.

Im not to worried about this one but it does seem a bit strange.

Thanks again. Please decide if you want to leave this issue open or close it, I am satisfied.

from nyxt.

When I first reported this I was seeing the name quit-prompt-buffer... named in the execute-command menu! With no binding information.

Are you saying that you saw quit-prompt-buffer listed as a command in execute-command? I can guarantee you that you have never seen it because it that was never the case! But I understand why its absence seems odd at first sight.

from nyxt.

@jmercouris closing?

from nyxt.