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

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.