[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Explicit encoding cookie in Elisp files Add prettify-symbols-alist f
Re: Explicit encoding cookie in Elisp files Add prettify-symbols-alist for js-mode
Mon, 28 Sep 2015 11:24:33 +0300
> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> 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
> > 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
> 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.