bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Simen Heggestøyl]

[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]

With the introduction of the fat arrow (=>) function notation in
ECMAScript 6, why not make them prettier by default when
prettify-symbols-mode is turned on?

I propose the following patch, which also adds pretty versions of >=
and <= while we're at it:


 From fa37953359f50748801717d259350d7e352cff60 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?Simen=20Heggest=C3=B8yl?= <simenheg@gmail.com>
Date: Wed, 23 Sep 2015 21:49:24 +0200
Subject: [PATCH] Add prettify-symbols-alist for js-mode

* lisp/progmodes/js.el (js--prettify-symbols-alist): New defconst.
(js-mode): Use it.
---
 lisp/progmodes/js.el | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el
index 6a800f8..f214015 100644
--- a/lisp/progmodes/js.el
+++ b/lisp/progmodes/js.el
@@ -1724,6 +1724,12 @@ This performs fontification according to 
`js--class-styles'."
            (js-syntax-propertize-regexp end))))))
    (point) end))

+(defconst js--prettify-symbols-alist
+  '(("=>" . ?⇒)
+    (">=" . ?≥)
+    ("<=" . ?≤))
+  "Alist of symbol prettifications for JavaScript.")
+
 ;;; Indentation

 (defconst js--possibly-braceless-keyword-re
@@ -3495,6 +3501,7 @@ If one hasn't been set, or if it's stale, prompt 
for a new one."
   (setq-local open-paren-in-column-0-is-defun-start nil)
   (setq-local font-lock-defaults (list js--font-lock-keywords))
   (setq-local syntax-propertize-function #'js-syntax-propertize)
+  (setq-local prettify-symbols-alist js--prettify-symbols-alist)

   (setq-local parse-sexp-ignore-comments t)
   (setq-local parse-sexp-lookup-properties t)
-- 
2.5.1



[-- Attachment #2: Type: text/html, Size: 2297 bytes --]

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Eli Zaretskii]

> Date: Sat, 26 Sep 2015 13:49:48 +0200
> From: Simen Heggestøyl <simenheg@gmail.com>
> 
> With the introduction of the fat arrow (=>) function notation in
> ECMAScript 6, why not make them prettier by default when
> prettify-symbols-mode is turned on?
> 
> I propose the following patch, which also adds pretty versions of >=
> and <= while we're at it:

Thanks, but please add a coding cookie to the file, so that UTF-8
encoded characters in it will always decoded correctly.

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Simen Heggestøyl]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

On Sat, Sep 26, 2015 at 3:32 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Thanks, but please add a coding cookie to the file, so that UTF-8
> encoded characters in it will always decoded correctly.

Alright. Better?


 From a51d8ceaa7e6114cf775a4f01e16a7cf1403e075 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?Simen=20Heggest=C3=B8yl?= <simenheg@gmail.com>
Date: Wed, 23 Sep 2015 21:49:24 +0200
Subject: [PATCH] Add prettify-symbols-alist for js-mode

* lisp/progmodes/js.el (js--prettify-symbols-alist): New defconst.
(js-mode): Use it.
---
 lisp/progmodes/js.el | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el
index 6a800f8..ab994f3 100644
--- a/lisp/progmodes/js.el
+++ b/lisp/progmodes/js.el
@@ -1724,6 +1724,12 @@ This performs fontification according to 
`js--class-styles'."
            (js-syntax-propertize-regexp end))))))
    (point) end))

