Re: master ff4de1b: Fix quoting style in Lisp comments

[Dmitry Gutov <dgutov@yandex.ru>]

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.