From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Explicit encoding cookie in Elisp files Add prettify-symbols-alist for js-mode Date: Mon, 28 Sep 2015 10:27:53 +0300 Message-ID: <83oagndmva.fsf@gnu.org> References: <1443268188.7436.0@smtp.gmail.com> <834mihgvb9.fsf@gnu.org> <1443283198.7442.0@smtp.gmail.com> <56074E0F.6060209@yandex.ru> <83r3lkfleu.fsf@gnu.org> <560788DB.6000104@yandex.ru> <83oagofhhi.fsf@gnu.org> <5607A721.2020002@yandex.ru> <83h9mgfe78.fsf@gnu.org> <5607ADCC.8080407@yandex.ru> <83d1x4fabf.fsf@gnu.org> <5607F919.9090600@yandex.ru> <831tdjg14c.fsf@gnu.org> <56083FD0.4020501@yandex.ru> <83y4frejbu.fsf@gnu.org> <56084F04.2040501@yandex.ru> <83vbavefup.fsf@gnu.org> <5608BF16.2020605@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1443425647 23129 80.91.229.3 (28 Sep 2015 07:34:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2015 07:34:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 28 09:33:58 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZgSwf-0004Gn-Mf for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 09:33:57 +0200 Original-Received: from localhost ([::1]:33505 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgSwf-0008AB-2J for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 03:33:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgSqj-0005OG-Uy for emacs-devel@gnu.org; Mon, 28 Sep 2015 03:27:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgSqf-0007im-KF for emacs-devel@gnu.org; Mon, 28 Sep 2015 03:27:49 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:58817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgSqf-0007i4-Bp for emacs-devel@gnu.org; Mon, 28 Sep 2015 03:27:45 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NVD00M00LQBAW00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 28 Sep 2015 10:27:43 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVD00MWAM273C40@a-mtaout22.012.net.il>; Mon, 28 Sep 2015 10:27:43 +0300 (IDT) In-reply-to: <5608BF16.2020605@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190431 Archived-At: > Cc: xfq.free@gmail.com, Simen Heggest=F8yl > , emacs-devel > From: Dmitry Gutov > Date: Mon, 28 Sep 2015 07:16:22 +0300 >=20 > How about this wording? >=20 > but other files need them even if encoded in UTF-8. However, if an= *.el > file is intended for use with older Emacs versions (e.g. if it's al= so > distributed via ELPA), having an explicit encoding specification is > still a good idea. Fine with me. Although it definitely narrows the applicability of that suggestion, because the issue is not necessarily "using" the files, but even visiting them with an older version. And the latter happens, at least to me, quite a lot, e.g. when I need to look at those files on a system where only an older Emacs is installed or usable. It also contradicts what we have been doing with such files until now= , see below. And again, it's just a suggestion, not a requirement. We already hav= e similar language elsewhere in CONTRIBUTE, for example: - There is no need to mention files such as NEWS, MAINTAINERS, and FOR-RELEASE, or to indicate regeneration of files such as 'configure', in the ChangeLog entry. "There is no need" means yo= u don't have to, but you can if you want to.^^^^^^^^^^^^^^^^^^^^^^^= ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It's okay to not behave according to such suggestions: that's why the= y are worded as non-mandatory suggestions. Why such strong opposition? > > Let's agree to disagree about that, okay? >=20 > I don't mind having a difference in opinion, if you don't object to= =20 > reverting db828f6. Sigh. Revert it if you must. But see below for why I think that's a desire I don't understand, unless you have some problem with my commits specifically. > Having Elisp files default to UTF-8 is a good feature, and you're > proposing to effectively ignore it. Did you see how many of our Lisp files already have the cookie that states UTF-8 encoding? (Answer: 197.) Moreover, various features that generate *.el files automatically insert the cookie there, see autoload.el and ido.el for just 2 examples. Did this bother you, or anyone else, until now? So why did that single commit, which added a cookie to 3 more files, for a 1.5% growth, suddenly bother you? I just did what we have been doing for many years, something that was burned into my muscle memory during all those years. IOW, don't you see how this minuscule issue is blown out of proportions for reasons I cannot even begin to understand? And why d= o you single out only those 3 files, but say nothing about the others? If you really dislike those cookies so much, I'd expect you to first realize the magnitude of the "problem", and then attack it consistently across the board, rather than pouncing on my single commit. > > The form and the intense of the objections are out of proportions= , > > for such an insignificant issue/disagreement. >=20 > Sorry about the strong wording. Apparently, that's how I react to a= =20 > perceived feature/workflow regression made on purpose (not sure how= to=20 > phrase this better). My strong perception is that this is how you react to any of my suggestions or ideas or actions, and this incident is a very good example.