Re: [Mlterm-dev-en] A few glitches.

[Araki K. <ara...@us...>]

 Thanks for your detailed report.

From: Andi Cristian Serbanescu <ski...@ya...>
Subject: [Mlterm-dev-en] A few glitches.
Date: Thu, 30 Aug 2012 06:23:49 -0700 (PDT)
Message-ID: <134...@we...>

> 1. After some text is output which is too long to fit in one line and
> then clearing the screen, the lines which were wraped around can still
> be selected with the mouse. Can be tested e.g. by typing random strings
> or by issuing ls -l in a directory with some long file names.

 The attached patch fixes this problem.

> 2. (May be related) Happens with some fancy shell prompts, if the path
> is part of the prompt, or the prompt itself is too long: a coloured
> prompt too long to fit in one line will also colour the cursor. May be
> tested (with bash) by setting the prompt to:
> 
> PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\] '
> 
> Sometimes you have to trigger behaviour 1 in order to activate 2.

 Indeed it looks strange, but xterm-279 reproduces the same problem
in my environment.
 For example, this problem happens by following steps.

1. bash whose PS1 is set as described above outputs following escape sequence.
   ESC[01;32m^Buser@host^AESC[01;34m^B ~/a/b/c/d/e/f/g/h/i/j/k/l/m $^AESC[00m^B
2. If screen is scrolled up between '~' and 'm' of the current path,
   the bottom lines including the cursor character are cleared with
   background-color-erase (bce) setting before bce attributes are reset
   by following ESC[00m.
3. The cursor character remains colored.

 I think it is difficult to avoid it because of the behavior of bce.
 If you use mlterm with --term=kterm option(kterm doesn't use bce), this
problem doesn't happen.

 If the problem you found is unique to mlterm, please inform me of it.

> 3. Double- and triple-click select one word/line at a time. However,
> double- and triple-clicking and then dragging the pointer will revert
> back to selecting one character at a time.

 As you mentioned, this behavior is not compatible with xterm, but it is
not easy to solve. It will take some time to think of the way to modify
source code.

> 4. Shift + PgDn (which scrolls down one screen) will output 2~ once it
> reaches the bottom. Shift + some other keys (Home, End, Delete, Left, 
> Up, Down, Right and maybe others) also display stuff, even though they
> don't do anything.

 The attached patch fixes this problem.

> 5. Some programs, such as mutt and nvlc (the ncurses interface for vlc)
> will display black text on black background instead of white on black
> (or whatever else you set fg/bg to). This one also happens with xterm
> and urxvt as far as I know.

 I haven't test mutt and nlvc yet, sorry.

> 6. I personally prefer to use the linux terminfo entry with mlterm, but
> it expects keys F1 to F5 to output something else than mlterm does, and
> there's no way to change it (e.g. via ~/.mlterm/termcap).

 How about following settings in ~/.mlterm/key ?

F1="\x1bOP"
F2="\x1bOQ"
F3="\x1bOR"
F4="\x1bOS"
---
Araki Ken
ara...@us...