Paste buffer insertion not curses compatible

[GoogleCodeExporter]

What steps will reproduce the problem?
1. start vi (possibly any curses based interactive application) in minTTY.
2. enter insert mode
3. paste a multi-line buffer

What is the expected output? What do you see instead?
Expected: all lines of paste appear in vi
Actual: only the first line appears

What version of the product are you using? On what operating system?
minTTY 0.3.0, Windows Vista

Please provide any additional information below.
The paste_hold (variable) mechanics in minTTY require that the console
application push an EOL (either CR or LF) to the terminal to signal
successful completion of the partial (single line record) paste.  Only
after this signal does the paste continue with the next line record.  While
this works at the commandline where the bash (or any other) shell is
expected to honour a CR/LF input by emitting the same, under curses this is
not expected behaviour.  Under curses, the terminal may never get an EOL
but instead get cursor position movement sequences.

Some experimentation suggests that paste_hold can simply be disabled and
correct behaviour under curses is achieved.  However, this results in a
slight loss of input-to-output synchronization under a normal (bash) shell
prompt.  That is: the original behaviour using paste_hold provides a
throttling mechanism that better preserves the correlation of a single line
of input to its output.  Ideally, if the terminal could detect that it was
being driven by curses through some sort of ioctl/stty setting, the
paste_hold mechanism could be conditional upon that.

Original issue reported on code.google.com by avade...@certicom.com on 1 Jan 2009 at 4:37

[GoogleCodeExporter]

Original comment by andy.koppe on 2 Jan 2009 at 10:05

• Changed state: Accepted
• Added labels: Component-Logic, Milestone-0.3.2, Priority-High

[GoogleCodeExporter]

Thanks for the excellent bug report! Fixed in r80 on branches/0.3.

Going back through revision history showed that the bug was introduced by a 
change to
term.c in r21. Removing paste_hold does indeed do the job for fullscreen apps, 
and
actually it also appears to improve matters on the command line. Previously, 
when
pasting two command lines the first one might appear twice, e.g.:

0 ~/Projects/mintty/branches/0.3
gcc config.c -c -MMD -MP -include std.h -std=gnu99 -Wall -Wextra -Werror 
-DNDEBUG
-march=i586 -mtune=pentium-m -fomit-frame-pointer -Os -DVERSION=0.3.0
gcc child.c -c -MMD -MP -include std.h -std=gnu99 -Wall -Wextra -Werror -DNDEBUG
-march=i586 -mtune=pentium-m -fomit-frame-pointer -Os -DVERSION=0.3.0

0 ~/Projects/mintty/branches/0.3
gcc child.c -c -MMD -MP -include std.h -std=gnu99 -Wall -Wextra -Werror -DNDEBUG
-march=i586 -mtune=pentium-m -fomit-frame-pointer -Os -DVERSION=0.3.0

Without paste_hold, the first child.c line no longer appears. I think that's 
because
the I/O via the pty already provides the necessary throttling.

Original comment by andy.koppe on 3 Jan 2009 at 9:26

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by andy.koppe on 4 Jan 2009 at 10:01

• Changed state: Verified