[ANNOUNCEMENT] Updated: mintty 2.9.0
Tue Jul 3 23:50:00 GMT 2018
Greetings, Thomas Wolff!
> 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.
I have this stuff in my .screenrc
termcapinfo *-256color* 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
>> 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
> 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.
Yeah, that's a path that could spiral out of control quite fast.
With best regards,
Wednesday, July 4, 2018 2:32:10
Sorry for my terrible english...
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin