Re: [Nano-devel] [bug] character insertion when holding Alt

[David Lawrence Ramsey]

Benno Schulenberg wrote:

<snip>

> When holding down certain Alt-key combinations, the character of the
> held key gets inserted now and then into the file being edited.
>
> For example, open with nano the ChangeLog in current CVS, go to the
> end of the file, switch on the constant cursor position display, then
> press and hold Alt+Spacebar -- and watch how here and there a space
> gets inserted.
>
> It also happens when holding Alt+- or Alt+= for a while.  But only in
> big files, and when constant cursor position display is switched on.

This is a known problem, but I have no idea how to properly fix it.  By
all rights, if the keyboard buffer gets full and keys are lost, it
should be losing them in the proper order.  For example, a stream of ^[
(Escape) -'s should end with an escape if some of its keys are lost.  If
it did, then everything would still work properly, since Escape followed
by one character will work regardless of any delay between the two. 
Maybe someone who knows more about this can clear it up?

> Another occurrence is when repeating a search: search for example for
> "Fix typos", then press and hold Alt+W.  It happens in any large file
> with any string that occurs seldomly.  Also without constant cursor
> position display.

This was why F16 was added as an alias for Meta-W: you can hold it down
without causing this problem because it's one key instead of two keys
masquerading as one.  However, it's only a workaround, since there are
only so many function keys past F12 that we can use (and which most
terminals support; for example, the Mach console doesn't appear to
support any function key past F10).

> Calculating the cursor position and searching the entire file seems to
> take so much time that one or several keystrokes accumulate in a
> buffer, but without their Alt-component being registered.

This is something that can be fixed, but not in time for nano 1.4.  nano
currently calculates the cursor position in terms of characters by
getting the length of every line before the cursor, followed by the
length of the current line up to the cursor position.  This is of course
horribly inefficient, but with the current design, it's the only way
that will work.  The 1.6 rewrite uses a completely different structure,
under which there may be a more efficient way to get the current
character in the file.  I don't know for sure, since there aren't any
references to totsize in it; DB, any comments?

So, unfortunately, in the meantime, either don't hold down the
problematic keys or turn constant cursor position display off on
problematic files.  Sorry I couldn't be more help, but if I really knew
how to fix this, I would have done it by now...