|
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.
[Prev in Thread] | Current Thread | [Next in Thread] |