From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#33796: 27.0.50; Use utf-8 is all our Elisp files Date: Thu, 20 Dec 2018 18:06:32 +0200 Message-ID: <835zvochdj.fsf@gnu.org> References: <3fd27fe5-e650-b207-fdd4-36f805b89b4d@cs.ucla.edu> <83bm5hcroa.fsf@gnu.org> <9f33127d-f01b-b138-7a0c-ffeac7b77938@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1545321915 15189 195.159.176.226 (20 Dec 2018 16:05:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Dec 2018 16:05:15 +0000 (UTC) Cc: monnier@iro.umontreal.ca, 33796@debbugs.gnu.org To: Paul Eggert , Kenichi Handa Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 20 17:05:10 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ga0ow-0003ot-1s for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Dec 2018 17:05:10 +0100 Original-Received: from localhost ([::1]:38488 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ga0r2-0002kS-GT for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Dec 2018 11:07:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ga0qv-0002kC-EM for bug-gnu-emacs@gnu.org; Thu, 20 Dec 2018 11:07:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ga0qo-0001Hp-Gz for bug-gnu-emacs@gnu.org; Thu, 20 Dec 2018 11:07:12 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52401) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ga0qm-0001Fn-Bl for bug-gnu-emacs@gnu.org; Thu, 20 Dec 2018 11:07:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ga0qm-00063Q-3J for bug-gnu-emacs@gnu.org; Thu, 20 Dec 2018 11:07:04 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Dec 2018 16:07:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33796 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33796-submit@debbugs.gnu.org id=B33796.154532199823220 (code B ref 33796); Thu, 20 Dec 2018 16:07:04 +0000 Original-Received: (at 33796) by debbugs.gnu.org; 20 Dec 2018 16:06:38 +0000 Original-Received: from localhost ([127.0.0.1]:56659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ga0qM-00062S-Ko for submit@debbugs.gnu.org; Thu, 20 Dec 2018 11:06:38 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ga0qL-00062D-FQ for 33796@debbugs.gnu.org; Thu, 20 Dec 2018 11:06:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ga0qF-0000nj-HP for 33796@debbugs.gnu.org; Thu, 20 Dec 2018 11:06:32 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39188) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ga0q8-0000hY-TL; Thu, 20 Dec 2018 11:06:26 -0500 Original-Received: from [176.228.60.248] (port=1207 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ga0q7-00062P-3n; Thu, 20 Dec 2018 11:06:24 -0500 In-reply-to: <9f33127d-f01b-b138-7a0c-ffeac7b77938@cs.ucla.edu> (message from Paul Eggert on Wed, 19 Dec 2018 14:13:59 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:153639 Archived-At: > Cc: monnier@iro.umontreal.ca, 33796@debbugs.gnu.org > From: Paul Eggert > Date: Wed, 19 Dec 2018 14:13:59 -0800 > > On 12/19/18 10:11 AM, Eli Zaretskii wrote: > > I need to hear a second opinion, > > That would actually be a third opinion, as Stefan's opinion surely > counts too and he has good reasons to prefer UTF-8 here. Technically, it's the forth, because my opinion should also count, right? But this is besides the point, because we need the opinion of people who might be actually affected by the proposed change, and none of us qualify. All 3 of us simply don't care, because we don't read these scripts and don't distinguish the various fonts used to display the same Unicode codepoints under different cultural conventions. At some point in the past that distinction was very important. If nowadays it no longer is, then I see no problems making the change. Otherwise, the change will lose information important to some of our users. We need someone to advise us what is the actual state of the affairs. I hope Handa-san will (please don't drop him from the CC list). Or maybe someone here can propose other experts or even just users with relevant experience. > And to some extent opinions should be weighted for the kind of > maintenance that is actually done with these files as opposed to the > rare cases where the font's style might annoy a language-expert > developer if the wrong language environment were used. This is also beyond the point, because we have nothing to weigh this against for now. When we do, we will. > >> etc/HELLO is pretty much a disaster for me now, as I can’t use any tool > >> other than Emacs to look at it > > > > ??? It's a UTF-8 file with markup.  Do you have the same problems with > > HTML and XML files? > > No, because when I visit those files I see the same thing in my Emacs > editing buffer that I see after using common keystrokes like 'C-x v =' > or standard tools like "git diff", and it's easy to use Emacs to edit > these files in the usual way without becoming expert in html-mode etc. > In contrast, with etc/HELLO standard tools and common keystrokes give me > gibberish, and one must gain expertise in enriched-mode to make > nontrivial changes. This line of reasoning makes little sense to me: . Displaying HELLO doesn't show "gibberish", it shows UTF-8 encoded text with pure-ASCII markup. If your terminal can display these characters, you should see legible marked-up text, whereas the ISO-2022 encoded file of yore would display as illegible escape sequences. But since in your opinion the current situation is a "disaster", you seem to be saying that we should go back to ISO-2022? . By the above reasoning, if Emacs is enhanced to interpret HTML/XML and show typefaces instead of markup, you will see that as a regression and complain that raw HTML files are "gibberish"? . You have find-file-literally to show you HELLO exactly as any text-mode tool will see it, if you really need that. . No experience in Enriched mode is needed to edit HELLO, you just need to apply text properties (via facemenu.el commands or the menu-bar's Edit->Text Properties menu). And these properties are optional. > A primary goal of Emacs is to have source code that the user can change > easily, and using enriched-text mode in etc/HELLO works against this. It > might be OK just for that one file (as a demonstration of enriched-text > mode perhaps) but as things stand we shouldn't let these issues infect > the rest of the Emacs sources. etc/HELLO is not a demonstration of Enriched mode, it is a demonstration of facilities to edit and display many different scripts and character sets in the same buffer. We use Enriched mode there because we have no other feature which allows us to save 'charset' text property to a disk file.