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: Display of undisplayable characters: \U01F3A8 instead of diamond Date: Fri, 2 Sep 2022 11:12:32 +0000 Message-ID: References: <87edx28cl1.fsf@disroot.org> <83y1v7w6eu.fsf@gnu.org> <2f302d1c3966849477b3@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28444"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , eliz@gnu.org, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 02 13:17: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 1oU4gN-0007Fk-5G for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Sep 2022 13:17:55 +0200 Original-Received: from localhost ([::1]:58714 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oU4gL-0007S8-RC for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Sep 2022 07:17:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43900) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oU4bQ-0004O4-Gy for emacs-devel@gnu.org; Fri, 02 Sep 2022 07:12:50 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:21618) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oU4bM-000548-Ag for emacs-devel@gnu.org; Fri, 02 Sep 2022 07:12:48 -0400 Original-Received: (qmail 50712 invoked by uid 3782); 2 Sep 2022 13:12:33 +0200 Original-Received: from acm.muc.de (p2e5d5e67.dip0.t-ipconnect.de [46.93.94.103]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 02 Sep 2022 13:12:32 +0200 Original-Received: (qmail 7019 invoked by uid 1000); 2 Sep 2022 11:12:32 -0000 Content-Disposition: inline In-Reply-To: <2f302d1c3966849477b3@heytings.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.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:294531 Archived-At: Hello, Gregory. On Fri, Sep 02, 2022 at 07:28:51 +0000, Gregory Heytings wrote: > > > > I don't see how it could be simpler than using a Linux console, since > > that is as simple as could be. I have 8 of them, and to use one, I just > > type the character that switches. > > > That won't change. That is true. > > > > ISTR seeing a discussion about whether fbterm "steals characters". > > > It doesn't, when configured properly. Though it has to be said that this configuration is actually disabling part of fbterm. It is a hack. > >> Is there a reason why you cannot (or do not want to?) use fbterm? > > 1. It will be different > > 2. I don't have any idea how to use fbterm. > > 3. I odn't know what new inconveniences it would cause. > How to install and configure it is documented in efaq.texi (on latest > master and emacs-28), around line 3050. Doing that will take you less > time that you've already spent on trying to find a way to change the way > Emacs handles nondisplayable characters on Linux consoles. If you need > help, feel free to ask, either here or privately. > What you'll get is: > 1. Full UTF-8 support, i.e. no "undisplayable" characters anymore. Yes. > 2. 256 colors instead of 8. Well, actually instead of 16, since all the colours come in a normal and a bright version. But these 256 colours will be getting used, and that means work configuring faces that are not satisfactory to the user in the 256 colour version. > 3. Modern fonts instead of pixelated ones. Here's the rub. The "pixelated" fonts were designed to be used in, say, an 8x16 matrix, and work very well indeed. The "modern" fonts were designed to be used in X, and work less well in fbterm on a pixelated grid. All of the "modern" fonts available for fbterm on my machine are "spidery" single pixel thick fonts. On the lat1-16 font I've been using in consoles for decades, the lines are two pixels thick. I find this much more readable. On some of the fonts I tried, full-frame windows were only 61 rows high rather than the normal 65. Some of them were so dark as to be effectively unreadable. None of them were really satisfactory. > There are no known inconveniences. There are several. As mentioned above, you have to configure faces, possibly a lot of them. There are all the problems with fonts. You've got to remember to hack the fbterm binary each time a new version of fbterm comes out (unless you've got a system like Gentoo, and arrange for this to happen automatically). There will likely be people who use an unhacked version of fbterm, with its key sequences, and they cannot run Emacs on such. They will possibly get confused if they need both hacked and unhacked versions of fbterm together on one machine. I had problems with fbterm working on my ISP's server over ssh. The program at the far end didn't recognise TERM=fbterm and gave up. I had to call ssh as $ TERM=linux ssh .... to get it to work. There are lots of itty-bitty things you've got to get used to to use Emacs in fbterm, and it is more inconvenient than the plain Linux console where you need merely to log on and type $ emacs. Likely there will be more little problems with fbterm turning up. I will probably continue using the plain Linux console, for all these reasons. I agree with Richard that there should be an option for displaying characters outside of the current font as "�" rather than "\u2022". It is a feature of the Linux console that all such characters are displayed that way. There is no possibility of any character causing an undefined action. -- Alan Mackenzie (Nuremberg, Germany).