C-w while in a textbox makes me sad

This one is a bit meta: it’s about editing text in this very textbox, the Nyxt forum new-post one.

I was writing a multi-hundred-word post (my immediately previous one), when I needed to cut a line, move to the end of my text, and paste. I selected the line, then, since I long ago chose Emacs bindings, I confidently hit C-w for kill-region (approximately equivalent to ‘Cut’).

The whole page disappeared. Closed by Nyxt, as if I’d used the CUA binding for ‘close window’ rather than the Emacs binding for kill-region.

I couldn’t restore the closed page with the text in the textbox either. My work was gone.

This. Must. Never. Happen.

Ever.

Luckily, Nyxt crashed soon after, and when I returned to the Nyxt forum start page and clicked “New Post”, hey presto, my post was back, in exactly the state it was in when I wanted to kill that line before. So restore was obviously always possible, just not accessible. That’s pretty bad too, but not as bad as (apparently) discarding my work without any warning as a result of ignoring my express key-binding preference.

So… how can I be assured that this will NEVER happen again, and that my preferred bindings will not be discarded or overridden in textbox-editing mode?

Hi Phil, I’m really sorry to hear that. I know that is super annoying when the browser does exactly the opposite of what you expect. How would we fix this problem?

We could ALWAYS ensure we are in input-edit-mode when a textbox is selected. We don’t currently do this, but we should. I’m not sure how to do it exactly, which is why we haven’t yet done it :smiley:

Another option of course is to add an option for a prompt (like in other browsers), that asks you to verify before deleting a buffer with unsaved input field data.

I should note that in the interim, you can try something like save-input-data and then invoke set-input-data-from-saved.

Another way to disable the C-w would be to bind it to 'nothing or nil in cua map. The approximate snippet would be

(define-configuration base-mode
  ((keymap-scheme
    (let ((scheme %slot-default%))
      (keymap:define-key (gethash scheme:cua scheme)
        "C-w" 'nothing)
      scheme))))

Thanks for that. I’ll try it.

What I don’t understand is why there is a CUA map in memory anywhere once I have set my preference for Emacs bindings. This seems like a bug.

Well… We consider Emacs bindings to contain CUA bindings as a subset, to have more keybindings to do stuff with. The same is with VI bindings – those include both Emacs and CUA bindings.

This, however, causes some collisions and problems, so maybe we should reconsider it.

Uh-huh. I can see the line of reasoning, but, as you say, it causes collisions and, as in my report, drastically unexpected behaviour leading to loss of work. If there were seriously glaring gaps in either Emacs or Vi(m) bindings it might make sense to have CUA as a backstop, but I don’t think there are such gaps. If there is anything you can currently do only with a CUA binding with no equivalent in the Emacs map, then the right thing is to add the missing Emacs map binding. The existing setup feels deeply confusing.

Perhaps a good first step, if it doesn’t exist already, would be a table of all standard bindings, where we can see at a glance what bindings if any are missing in each map.

Actually, CUA is under-featured, compared to Emacs/VI map–it has less bindings and those are usually basic :slight_smile:

But yes, I’ll open the issue on separating CUA, VI, and Emacs maps.