<span class="editing"> prevents autocompletion about domterm HOT 3 OPEN

As a work-around, you can switch from auto mode to char mode.

I think the thing to do here is when we see a prompt, and we're in auto mode, and we're already in an "editing" span, switch back to char-mode. Maybe only if the prompt sequence indicates a non-zero edit-mode. Probably not difficult, assuming I can reproduce/test it - adding a delay like I use to test predictive echo might work.

I've been thinking abut how to integrate an input editor (like zle or readline) with readline. For zle the primary "selection" should be identical with the region, and the clipboard with the kill-buffer, similar to Emacs's integration. Shift combined with navigation keys would extend the selection/region. You'd need a new selection-region mode (in which unshifted arrow keys collapse the region). There are some security complications, at least on a regular browser (Electron or Qt may be different): Reading or writing the clipboard needs to be done in a browser event hander - it can't be done as a result of a request from the application (i.e. zle). (A work-around is to use xclip or similar in the server, but that is less portable.)

from domterm.

I'm having problems reproducing this, even when I add the send-delay (in DomTerm.connectWS). Perhaps I need to put in a delay somewhere else.

from domterm.

I think this is a way to trigger the problem: Just type sleep 1 and then starting typing a command before the prompt appears. I think the right thing is in this situation is turn off the _clientWantsEditing and convert existing input (in the editing) buffer to pending (tentative) input - after sending it to the client. Working on that.

from domterm.