From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Using Emacs in fbterm. Date: Mon, 29 Aug 2022 18:44:26 +0000 Message-ID: References: <83czcjvtt2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37238"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 29 20:47:55 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oSjnd-0009T7-W8 for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Aug 2022 20:47:53 +0200 Original-Received: from localhost ([::1]:37416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oSjnc-0004Ap-GT for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Aug 2022 14:47:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49880) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSjkT-0002jx-4I for emacs-devel@gnu.org; Mon, 29 Aug 2022 14:44:39 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:63848) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSjkO-0008V2-RE for emacs-devel@gnu.org; Mon, 29 Aug 2022 14:44:35 -0400 Original-Received: (qmail 9810 invoked by uid 3782); 29 Aug 2022 20:44:27 +0200 Original-Received: from acm.muc.de (p4fe15978.dip0.t-ipconnect.de [79.225.89.120]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 29 Aug 2022 20:44:27 +0200 Original-Received: (qmail 18494 invoked by uid 1000); 29 Aug 2022 18:44:26 -0000 Content-Disposition: inline In-Reply-To: <83czcjvtt2.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:294294 Archived-At: Hello, Eli. On Mon, Aug 29, 2022 at 20:33:13 +0300, Eli Zaretskii wrote: > > Date: Mon, 29 Aug 2022 16:41:00 +0000 > > From: Alan Mackenzie > > > > There is a problem with colours in Emacs in fbterm. When one does M-: > > (defined-colors) it prints a list of just eight colours, black, red, > > ...., white. > > > > However, the face constructing mechanism seems to assume more than eight > > colours, and this seems buggy. > Face constructing makes no such assumptions. If the colors defined > for the face are not directly supported by the terminal (in this case, > not in the 8 colors), Emacs uses color-translation to find the closest > color that is supported. See tty-colors.el. If this translation > doesn't produce satisfactory results, the face colors need to be > either: > . changed such that (a) on color-rich terminals the colors are > similar, but (b) on 8-color terminals we get better results; or > . the face definition should be changed to have a separate setting > of colors for terminals with 8 colors > > The face hi-green, for example, rather than having background > > "green" gets "light green". This appears on the terminal as dark > > yellow, which is clearly wrong. > Why do you think it's wrong? hi-green MUST be green, otherwise, what's the point? What is wrong is the "light" in light green. It's simply "green" on the Linux console. Looking at the Lisp expression in customize-face, light green can only happen when (min-colors 88) is satisfied. > Given that yellow is closer to hi-green (judging by its RGB > components) than green, I see nothing wrong here. > > Also the face mode-line-inactive is indistinguishable from the default > > face > ??? It should be the same as mode-line face of the active mode line. > I wonder how come it's the same as the default in your case. Is that > in "emacs -Q"? It was, yes. I've made further progress in diagnosing this. If the environment variable TERM is "linux", the problems with the colours don't happen. If it's "fbterm", they do. So, I would guess that somewhere in the depths of the face construction, there's a test for TERM being "linux". Or, maybe, an inappropriate terminfo entry is getting used when it's "fbterm". Or something like that. Maybe the fbterm terminfo entry is inconsistent with fbterm itself. I think it's worth fixing, whatever it is. -- Alan Mackenzie (Nuremberg, Germany).