all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: emacs-devel@gnu.org
Subject: Re: Explicit encoding cookie in Elisp files Add prettify-symbols-alist for js-mode
Date: Mon, 28 Sep 2015 10:27:53 +0300	[thread overview]
Message-ID: <83oagndmva.fsf@gnu.org> (raw)
In-Reply-To: <5608BF16.2020605@yandex.ru>

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




  reply	other threads:[~2015-09-28  7:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-26 11:49 bug#21568: [PATCH] Add prettify-symbols-alist for js-mode Simen Heggestøyl
2015-09-26 13:32 ` Eli Zaretskii
2015-09-26 15:59   ` Simen Heggestøyl
2015-09-27  0:39     ` Xue Fuqiao
2015-09-27  2:01       ` Dmitry Gutov
2015-09-27  6:04         ` Eli Zaretskii
2015-09-27  6:12           ` Dmitry Gutov
2015-09-27  7:28             ` Eli Zaretskii
2015-09-27  8:21               ` Dmitry Gutov
2015-09-27  8:39                 ` Eli Zaretskii
2015-09-27  8:50                   ` Dmitry Gutov
2015-09-27 10:03                     ` Eli Zaretskii
2015-09-27 14:11                       ` Dmitry Gutov
2015-09-27 18:37                         ` Eli Zaretskii
2015-09-27 19:13                           ` Dmitry Gutov
2015-09-27 19:46                             ` Eli Zaretskii
2015-09-27 20:18                               ` Dmitry Gutov
2015-09-27 21:01                                 ` Eli Zaretskii
2015-09-28  4:16                                   ` Explicit encoding cookie in Elisp files, was: " Dmitry Gutov
2015-09-28  7:27                                     ` Eli Zaretskii [this message]
2015-09-28  7:53                                       ` Explicit encoding cookie in Elisp files " Dmitry Gutov
2015-09-28  8:24                                         ` Eli Zaretskii
2015-09-28 22:54                                           ` Dmitry Gutov
2015-09-27  8:10             ` bug#21568: [PATCH] " Simen Heggestøyl
2015-09-27 14:28         ` Xue Fuqiao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83oagndmva.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.