public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Thomas Wolff <towo@towo.net>
To: cygwin@cygwin.com
Subject: Re: Mintty text glitches when using up key
Date: Fri, 28 Aug 2020 10:33:45 +0200	[thread overview]
Message-ID: <4214ab62-9f2c-0c9d-26f1-5fff8ec2c376@towo.net> (raw)
In-Reply-To: <c064a9ce-ec21-ff87-29a2-c9f6a510b773@SystematicSw.ab.ca>

Am 27.08.2020 um 21:55 schrieb Brian Inglis:
> On 2020-08-27 10:55, Hamish McIntyre-Bhatty via Cygwin wrote:
>> For a while I've noticed that if I run a long command (usually has to
>> wrap to next line down), that my Mintty session often becomes all messed
>> up if I use the up arrow keys to try and run it again later. Has anyone
>> else experienced this?
This description is quite fuzzy. It could be that you resized the window 
while a program was running, or that some background process sends 
output to the screen asynchronously. In such cases, the shell loses 
track of the cursor position and line editing fails. That's not a 
terminal issue.

>> Another, probably unrelated, observation is that if a command produces a
>> lot of long lines that get wrapped, if I make the Mintty window wider,
>> the lines stay wrapped. This behaves much like other terminal emulators
>> I used in the past, including gnome-terminal. At some point, this was
>> fixed in gnome-terminal, so I wonder if that fix would be relevant here too.
This was requested to mintty already 
(https://github.com/mintty/mintty/issues/82) but it's not a traditional 
terminal feature, so if some terminals have added it as an enhancement, 
that's not a "fix".
Thomas

>>
>> Unfortunately I know precious little about how terminal emulation works
>> so I'm not likely to be able to provide a fix, but I'm interested to see
>> if anyone else has experienced this or has found workarounds. It seems
>> to happen with both 32-bit and 64-bit Cygwin for me.
> Not a problem with long lines - often find myself editing a few lines down in a
> few hundred characters long after some iterations - I type without thought:
>
> 	$ history | tail > ~/bin/script
> 	$ vim + !$
>
> Problem is when you type ahead too fast, hit modifier keys and/or special
> functions by mistake in the wrong place, and/or when something else is running
> in the background, or the system is loaded, and mintty does not grab the whole
> escape sequence to process; often just running reset will restore sanity.
>
> [For real fun with mintty, type: $ echo `/usr/bin/env /usr/bin/python`
> You can kill python from another terminal window or TaskMgr.]
>


  reply	other threads:[~2020-08-28  8:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-27 16:55 Hamish McIntyre-Bhatty
2020-08-27 19:55 ` Brian Inglis
2020-08-28  8:33   ` Thomas Wolff [this message]
2020-08-28 14:31     ` Hamish McIntyre-Bhatty
2020-08-28 15:13       ` Thomas Wolff
2020-08-28 15:48         ` Hamish McIntyre-Bhatty
2020-08-28 16:45           ` Thomas Wolff
2020-09-02 15:28             ` Hamish McIntyre-Bhatty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4214ab62-9f2c-0c9d-26f1-5fff8ec2c376@towo.net \
    --to=towo@towo.net \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).