delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
DomainKey-Signature: | a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id |
:list-unsubscribe:list-subscribe:list-archive:list-post | |
:list-help:sender:subject:to:references:from:message-id:date | |
:mime-version:in-reply-to:content-type | |
:content-transfer-encoding; q=dns; s=default; b=xjSl7fcaV8KFWTG+ | |
TeBE+MCCXl+UlMqIe81RF9xEC/JTe5AhUkmHZvTXYWSVTcdbicUHwfgcPpotPIH4 | |
6xQ7/o9E+WOIoAtLOGW7cvKjRPqrqzJTJS/EPuykn+Uh8duGjD1jHZE/D08r7VBy | |
otf+xg/RohOwD4b0kdEhFaXcpZk= | |
DKIM-Signature: | v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id |
:list-unsubscribe:list-subscribe:list-archive:list-post | |
:list-help:sender:subject:to:references:from:message-id:date | |
:mime-version:in-reply-to:content-type | |
:content-transfer-encoding; s=default; bh=jFRNDXHlnp6Hq+kq08a1ZP | |
fFDJw=; b=GIqG+PPCkKMri9UUZJsuaHj9oTBAXUaCEQe9I93oivCXcS8SBe15yb | |
VNCCaCywUby9odiDOY2zbLUBu84S6ZS36w8Fea1GYpcNoOVmC0HCODDtQv15OUsY | |
tiPxjZ++VVkSF1XVuHhx3mZB/++eMHKp/tEChcUXTyYUqyI1T99rE= | |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
List-Archive: | <http://sourceware.org/ml/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
Sender: | cygwin-owner AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
Delivered-To: | mailing list cygwin AT cygwin DOT com |
Authentication-Results: | sourceware.org; auth=none |
X-Virus-Found: | No |
X-Spam-SWARE-Status: | No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=xterm, stayed |
X-HELO: | limerock01.mail.cornell.edu |
X-CornellRouted: | This message has been Routed already. |
Subject: | Re: Latest Cygwin update and Emacs in Mintty |
To: | cygwin AT cygwin DOT com |
References: | <87wpciktid DOT fsf AT Rainer DOT invalid> <87o9tqs8c8 DOT fsf AT Rainer DOT invalid> <40991a4b-1e1c-4d03-f70f-8c77eb29bc7b AT cornell DOT edu> |
From: | Ken Brown <kbrown AT cornell DOT edu> |
Message-ID: | <840056d7-6365-97bb-96d0-cca35aaff925@cornell.edu> |
Date: | Thu, 15 Jun 2017 09:35:01 -0400 |
User-Agent: | Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 |
MIME-Version: | 1.0 |
In-Reply-To: | <40991a4b-1e1c-4d03-f70f-8c77eb29bc7b@cornell.edu> |
X-PMX-Cornell-Gauge: | Gauge=XXXXX |
X-PMX-CORNELL-AUTH-RESULTS: | dkim-out=none; |
X-IsSubscribed: | yes |
On 6/15/2017 6:47 AM, Ken Brown wrote: > On 6/14/2017 3:00 PM, Achim Gratz wrote: >> Achim Gratz writes: >>> After the latest Cygwin update I'm hitting an interesting problem with >>> emacs-nox running in a mintty: when Emacs starts, it decides that the >>> background color is gray instead of the usual white (for all but the >>> rightmost character in the status line, interestingly enough). I have >>> the normal mintty background set slightly off-white (to #F8F8F8) and >>> mintty reports itself as xterm-256color (the same happens in when TERM >>> is set to screen-256color). Emacs starts up with the correct background >>> color, draws the status bar and the menu bar and only then switches the >>> background to gray. The gray it choses is very slightly lighter than >>> the status bar (so lightly in fact that I can make out the difference on >>> only one of my three monitors). Emacs really thinks it is using a white >>> background, as evidenced by the fact that (set-background-color "white") >>> will produce exactly the same result. I get my usual background back >>> with (set-background-color "#F8F8F8"), but I have no idea where the >>> wrong setting for the named color "white" comes from. >>> >>> I'm just trying this at home remotely logging in from a konsole terminal >>> on my Linux box: Here the background chosen is slightly darker than the >>> status bar, the status bar seems to be #B8B8B8 and the background for >>> "white seems to be #B4B4B4. Curious and curiouser... >> >> Ken, did you have a chance to look into this? > > Sorry, I must have missed this when you first sent it. I'll take a look. I also see some strange behavior, but I can't reproduce what you're seeing. Here's what I tried: 1. I edited .minttyrc to set BackgroundColour=#F8F8F8. (ForegroundColour is 0,0,0, which I guess is the default.) 2. I ran 'emacs-nox -Q'. The background color didn't visibly change; it's still off-white. The mode line and menu line appear to be reversed (black background, off-white foreground, though I can't really be sure that the foreground is off-white rather than white). 3. I evaluated (set-background-color "white"). This caused the background to turn gray. The mode line and menu bar didn't visibly change. 4. I evaluated (set-background-color "#F8F8F8"). The background stayed gray. I need to investigate 3 and 4, but first I'd like to understand why you and I are seeing different things. One difference is the value of TERM. You say "mintty reports itself as xterm-256color". Do you mean it does this by default, or do you have something in your startup files that causes this? When I start mintty, I get the following: $ echo $TERM xterm Ken -- 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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |