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: character sets as they =?utf-8?Q?relat?= =?utf-8?B?ZSB0byDigJxSYXfigJ0=?= string literals for elisp Date: Tue, 5 Oct 2021 11:20:47 +0000 Message-ID: References: <87v92ft9z6.fsf@db48x.net> <87o885tyle.fsf@db48x.net> <83k0it6lu5.fsf@gnu.org> <87k0isu7hz.fsf_-_@db48x.net> <87a6jotszy.fsf@db48x.net> <875yuctout.fsf@db48x.net> 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="32240"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Daniel Brooks Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 05 13:25:03 2021 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 1mXiZC-00089p-Rw for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Oct 2021 13:25:02 +0200 Original-Received: from localhost ([::1]:60890 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mXiZB-0006na-DA for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Oct 2021 07:25:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33088) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXiVD-0008UZ-Fz for emacs-devel@gnu.org; Tue, 05 Oct 2021 07:20:55 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:35488 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mXiV9-0002kC-Qb for emacs-devel@gnu.org; Tue, 05 Oct 2021 07:20:55 -0400 Original-Received: (qmail 16280 invoked by uid 3782); 5 Oct 2021 11:20:48 -0000 Original-Received: from acm.muc.de (p4fe15b3d.dip0.t-ipconnect.de [79.225.91.61]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 05 Oct 2021 13:20:48 +0200 Original-Received: (qmail 4732 invoked by uid 1000); 5 Oct 2021 11:20:47 -0000 Content-Disposition: inline In-Reply-To: <875yuctout.fsf@db48x.net> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; 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 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:276317 Archived-At: Hello, Daniel. On Mon, Oct 04, 2021 at 15:19:22 -0700, Daniel Brooks wrote: > Alan Mackenzie writes: > >> PS: it occurs to me to wonder if my use of Unicode in the prose of this > >> message, outside of the examples, detracted from its readability in any > >> way? > > It does for me. > Aha! I’m rather astounded that this is the case, but happy to know that > we are talking about a use–case that actually affects real users, as > opposed to merely hypothetical ones. Thank you! > >> I am asking if anyone reading my messages, either this one or any of the > >> last dozen I have sent to the list, have noticed any specific > >> problems. I have used non–ascii characters in all of them. I’m wondering > >> if anyone even noticed. If nobody noticed, or if they didn’t detract > >> from readability, then it is unlikely that Unicode is a problem in > >> general. > > These characters displayed as inverse question marks on my Linux console. > > I can understand people wanting their non-ascii names to be properly > > spelt (just as I prefer my non-ascii home city Nürnberg to be correctly > > spelt). > > What I don't really understand is including punctuation characters which > > can't be typed on the writer's keyboard, except by awkward workarounds. > You are making unwarranted assumptions about my keyboard :D Indeed, yes. ;-) > But alas, it’s fairly ordinary; I don’t actually have the keyboard of my > dreams. Instead, there are some xkb options that I turn on to make it > more capable. To type a ｢"｣ I have to press S-', while to type ｢“｣ I > press Level3-k; it’s a different pair of fingers, but not really any > more difficult or awkward to type. So, you've set up your keyboard specially to be able to type these things easily. I think we can be sure that a lot of your readers won't have done the same. I've set up mine to be able to type ä, Ä, ö, Ö, ü, Ü, and ß. > > One of the reasons I use Linux is because I have a 16 x 8 dot fontset, > > and don't have to cope with all the vagaries of fancy, sometimes blurred, > > fonts used on GUIs. There are quite a few others. Why use a graphical > > environment for doing text work? > I use a GUI precisely because the range of characters is so much wider, > making the text work more fun. OK. If the kernel's console also had the same range of characters, would you then use that console for text work? > Also, because the fonts aren’t blurry to me, ever since I adjusted the > font hinting slightly and bumped up the minimum font sizes > significantly (I agree that blurriness is somewhat subjective). > >> (But I can imagine a hypothetical future kernel module which statically > >> links against them in order to provide a full–featured terminal in the > >> console.) > > I can't. The Linux console has got to work to bring up a new machine, > > should one be doing this from scratch rather than installing a > > distribution with ready made X. For this, it's _got_ to work directly in > > the kernel. > Yea, that’s why I said that it would need to be statically linked. The > console already uses the framebuffer, it just needs support for reading > TTF fonts (libfreetype) and shaping the text properly (libharfbuzz). I’m > sure some other handwavium would be needed too, but in principle there’s > no reason the Linux console shouldn’t be able to completely support > Unicode text display. It’s just that nobody has done the work. Exactly so. The Linux console code is exceptionally old gnarled code, which is difficult to work with. (I know, having recently hacked it to restore "soft scrolling" via the S-, S- keys.) > Of course I hadn’t been thinking of input handling, but xkb does already > exist. While it is a problem that the name starts with an ‘x’, the core > logic of translating keycodes into characters via a keymap is all > there. Actually, no it's not. I had to hack its source a few years ago to be able to configure C-A-S-Fn in X. The corresponding program for the console, loadkeys, can pretty much do anything. > Presumably with sufficient elbow grease the X protocol stuff could be > filed off and the important bits reused. > I can hear the laughter already, as we propose adding a 2 or 3 megabyte > kernel module. It would be hilarious. Can you imagine it now? Actually, if it was an optional feature, I think it would be welcome in the kernel, although most kernel hackers would probably continue not to use it. 2 or 3 Mb isn't a large amount of RAM on a desktop machine any more. > db48x -- Alan Mackenzie (Nuremberg, Germany).