bugGNU nano - Bugs: bug #48659, of several commands typed during...


bug #48659: of several commands typed during loading, only the first is executed

Submitted by:  Benno Schulenberg <bens>
Submitted on:  Sat 30 Jul 2016 09:53:47 AM UTC  
Severity:  2 - Minor Status:  Fixed
Assigned to:  Benno Schulenberg <bens> Open/Closed:  Closed

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Tue 23 Jan 2018 05:15:12 PM UTC, comment #10:

Fixed in git, commit e739448c.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 20 Jan 2018 06:40:17 PM UTC, comment #9:

Attached is a first version of a patch.

(file #42991)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Wed 12 Jul 2017 05:47:10 PM UTC, comment #8:

First test whether the Ctrl+Arrow keys work elsewhere. Type a few random words on the command line, then use Ctrl+Left and Ctrl+Right to jump around in them. Does that work? And do those same keystrokes work in vim? If they don't, and they do work when using Terminator, that should be clear enough as a bug report.

(But check first if maybe the terminal allows the keys to be configured, or rebound. There are some terminal emulators that have a configuration tab somewhere.)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Wed 12 Jul 2017 04:41:04 PM UTC, comment #7:

Good to know MATE Terminal is deficient. What would be the most effective way of phrasing a bug report??

I've tried Ctrl-Right in Terminator, and it works there. Also, no problem on the buffering. (F9 in Mate Terminal also no problem.)

Peter Passchier <pepa65>
Wed 12 Jul 2017 04:15:54 PM UTC, comment #6:

> I didn't see the significance of Ctrl-Right,
> that does the same thing as Right here...

Ah. Then you have a "deficient" terminal. Since nano-2.5.0 Ctrl+Left and Ctrl+Right should jump to previous and next word on most terminals.

I used Ctrl+Right as an example because it is most likely to produce an escape sequence. ^K will produce a single integer, so that will not trigger the effect. You can try it with F9 (which should do the same as ^K when you use --ignore) -- maybe the function keys still produce escape sequences.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Wed 12 Jul 2017 10:35:04 AM UTC, comment #5:

Ubuntu 16.04
GNU nano, version 2.5.3
mate-terminal 1.16.3-1~xenial1.0

No problem here.

Disclaimer: I used "nano -I" but I didn't see the significance of Ctrl-Right, that does the same thing as Right here... But using ^K had the expected result of cutting the lines to the buffer (and ^U pastes them back.)

Peter Passchier <pepa65>
Wed 12 Jul 2017 09:31:22 AM UTC, comment #4:

No, we can't just continue interpreting the input, because we haven't kept a record of how much of the input we have consumed during the interpretation of a sequence. That is why the counter needs to be built in. Which is going to be messy and ugly.

But... the good news is: I've just tried the reproduction recipe (on a one-million-line file), and the problem is gone for me. Both on an Xterm and on a VTE-based Xfce terminal. (Not entirely on a Linux console, because there we need to use trickery to get the modifiers.) This is on Xubuntu 17.04. So... maybe we can just ignore this problem, and say: "if you want macros to work, you need a new enough distro". (It will still require adapting the current keyboard code to make it return a proper code for the shifted arrow keys, but that should be doable.)

For now, I need people to test the recipe on their terminals, to see whether typing ten times Ctrl+Right before nano has fully started up indeed places the cursor ten or eleven words into the file when the file is finally shown.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Wed 12 Jul 2017 01:06:35 AM UTC, comment #3:

In that case, isn't it just a matter of keeping existing processing, but not discarding the rest but keep interpreting the input using existing code?

Peter Passchier <pepa65>
Tue 11 Jul 2017 07:07:34 PM UTC, comment #2:

This isn't so easy. Well, on modern machines, with a new enough ncurses, the terminal doesn't produce escape sequences any more: each key is a single code. So there it would be dead easy to process just one integer at a time. But older machines still produce escape sequences, and to build into the interpretation code a counter for how many integers the sequence has eaten up and need to be skipped, that is... pfff, a mess.

From ncurses, we read one integer at a time. We cannot read sequence by sequence because we don't know how long the sequence is before we have fully interpreted it. So we read everything ncurses has available, and then interpret that -- and then stupidly assume that ncurses gave us a single sequence, and thus discard any remaining integers.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Tue 11 Jul 2017 02:06:46 PM UTC, comment #1:

This sounds like it should be easy to fix. Either read sequence by sequence from ncurses' buffer and interpret each in turn, or add ncurses' whole buffer into an internal input buffer and read/interpret sequence by sequence from there.

Is it possible to read by sequence from ncurses' buffer, or does it need to be read in a whole chunk?

I am eager to see this resolved, so bug #50314 can be worked on!

Peter Passchier <pepa65>
Sat 30 Jul 2016 09:53:47 AM UTC, original submission:

To reproduce, create a large file with 'for x in $(seq 131); do cat NEWS >>200thousand.c; done'. Then run 'src/nano +1,1 200thousand.c' and during loading type three times <Ctrl+Right>. When the file is finally shown, after a second or two, three, only the first of the sequence of commands has been executed. (Which can be verified by running 'src/nano +1,88 200thousand.c' and typing once <Ctrl+Right> and several times <Ctrl+Left>.)

This happens because, when keystrokes have accumulated in the input buffer of ncurses, nano takes in everything in that buffer at once, interprets only the first sequence, and forgets about the rest. It shouldn't do that. It should unget any bytes that weren't part of the interpreted sequence. Or it should take in each byte (or at least: try to) as the unfolding sequence requires it.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by pepa65 (Posted a comment)
  • -email is unavailable- added by pepa65 (Voted in favor of this item)
  • -email is unavailable- added by bens (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-01-30 bens Open/ClosedOpen => Closed
    2018-01-23 bens StatusIn Progress => Fixed
    2018-01-20 bens Attached File- => Added 0001-input-consume-only-the-actual-length-of-an-escape-se.patch, #42991
        StatusNeed Info => In Progress
        Assigned toNone => bens
    2017-07-12 bens StatusNone => Need Info
    2017-07-11 pepa65 Carbon-Copy- => Added pepa65

    Back to the top

    Powered by Savane 3.3