emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master ff4de1b: Fix quoting style in Lisp comments


From: Dmitry Gutov
Subject: Re: master ff4de1b: Fix quoting style in Lisp comments
Date: Thu, 16 Sep 2021 13:50:32 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 15.09.2021 23:15, Stefan Monnier wrote:
Then, if you don't mind, I will revert your commit.

I think we should first try to agree on a convention (specifically for
quoting symbols in ELisp comments).  Either:

- We have no official preference (in which case the maintainer of
   a package/file can try and impose his preference for that file, but
   beyond this we should just refrain from changing other people's
   style).  I guess that would mean you shouldn't revert his commit.

No, that would mean I should because he went and changed code I am responsible for from the style I prefer into a broken one.

- We declare '...' as the official style and decide on how we deal with
   the many cases of other style used throughout the code, and someoneā„¢
   will have to write the new code for font-lock and completion.

That's my main point: doing this change now all of a sudden without the associated changes in infrastructure is bad form.

- We declare `...' as the official style.  This matches the historical
   use, so it requires no changes, AFAIK (other than reverting Eli's
   commit, obviously).

- We declare something else as the official style.  I personally have
   grown fond of (a subset of) Markdown, so I'd vote for `...` (and
   encourage extending this to a few more conventions, e.g. so we can
   distinguish code from prose in comments), but (a subset of) Org style
   would also make a lot of sense.

`...` is fine with me, or anything else that looks like markup ('...' will result in more annoying false positives). But it will result in a lot more work across the board.

This is a typical bikeshed kind of question, so there's not much point
getting people to argue over it.  The maintainers should make an
executive decision on it (but they do need to come to an agreement
among themselves ;-).

And they need to consider the technical tradeoffs of every choice, and take responsibility for the necessary changes in supporting code.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]