drowsysword / mintty

Automatically exported from code.google.com/p/mintty
0 stars 0 forks source link

Command line alignment problem #355

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I'm sure this is a local issue, but I can't figure it out. Regardless of the 
TERM I use xterm, xterm-256, etc. If I type over a certain number of 
characters, there is an input line shift and I can't get to the beginning or 
end of the text to edit it. If I set the TERM=mintty it solves the problem, but 
breaks after a few minutes and the term is screwed up. 

What steps will reproduce the problem?
1. Open an Mintty terminal using shortcut.
     Target: C:\cygwin\bin\mintty.exe -

2. Type on the command line 1234567890|1234567890|1234567890|

3. Hit cntrl+a keys to get to the beginning of the line. It will place just 
have characters 1234. Hit cntrl+e it will go four character beyond the text. 

What is the expected output? What do you see instead?

I expect to be at the beginning and end of the text to be edited. Instead, I 
cannot see what characters are being edited at that position to edit those 
characters.

What versions of mintty, Cygwin/MSYS, and Windows are you using?
mintty --version
mintty 1.1.2

uname -a
CYGWIN_NT-5.1 #### 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin

Windows XP service pack 3

Please provide any additional information below.
Here is my .inputrc file:
# base-files version 3.2-1

# don't beep at me
# set bell-style visible

# the following line is actually
# equivalent to "\C-?": delete-char
"\e[3~": delete-char

# VT
"\e[1~": beginning-of-line
"\e[4~": end-of-line

# kvt
"\e[H":beginning-of-line
"\e[F":end-of-line

# rxvt and konsole (i.e. the KDE-app...)
"\e[7~":beginning-of-line
"\e[8~":end-of-line

set completion-ignore-case on

Original issue reported on code.google.com by stevem...@gmail.com on 14 Oct 2012 at 3:17

GoogleCodeExporter commented 8 years ago
Sounds like issue 191.

Original comment by andy.koppe on 19 Oct 2012 at 11:46

GoogleCodeExporter commented 8 years ago
You are correct. The PS1 prompt is what was doing it. In my case, the issue was 
text reset: "\e[0m". I'm not sure why this broke it. 

Thanks for the help. 

Original comment by stevem...@gmail.com on 19 Oct 2012 at 9:47

GoogleCodeExporter commented 8 years ago
Bash/readline needs to know what column the cursor will be at after printing 
the prompt, so that it can work out when the command line will wrap. Obviously, 
non-printing characters shouldn't be counted towards that, hence the 
requirement to enclose them in \[ and \]. I'd guess that it's done this way 
(rather than by having readline recognise control sequences itself) in order to 
keep readline fully terminal-independent.

See also http://www.gnu.org/software/bash/manual/bashref.html#Printing-a-Prompt.

(Btw, there is a control sequence for querying the cursor position from the 
terminal, but that can be slow and error-prone, particularly over slow network 
connections.)

Original comment by andy.koppe on 21 Oct 2012 at 5:00