DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=D/zVrUfKuyEzEZn4
	+M7tq70eo1cmu7J9KChuQ2yDR3G6sqbCoWwodoAa/ySMjxqEt5xQDLlGZhRyd4jh
	19zDuCmowUYuYoHSFLIsUic4GlirYIYycitxbP7woNG8yvLF+pSFP3cG7f4mMXWQ
	YynKUL3NGMMz0v5YhfLk00J6m6I=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Wed, 4 Jul 2018 02:40:51 +0300
From: Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To: cygwin AT cygwin DOT com
Message-ID: <519069560.20180704024051@yandex.ru>
To: Thomas Wolff <towo AT towo DOT net>, cygwin AT cygwin DOT com
Subject: Re: [ANNOUNCEMENT] Updated: mintty 2.9.0
In-Reply-To: <9e3c9045-4d02-cd66-dae1-8558cdf2a14f@towo.net>
References: <announce DOT f1fa99f9-4d45-8314-50ed-ac95b79dd43d AT towo DOT net>   <87zhz9bcyt DOT fsf AT Rainer DOT invalid>  <99897D710406F142A5DE486B0F3B7BC101461E7DBB AT EMP-EXMR203 DOT corp DOT leidos DOT com>  <09aedfda-f35b-5c33-6bef-cef52c9f041c AT towo DOT net> <87va9wi4pb DOT fsf AT Rainer DOT invalid>  <9e3c9045-4d02-cd66-dae1-8558cdf2a14f AT towo DOT net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

term "screen-256color"
termcapinfo *-256color* 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
defbce on
altscreen on

>> 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.

Yeah, that's a path that could spiral out of control quite fast.


-- 
With best regards,
Andrey Repin
Wednesday, July 4, 2018 2:32:10

Sorry for my terrible english...


--
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