[ANNOUNCEMENT] Updated: mintty 2.9.0

Thomas Wolff towo@towo.net
Tue Jul 3 19:46:00 GMT 2018


Am 03.07.2018 um 19:56 schrieb Achim Gratz:
> Thomas Wolff writes:
>> I guess it's more about the configuration of tmux. There is in fact a
>> cursor style setting sequence that mintty newly supports.
>> Please make a terminal log and check whether ^[[34h (ESC [ 3 4 h)
>> appears during tmux initialization.
> I figured as much meanwhile, but I've not had luck in finding a
> description of that sequence until much later today (in the teraterm
> documentation).  I also fell into the trap again that you really can't
> recompile a terminfo entry and expect it to work until you've closed all
> mintty processes.
>
>> If so, however, the assumption is that tmux sends it on purpose, so
>> the blame is on tmux :/
> Not tmux, what you need to blame is the terminfo entry for
> screen-256color again, specifically the cursor_normal variable.  There
> are a bunch of other terminals using the same sequences though.  But I
> need to set the terminal to this exact string or colors inside screen
> (e.g. Emacs) don't work correctly (it falls back to some lower number of
> colors and gets completely illegible with the default theme).  Anyway,
> since I already needed to patch the stupid italics/bold swap in that
> terminfo entry, I just patched out this bit of nonsense as well.
As I cannot reproduce the exact scenario, I don't see yet where/how you 
set TERM=screen-256color and when the cursor would switch.
Also I notice that the xterm-256color entry is missing the Co entry 
(which is likely what you want), strange.

> BTW, for the terminal logs: it'd be nice if you could set a terminal log
> file from the extended context menu.  At the moment you can't actually
> activate the log (grayed out) unless you've started MinTTY with the
> appropriate option.
Such issues could also be discussed in the mintty chat 
https://github.com/mintty/mintty/issues/777
As mintty has always used a configured log file name (unlike xterm using 
a fixed pattern), the absence of one would be a design problem.

>> About an option to suppress dynamic changes of cursor style, that
>> might indeed be useful. I assume, though, that it should uniformly
>> also suppress the DEC sequence (DECSCUSR). Or should different cursor
>> attributes be addressable separately? (shape, blinking, colour??, even
>> hiding???)  Design proposals welcome.
> Well, one simple switchbox to "keep the cursor fixed at these settings"
> next to the other cursor settings would have saved me a few hours of
> heartburn.  Allowing to make each of them separately sticky would be
> nicer, but it's probably also a touch too much (besides, there's be a
> ton of other options that would then need the same treatment for the
> same reason).
I know I raised the idea, but having thought again, this could imply 
that a lot of settings might be markable as "fixed",
including all mode settings, character set settings, and others, to 
avoid accidentally confused settings for one or the other person.
I'm hesitating to take a step into such a direction.

Thomas


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple



More information about the Cygwin mailing list