[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
Tue, 29 Sep 2015 01:54:19 +0300
Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0
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
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
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
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.