+(defconst js--prettify-symbols-alist
+  '(("=>" . ?⇒)
+    (">=" . ?≥)
+    ("<=" . ?≤))
+  "Alist of symbol prettifications for JavaScript.")
+
 ;;; Indentation

 (defconst js--possibly-braceless-keyword-re
@@ -3495,6 +3501,7 @@ If one hasn't been set, or if it's stale, prompt 
for a new one."
   (setq-local open-paren-in-column-0-is-defun-start nil)
   (setq-local font-lock-defaults (list js--font-lock-keywords))
   (setq-local syntax-propertize-function #'js-syntax-propertize)
+  (setq-local prettify-symbols-alist js--prettify-symbols-alist)

   (setq-local parse-sexp-ignore-comments t)
   (setq-local parse-sexp-lookup-properties t)
@@ -3564,4 +3571,8 @@ If one hasn't been set, or if it's stale, prompt 
for a new one."

 (provide 'js)

+;; Local Variables:
+;; coding: utf-8
+;; End:
+
 ;; js.el ends here
-- 
2.5.3



[-- Attachment #2: Type: text/html, Size: 2590 bytes --]

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Xue Fuqiao]

On Sat, Sep 26, 2015 at 11:59 PM, Simen Heggestøyl <simenheg@gmail.com> wrote:
> Alright. Better?

LGTM.  WDYT, Dmitry and Daniel?

BTW, Dmitry, maybe you can also apply it to js2-mode.

> From a51d8ceaa7e6114cf775a4f01e16a7cf1403e075 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Simen=20Heggest=C3=B8yl?= <simenheg@gmail.com>
> Date: Wed, 23 Sep 2015 21:49:24 +0200
> Subject: [PATCH] Add prettify-symbols-alist for js-mode
>
> * lisp/progmodes/js.el (js--prettify-symbols-alist): New defconst.
> (js-mode): Use it.
> ---
>  lisp/progmodes/js.el | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el
> index 6a800f8..ab994f3 100644
> --- a/lisp/progmodes/js.el
> +++ b/lisp/progmodes/js.el
> @@ -1724,6 +1724,12 @@ This performs fontification according to
> `js--class-styles'."
>             (js-syntax-propertize-regexp end))))))
>     (point) end))
>
> +(defconst js--prettify-symbols-alist
> +  '(("=>" . ?⇒)
> +    (">=" . ?≥)
> +    ("<=" . ?≤))
> +  "Alist of symbol prettifications for JavaScript.")
> +
>  ;;; Indentation
>
>  (defconst js--possibly-braceless-keyword-re
> @@ -3495,6 +3501,7 @@ If one hasn't been set, or if it's stale, prompt for a
> new one."
>    (setq-local open-paren-in-column-0-is-defun-start nil)
>    (setq-local font-lock-defaults (list js--font-lock-keywords))
>    (setq-local syntax-propertize-function #'js-syntax-propertize)
> +  (setq-local prettify-symbols-alist js--prettify-symbols-alist)
>
>    (setq-local parse-sexp-ignore-comments t)
>    (setq-local parse-sexp-lookup-properties t)
> @@ -3564,4 +3571,8 @@ If one hasn't been set, or if it's stale, prompt for a
> new one."
>
>  (provide 'js)
>
> +;; Local Variables:
> +;; coding: utf-8
> +;; End:
> +
>  ;; js.el ends here
> --
> 2.5.3
>

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Dmitry Gutov]

On 09/27/2015 03:39 AM, Xue Fuqiao wrote:

> LGTM.  WDYT, Dmitry and Daniel?

The patch looks fine to me, but I have no idea if Eli meant to add the 
cookie at the bottom, or whether that request really makes sense at all.

So I'd prefer if he replies as well.

> BTW, Dmitry, maybe you can also apply it to js2-mode.

No need: it inherits from js-mode already.

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 27 Sep 2015 05:01:51 +0300
> Cc: 21568@debbugs.gnu.org
> 
> On 09/27/2015 03:39 AM, Xue Fuqiao wrote:
> 
> > LGTM.  WDYT, Dmitry and Daniel?
> 
> The patch looks fine to me, but I have no idea if Eli meant to add the 
> cookie at the bottom

I have no preferences in this regard.

> or whether that request really makes sense at all.

In general, ELisp files don't have to have these cookies, but I'd
prefer such changes to trigger adding them, if only for educational
purposes, so our contributors are aware of this subtle issue.

> So I'd prefer if he replies as well.

The patch is fine with me.

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Dmitry Gutov]

On 09/27/2015 09:04 AM, Eli Zaretskii wrote:

> I have no preferences in this regard.

Thanks. Simen, please install.

> In general, ELisp files don't have to have these cookies, but I'd
> prefer such changes to trigger adding them, if only for educational
> purposes, so our contributors are aware of this subtle issue.

I'd prefer there not to be any subtle issues here, or that, at least, 
most contributors wouldn't have to be aware of them.

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Eli Zaretskii]

> Cc: xfq.free@gmail.com, simenheg@gmail.com, 21568@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 27 Sep 2015 09:12:43 +0300
> 
> > In general, ELisp files don't have to have these cookies, but I'd
> > prefer such changes to trigger adding them, if only for educational
> > purposes, so our contributors are aware of this subtle issue.
> 
> I'd prefer there not to be any subtle issues here, or that, at least, 
> most contributors wouldn't have to be aware of them.

Me too.  But we don't have a better solution yet.

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Simen Heggestøyl]

[-- Attachment #1: Type: text/plain, Size: 122 bytes --]

On Sun, Sep 27, 2015 at 8:12 AM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> Thanks. Simen, please install.

Done!

-- Simen

[-- Attachment #2: Type: text/html, Size: 262 bytes --]

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Dmitry Gutov]

On 09/27/2015 10:28 AM, Eli Zaretskii wrote:

> Me too.  But we don't have a better solution yet.

Do we have a clear statement of the problem (and a bug number, maybe)? 
Is it new? Is it likely to be unsolved until the upcoming release?

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Eli Zaretskii]

> Cc: xfq.free@gmail.com, simenheg@gmail.com, 21568@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 27 Sep 2015 11:21:53 +0300
> 
> On 09/27/2015 10:28 AM, Eli Zaretskii wrote:
> 
> > Me too.  But we don't have a better solution yet.
> 
> Do we have a clear statement of the problem (and a bug number, maybe)? 

I just added a few recommendations to CONTRIBUTE about that.

Other than that, we don't have a bug number.  I don't think it's a
bug, more like inconvenient feature: Emacs cannot determine the
encoding of arbitrary text with 100% reliability, so files whose
encoding is not unequivocally determined by their file-name extension
or some other meta-data need a coding cookie to avoid incorrect
decoding.  With UTF-8 encoded files (which is the encoding we prefer
in Emacs), the problem happens in locales whose codeset is not UTF-8,
because Emacs prefers the locale's encoding when no other information
is available.

> Is it new?

No, it's very old.

> Is it likely to be unsolved until the upcoming release?

I'm not aware of anyone working on that, nd it's a large and
complicated problem, so the answer is probably yes.

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Dmitry Gutov]

On 09/27/2015 11:39 AM, Eli Zaretskii wrote:

> I just added a few recommendations to CONTRIBUTE about that.

Thank you, but as long as that's true:

"As of Emacs 24.4, it is no longer necessary to have
explicit 'coding' cookies in *.el files if they are encoded in UTF-8,
but other files need them even if encoded in UTF-8.  And even for *.el
files, having an explicit encoding specification facilitates correct
display of non-ASCII characters when the file is visited in older
Emacs versions."

...we really shouldn't bother contributors with that detail, not should 
we annotate code Elisp files with explicit cookies. Use UTF-8 in them, 
it works fine in Emacs 24.4+, end of story.

If anyone's working on Emacs master using 24.3 or earlier, I'm sure 
there are other footguns they can encounter as well.

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Eli Zaretskii]

> Cc: xfq.free@gmail.com, simenheg@gmail.com, 21568@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 27 Sep 2015 11:50:20 +0300
> 
> On 09/27/2015 11:39 AM, Eli Zaretskii wrote:
> 
> > I just added a few recommendations to CONTRIBUTE about that.
> 
> Thank you, but as long as that's true:
> 
> "As of Emacs 24.4, it is no longer necessary to have
> explicit 'coding' cookies in *.el files if they are encoded in UTF-8,
> but other files need them even if encoded in UTF-8.  And even for *.el
> files, having an explicit encoding specification facilitates correct
> display of non-ASCII characters when the file is visited in older
> Emacs versions."
> 
> ...we really shouldn't bother contributors with that detail

I don't see that as a bother, just as useful information that can do
no harm.

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Dmitry Gutov]

On 09/27/2015 01:03 PM, Eli Zaretskii wrote:

> I don't see that as a bother, just as useful information that can do
> no harm.

I'd have been happy not be have been imparted this "information". 
Especially in the form it was presented: adding those cookies everywhere 
conflicts with that bit of knowledge I've had in my head that since some 
recent Emacs version having UTF-8 in Elisp files is not a problem.

We shouldn't treat them like that just because this problem occurs in 
other files. Nor bring it up in discussions on submitted patches.

There are other ways to raise awareness. Like CONTRIBUTE, which now 
features that information. Most contributors aren't going to touch 
anything but Elisp, ever.

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Xue Fuqiao]

On Sun, Sep 27, 2015 at 10:01 AM, Dmitry Gutov <dgutov@yandex.ru> wrote:
>> BTW, Dmitry, maybe you can also apply it to js2-mode.
>
> No need: it inherits from js-mode already.

I didn't know that.  Thanks for pointing out this!

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Eli Zaretskii]

> Cc: xfq.free@gmail.com, simenheg@gmail.com, 21568@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 27 Sep 2015 17:11:37 +0300
> 
> On 09/27/2015 01:03 PM, Eli Zaretskii wrote:
> 
> > I don't see that as a bother, just as useful information that can do
> > no harm.
> 
> I'd have been happy not be have been imparted this "information". 

Then please ignore it.  No harm done.

> Especially in the form it was presented: adding those cookies everywhere 
> conflicts with that bit of knowledge I've had in my head that since some 
> recent Emacs version having UTF-8 in Elisp files is not a problem.

That's a misrepresentation of what the text says.  It explicitly does
NOT require cookies in ELisp files that are encoded in UTF-8.

> We shouldn't treat them like that just because this problem occurs in 
> other files. Nor bring it up in discussions on submitted patches.

With all due respect, I will bring up whatever issues I think are
important when discussing patches.  Please feel free to bring up those
that you feel to be important.

> There are other ways to raise awareness. Like CONTRIBUTE, which now 
> features that information.

I did both.  Where's the harm?

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Dmitry Gutov]

On 09/27/2015 09:37 PM, Eli Zaretskii wrote:

>> Especially in the form it was presented: adding those cookies everywhere
>> conflicts with that bit of knowledge I've had in my head that since some
>> recent Emacs version having UTF-8 in Elisp files is not a problem.
>
> That's a misrepresentation of what the text says. It explicitly does
> NOT require cookies in ELisp files that are encoded in UTF-8.

Right (so I'd only change CONTRIBUTE to say that one needn't bother with 
cookies in *.el files, except in those that are also distributed 
separately).

What I'm referring to is requests such as this one, which I believe 
was/is misleading:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21568#8

Let's not add that to the general practice.

> With all due respect, I will bring up whatever issues I think are
> important when discussing patches.  Please feel free to bring up those
> that you feel to be important.

But there was no issue with that patch. js-mode is not distributed 
separately from Emacs.

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Eli Zaretskii]

> Cc: xfq.free@gmail.com, simenheg@gmail.com, 21568@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 27 Sep 2015 22:13:20 +0300
> 
> On 09/27/2015 09:37 PM, Eli Zaretskii wrote:
> 
> >> Especially in the form it was presented: adding those cookies everywhere
> >> conflicts with that bit of knowledge I've had in my head that since some
> >> recent Emacs version having UTF-8 in Elisp files is not a problem.
> >
> > That's a misrepresentation of what the text says. It explicitly does
> > NOT require cookies in ELisp files that are encoded in UTF-8.
> 
> Right (so I'd only change CONTRIBUTE to say that one needn't bother with 
> cookies in *.el files, except in those that are also distributed 
> separately).

No, please leave that text alone.  It's okay the way it is.

> What I'm referring to is requests such as this one, which I believe 
> was/is misleading:
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21568#8

I disagree that it was misleading.

> Let's not add that to the general practice.

Now that we have that text in CONTRIBUTE, that's all there is to say.

> > With all due respect, I will bring up whatever issues I think are
> > important when discussing patches.  Please feel free to bring up those
> > that you feel to be important.
> 
> But there was no issue with that patch. js-mode is not distributed 
> separately from Emacs.

I explained my reasons right there and then.

I really don't understand what this attack on me is about.

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Dmitry Gutov]

On 09/27/2015 10:46 PM, Eli Zaretskii wrote:

> No, please leave that text alone.  It's okay the way it is.

I feel that the last sentence causes unnecessary doubt on the part of 
the reader. After all, CONTRIBUTE is intended as a guideline for 
developing Emacs, and the less ambiguous it is, the better.

>> What I'm referring to is requests such as this one, which I believe
>> was/is misleading:
>>
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21568#8
>
> I disagree that it was misleading.

It implied that without that cookie, something in that code might not 
work well.

> Now that we have that text in CONTRIBUTE, that's all there is to say.

All right, thank you.

> I explained my reasons right there and then.

As a counterpoint, I don't believe educational purpose is a good enough 
cause to ask people to use coding cookies in UTF-8 encoded Elisp files.

Even for external packages, over time, Emacs versions where they're 
necessary will sail off into distant past. No need to add to the baggage 
the future people will have to deal with.

> I really don't understand what this attack on me is about.

Please excuse any offense, but I'm not calling you names, or anything 
like that.

I see an attempt to bring in extraneous practice into writing Elisp 
files (as well as reviewing the patches), and speak against it.

bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Eli Zaretskii]

> Cc: xfq.free@gmail.com, simenheg@gmail.com, 21568@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 27 Sep 2015 23:18:12 +0300
> 
> On 09/27/2015 10:46 PM, Eli Zaretskii wrote:
> 
> > No, please leave that text alone.  It's okay the way it is.
> 
> I feel that the last sentence causes unnecessary doubt on the part of 
> the reader. After all, CONTRIBUTE is intended as a guideline for 
> developing Emacs, and the less ambiguous it is, the better.

I see no ambiguity there.  There are requirements, and there's "a good
idea" with an explanation that is left to the contributors to consider
and decide.  I see nothing wrong with leaving the decision with them.

> >> What I'm referring to is requests such as this one, which I believe
> >> was/is misleading:
> >>
> >> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21568#8
> >
> > I disagree that it was misleading.
> 
> It implied that without that cookie, something in that code might not 
> work well.

Then I'm sorry that my wording made such interpretation possible.  It
was certainly not intended.

> > I explained my reasons right there and then.
> 
> As a counterpoint, I don't believe educational purpose is a good enough 
> cause to ask people to use coding cookies in UTF-8 encoded Elisp files.

Let's agree to disagree about that, okay?

> Even for external packages, over time, Emacs versions where they're 
> necessary will sail off into distant past. No need to add to the baggage 
> the future people will have to deal with.

I cannot see how a dozen-character string most users will never even
notice could possibly be a "baggage" of any significance.

> I see an attempt to bring in extraneous practice into writing Elisp 
> files (as well as reviewing the patches), and speak against it.

The form and the intense of the objections are out of proportions,
for such an insignificant issue/disagreement.

Explicit encoding cookie in Elisp files, was: Re: bug#21568: [PATCH] Add prettify-symbols-alist for js-mode

[Dmitry Gutov]

On 09/28/2015 12:01 AM, Eli Zaretskii wrote:

> I see no ambiguity there.  There are requirements, and there's "a good
> idea" with an explanation that is left to the contributors to consider
> and decide.  I see nothing wrong with leaving the decision with them.

How about this wording?

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 also
distributed via ELPA), having an explicit encoding specification is
still a good idea.

> Then I'm sorry that my wording made such interpretation possible.  It
> was certainly not intended.

Thanks. It was exactly how I interpreted it.

> Let's agree to disagree about that, okay?

I don't mind having a difference in opinion, if you don't object to 
reverting db828f6. Having Elisp files default to UTF-8 is a good 
feature, and you're proposing to effectively ignore it.

> The form and the intense of the objections are out of proportions,
> for such an insignificant issue/disagreement.

Sorry about the strong wording. Apparently, that's how I react to a 
perceived feature/workflow regression made on purpose (not sure how to 
phrase this better).

Re: Explicit encoding cookie in Elisp files Add prettify-symbols-alist for js-mode

[Eli Zaretskii]

> Cc: xfq.free@gmail.com, Simen Heggestøyl
>  <simenheg@gmail.com>, emacs-devel <emacs-devel@gnu.org>
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 28 Sep 2015 07:16:22 +0300
> 
> How about this wording?
> 
> 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 also
> 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 have
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 you
    don't have to, but you can if you want to.^^^^^^^^^^^^^^^^^^^^^^^^
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It's okay to not behave according to such suggestions: that's why they
are worded as non-mandatory suggestions.  Why such strong opposition?

> > Let's agree to disagree about that, okay?
> 
> I don't mind having a difference in opinion, if you don't object to 
> 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 do
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.
> 
> Sorry about the strong wording. Apparently, that's how I react to a 
> perceived feature/workflow regression made on purpose (not sure how to 
> 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.

Re: Explicit encoding cookie in Elisp files Add prettify-symbols-alist for js-mode

[Dmitry Gutov]

On 09/28/2015 10:27 AM, Eli Zaretskii wrote:

> 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.

Yes, that is the exact distinction. Has it caused you a tangible amount 
of hassle over the years?

Thanks.

> 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.

Hopefully, that will occur less and less. 24.4 will soon be a year old.

> And again, it's just a suggestion, not a requirement.  We already have
> 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 you
>      don't have to, but you can if you want to.^^^^^^^^^^^^^^^^^^^^^^^^
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> It's okay to not behave according to such suggestions: that's why they
> are worded as non-mandatory suggestions.  Why such strong opposition?

That suggestion makes it clear that the choice is irrelevant.

And change log guidelines are in a bit different position than source 
code guidelines: it's perfectly possible for two different developers to 
work on the same code while keeping to their respective change log 
preferences.

>> I don't mind having a difference in opinion, if you don't object to
>> 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.

Just that one particular commit.

> 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?

I wasn't actively aware of that, but I imagine a lot of them come from 
before Emacs 24.4 (both files and generation scripts).

If it's inconsistency you dislike, I can commit to spend the effort and 
remove the cookies where they're not strictly required, if you like.

> 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.

Imagine that we added a new syntax feature to Elisp, used it for over a 
year from time to time in some new code, and them one of the developers 
"desugared" all its uses into more verbose code that's compatible with 
older Emacsen. The present situation is not as absurd, but that's the 
direction I'm looking at it from.

> IOW, don't you see how this minuscule issue is blown out of
> proportions for reasons I cannot even begin to understand?  And why do
> 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.

We also have lots of compilation warnings, non-idiomatic (or just 
somewhat obsolete) uses of Elisp in different places, and other similar 
problems, for which there's not enough manpower/enthusiasm to fix.

I'd prefer not to exacerbate any of them. But like I said, my issue is 
not with individual cookies, but with the strong suggestion to add them 
everywhere UTF-8 is used.

Re: Explicit encoding cookie in Elisp files Add prettify-symbols-alist for js-mode

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 28 Sep 2015 10:53:32 +0300
> 
> > And the [need to visit Emacs files with older Emacs versions]
> > 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.
> 
> Hopefully, that will occur less and less. 24.4 will soon be a year old.

Of course.  But I still routinely work on systems where 23.2 is the
latest installed version, and I'm a simple user there, so I cannot
upgrade that.

> > 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?
> 
> I wasn't actively aware of that, but I imagine a lot of them come from 
> before Emacs 24.4 (both files and generation scripts).
> 
> If it's inconsistency you dislike, I can commit to spend the effort and 
> remove the cookies where they're not strictly required, if you like.

I did what I did semi-automatically because we were doing that for
years.  I didn't even remember that we default to UTF-8 in *.el files
until Stefan reminded me.  Why? because we never bothered to remove
the cookies after we made that change, nor stop producing them in
auto-generated *.el files.

Inconsistency?  Yes, I dislike it, but I dislike discrimination and
lack of fair play even more.

> > 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.
> 
> Imagine that we added a new syntax feature to Elisp, used it for over a 
> year from time to time in some new code, and them one of the developers 
> "desugared" all its uses into more verbose code that's compatible with 
> older Emacsen. The present situation is not as absurd, but that's the 
> direction I'm looking at it from.

Once again, you are blowing out of proportion a minor issue.  It lacks
any potential for any kind of grave consequences, so far-fetched
absurd analogies are inappropriate here.  One more reason for me to
suspect the issue itself is not what made you so worked up.

> > IOW, don't you see how this minuscule issue is blown out of
> > proportions for reasons I cannot even begin to understand?  And why do
> > 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.
> 
> We also have lots of compilation warnings, non-idiomatic (or just 
> somewhat obsolete) uses of Elisp in different places, and other similar 
> problems, for which there's not enough manpower/enthusiasm to fix.

Judging by the energy invested in this discussion, I don't think we
should lack manpower/enthusiasm to fix the issue consistently, only
redirect it.  Assuming, that is, that the issue is indeed the cookies
themselves.

> But like I said, my issue is not with individual cookies

Then why did you want to revert db828f6?

> but with the strong suggestion to add them everywhere UTF-8 is used.

The text in CONTRIBUTE is hardly a "strong" suggestion.

Re: Explicit encoding cookie in Elisp files Add prettify-symbols-alist for js-mode

[Dmitry Gutov]

On 09/28/2015 11:24 AM, Eli Zaretskii wrote:

> Of course.  But I still routinely work on systems where 23.2 is the
> latest installed version, and I'm a simple user there, so I cannot
> upgrade that.

Hopefully, you don't have to work on Emacs too much in those conditions.

> I did what I did semi-automatically because we were doing that for
> years.  I didn't even remember that we default to UTF-8 in *.el files
> until Stefan reminded me.  Why? because we never bothered to remove
> the cookies after we made that change, nor stop producing them in
> auto-generated *.el files.

Cookies still make sense in loaddefs, because those are created inside 
.emacs.d/elpa as well.

> Inconsistency?  Yes, I dislike it, but I dislike discrimination and
> lack of fair play even more.

Ok, I've removed most of those old occurrences too, so that the tiny new 
commit doesn't feel too discriminated against. Hopefully, it won't cause 
significant difficulties on your systems with Emacs 23.2.

I didn't touch Org, Gnus, CC Mode, Tramp and loaddefs files. As well as 
the directories leim, language and international, because those are 
terrifying.

> Once again, you are blowing out of proportion a minor issue.  It lacks
> any potential for any kind of grave consequences, so far-fetched

Analogies sometimes get exaggerated for clarity.

Note that "desugaring" in the presented analogy doesn't have any "grave 
consequences" either. It's a pretty safe operation, all in all.

> Judging by the energy invested in this discussion, I don't think we
> should lack manpower/enthusiasm to fix the issue consistently, only
> redirect it.  Assuming, that is, that the issue is indeed the cookies
> themselves.

My issue was with the proposed change in the workflow for new 
contributions. But I hope you're okay with the result.

> Then why did you want to revert db828f6?

It seems to be a fitting conclusion for this discussion, that's all.