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: Using Emacs in fbterm. Date: Mon, 29 Aug 2022 16:41:00 +0000 Message-ID: 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="2488"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 29 18:42:29 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 1oShqG-0000WY-LQ for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Aug 2022 18:42:28 +0200 Original-Received: from localhost ([::1]:51786 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oShqF-0001Wu-0j for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Aug 2022 12:42:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51734) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oShoz-0000HP-HZ for emacs-devel@gnu.org; Mon, 29 Aug 2022 12:41:09 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:60389) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oShou-00060t-KJ for emacs-devel@gnu.org; Mon, 29 Aug 2022 12:41:09 -0400 Original-Received: (qmail 86539 invoked by uid 3782); 29 Aug 2022 18:41:01 +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 18:41:00 +0200 Original-Received: (qmail 13842 invoked by uid 1000); 29 Aug 2022 16:41:00 -0000 Content-Disposition: inline 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:294287 Archived-At: Hello, Emacs. I think it's time to begin a new thread on fbterm, which isn't about undisplayable characters any more. Just as a matter of interest, I've amended my copy of the fbterm's source code so as to remove most of the "stolen" key combinations, leaving just S- and S- in place. These scroll the screen vertically, allowing one to view previous messages or commands. fbterm is hosted at GitHub, where there seem to be 28 forks of it, most of them, probably, being very slight differences from their forkees (is that a word?). So much for free software. ;-) In the GNU/Linux distribution I use, Gentoo, the version of fbterm is one of those forks. One change in it, made 7 years ago, was changing the setting of the environment variable TERM from "linux" to "fbterm". It seems that this will vary randomly between these forks, and also randomly between G/L distributions. There might be something in the terminfo setup to enable one to distinguish fbterm from the Linux console when TERM is "linux". 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. 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. Also the face mode-line-inactive is indistinguishable from the default face, so when there're more than one window in the frame, they are less easy to distinguish than they should be. -- Alan Mackenzie (Nuremberg, Germany).