2

I had an edit suggested to answer of mine, which replaced with-eval-after-load with eval-after-load for compatibility with Emacs 24.3.

I mainly disagree with the reason for this edit: Compatibility with Emacs 24.3. Emacs 24.4 is the latest stable release, and I think that answers should reflect the current state of the art, and not that of some arbitrary older release. We don't write answers for Emacs 22 either, do we?

Apparently, though, the reviewers did not share this opinion: The edit was unanimously accepted. Since I disagree, I have reverted by answer to the previous state, but now I wonder whether we have a policy on this matter on Emacs.SX?

Is it acceptable to edit answers to restore compatibility with older releases? If so, where's the line? Do we accept edits for compatibility with Emacs 22 or even older releases as well?

Besides, the edit was not even correct: Dear reviewers, would you please mind to actually read the edit and check its correctness, before you accept it?

Finally, a only semi-related question: How can I contact the reviewers who accepted a suggested edit about this, to ask for clarification?

4
  • The only way to request clarification is to post on meta. You could put a comment on your post, but the reviewer won't be alerted to it (and comments aren't for meta discussion).
    – Matt Ellen
    Commented Nov 28, 2014 at 11:10
  • 1
    Sidenote: As you well know, answerers can always rollback edits. Precisely for that reason, people tend to not worry too much about "would the author want this" the author when proposing/accepting edits. (Just wanted to mention that, not sure if that's a good thing or not.)
    – Malabarba Mod
    Commented Nov 28, 2014 at 22:43
  • @T.Verron unless you've actually tried this and know different, that post does not say you can ping reviewers. Reviewers do not apprear in the revision history.
    – Matt Ellen
    Commented Dec 8, 2014 at 16:06
  • Uh, I'm tired, sorry. I read "editor" instead of "reviewer". Deleting that comment, sorry for the disturbance.
    – T. Verron
    Commented Dec 8, 2014 at 16:08

3 Answers 3

Reset to default
5

First of All

Whether you go for backwards-compatible or bleeding-edge is entirely up to you.

In the general case

In my opinion, it's ok to edit answers without when the edit is actually a strict improvement improvement. Here are two examples of when editing is a no-brainer.

  • Strictly adding information. If the edit just adds missing links or appends useful information to the end, then it's extremely unlikely that it will go against the author's intent.
  • Correcting wrong information (or bad english). Wrong information spreads like a plague and needs to be purged immediately.

There are many more cases when editing is an improvement. The important part is to make sure you don't take anything away. If your edit takes something away (which was the case in this example) then rewrite it a bit to fix that.

On the Compatibility Topic

Whether to go for backwards-compatibility or for bleeding edge features is entirely a matter of preference. Spreading the knowledge about new features is just as important as having a useful answer for older versions.
So it is entirely up to the author. There are people going each way, and people who go both.

In your specific situation, the edit could really have been just a comment. It could also have been added at the end of your answer, as a backwards-compatible alternative, in which case I (personally) would accept it (if not for the fact that it was wrong, of course).

In cases where the edit is more substantial (and even with short ones), the best approach is to just make a separate answer. The two answers would not be redundant and, in fact, both should exist. The asker can then proceed to accept whichever he likes best, but both answers will end up being useful for different people.

10
  • 1
    Please read the policy on editing. Editing answers is encouraged, and there is no reason to comment first (in fact commenting is discouraged when editing is warranted). This edit would have been justified if it had been correct.
    – Gilles 'SO- stop being evil'
    Commented Nov 29, 2014 at 23:52
  • 1
    @Gilles I came off a bit more restrictive than I intended. I've edited a bit. Overall, I agree editing is ok when it's an improvement. But if the edit is taking away useful information, how can it be warranted?
    – Malabarba Mod
    Commented Nov 29, 2014 at 23:58
  • If the edit is taking away useful information, it isn't warranted. But that's not what we were talking about here. This specific edit was incorrect and should have been rejected. The goal of the edit was a good one, and it should have been accepted if implemented correctly.
    – Gilles 'SO- stop being evil'
    Commented Nov 30, 2014 at 0:15
  • 2
    @Gilles I'm sorry, but I disagree. I do not think, that the goal was a good one. If at all, it should have added the legacy alternative, not replace the current state of the art.
    – user227
    Commented Nov 30, 2014 at 8:31
  • 1
    @lunaryorn In this case, the “legacy alternative” has no downside compared with the “current state of the art” (which is not really current, for many people it isn't there yet). The code wasn't more robust, or shorter, or faster or anything. So no, there was no point in mentioning both.
    – Gilles 'SO- stop being evil'
    Commented Nov 30, 2014 at 12:44
  • @Gilles Oh, really? How come then, that the edit made the very mistake that motivated the new with-eval-with-load macro?
    – user227
    Commented Nov 30, 2014 at 17:17
  • 1
    @lunaryorn The edit was wrong. I'm not defending the edit, can you please stop with the strawman argument?
    – Gilles 'SO- stop being evil'
    Commented Nov 30, 2014 at 17:31
  • Ok, I don't think there are any new arguments being brought to the table here. IIUC: Gilles Thinks backwards compatibility is better when it doesn't make the code longer or more complicated; lunaryorn thinks using state-of-the-art has merits on its own, and may have other advantages even when it doesn't make the code shorter (such as preventing common mistakes). If you'd like to continue the discussion (or correct something I wrote), I invite you to use the chat room. If a consensus is reached we can bring it here, otherwise we just leave the comments as is since both opinions are valid.
    – Malabarba Mod
    Commented Nov 30, 2014 at 17:49
  • 1
    @Gilles It's no strawman argument: The mistake made in the edit (not quoting the argument to eval-after-load) is exactly the reason why with-eval-after-load is more robust, and why I prefer it: You don't need to quote the body, which avoids any unwarranted side effects from evaluating forms earlier then expected. And in answers, this matters even more, since it can be the difference between a right and a wrong answer.
    – user227
    Commented Nov 30, 2014 at 17:52
  • 1
    @lunaryorn Since the question wasn't primarily about eval-after-load, including all possible syntaxes for that purpose would dilute the "real" answer in confusing content (for those who don't know it) or useless content (for those who do). The situation would be different for a question asking why some code including eval-after-load is not working, and where this macro would be the cause of the problem.
    – T. Verron
    Commented Dec 2, 2014 at 8:20
3

On Emacs versions targeted by answers

We have no policy on Emacs compatibility of answers, other than the constraint that answers must answer the question. If the question specifies an Emacs version, then answers should work at least on that Emacs version.

If the question doesn't specify any version, answers should make a reasonable assumption. It is generally reasonable to assume that people are running a currently-supported operating system. At the moment, the oldest commonly-available operating systems are:

  • CentOS 5 which ships Emacs 21.4, and will be supported until March 2017.
  • CentOS 6 which ships Emacs 23.1, and will be supported until November 2020.
  • Debian wheezy which ships Emacs 23.4 and will be supported until (probably — Debian's release schedules aren't very predictable) late 2015.
  • Ubuntu 10.04 which ships Emacs 23.1 and will be supported until April 2015.
  • Ubuntu 12.04 which ships Emacs 23.3 and will be supported until April 2017.

CentOS 5 and Ubuntu 10.04 are mostly used on older servers, and people running them are (or at least should be) aware that they're rather behind the times in terms of software. CentOS 6 and Ubuntu 12.04 are still relatively common, but they are no longer the latest major release of these distributions, so people running them should be aware that they're behind the times and mention that they're running an older version of Emacs in their question. Debian wheezy is still the latest stable Debian release at the time of writing; for Debian stable users, Emacs 23.4 is the current version.

Thus if a question doesn't specify compatibility with older releases as a concern and doesn't concern features that are from more recent versions, arranging for compatibility with Emacs 23.4 is a good thing and should be encouraged. Compatibility with older versions is a lot less useful, I wouldn't bother. Answers that assume more recent versions than the typical audience should mention that fact. In particular, at this point, only very early adopters are running 24.4 or above. If your answer requires 24.4 and the question didn't mention that, your answer has a high chance of not even being useful to the asker, let alone other visitors.

Thus the reason behind this edit was a good one. You may run the latest Emacs version, but not everybody does, and there is nothing virtuous about running the latest version.

On edits

Of course, that only justifies edits that do it right. Incorrect edits are never welcome.

If an edit is made to your answer (whether it's a suggested edit or not), you can address a comment to the editor with the @username syntax (even though the user name won't be available in completion). You can't address users who made suggested edits that were rejected in this way, nor users who reviewed a suggested edit.

You can try to contact anyone in chat. Chat pings will only notify users who have been in the chat room recently enough (you can see who is pingable by typing @ and looking at the offered completions).

8
  • 1
    Backwards compatibility is important. New features are important too. The edit made the answer better in one sense, and made it worse in another, I wouldn't call that a good edit. It would have been better as a separate answer, or it could have just added the extra option without erasing the existing one.
    – Malabarba Mod
    Commented Nov 30, 2014 at 0:09
  • 1
    @Malabarba No, merely replacing with-eval-after-load with eval-after-load in that answer should have been an edit, not a separate answer. It isn't proposing a different method (it's not like the question was about running code when loading a package), it's just a minor improvement on an existing answer.
    – Gilles 'SO- stop being evil'
    Commented Nov 30, 2014 at 0:18
  • 1
    ok, I'll just accept our diverging opinions. :-) To me, there's value in teaching people about with-eval-after-load (and other new features), and simply replacing it with something else took that value away. Of course, it added value in terms of compatibility, but it still took something away.
    – Malabarba Mod
    Commented Nov 30, 2014 at 0:25
  • 2
    On the general topic of the question, 23.4 sounds like a good target for those authors who want to reach the most users.
    – Malabarba Mod
    Commented Nov 30, 2014 at 0:43
  • @Gilles I do not use 23.4. I do not even support it in any of my packages. How am I reasonably supposed to write answers about this release? !
    – user227
    Commented Nov 30, 2014 at 8:25
  • Besides, that relevance has Debian here? It's just one arbitrary distribution. I could just as well argue that Arch has 24.4 by now. Why should I write answers with outdated code, just because an arbitrary distribution ships outdated software? If 23.4 was the base line, we couldn't even recommend package.el...
    – user227
    Commented Nov 30, 2014 at 8:28
  • 1
    @lunaryorn I cited some popular distributions that ship older versions. I didn't cite Arch because it has a recent version, so it's irrelevant. The situation is not symmetric: newer versions can run code that works in older versions, but the converse is not true. You don't have to write answers about older releases than you're used to, but you should mention in your answer that it might not be suitable for most readers.
    – Gilles 'SO- stop being evil'
    Commented Nov 30, 2014 at 12:43
  • 3
    "If your answer requires 24.4 and the question didn't mention that, your answer has a high chance of not even being useful to the asker, let alone other visitors." This, this and this! Your answer belongs to you, but your primary goal should be to be useful to readers, not to try to force them to install the most recent version... For example, how about users who are using emacs at work?
    – T. Verron
    Commented Dec 1, 2014 at 9:47
2

Within reason, an answer which is more widely compatible with different versions of Emacs is more useful (in general) to one which is specific to only the latest version (or to un-released versions).

Personally I think that:

  • Authors are under no obligation to research whether their solution is backwards-compatible.
  • Edits for backwards-compatibility can be a very good thing.
  • Authors are entirely justified in rolling back any edit they dislike...
  • ...but when doing so, should be encouraged to, in some way, retain the compatibility information from that edit (whether in their own additional edit, or as a comment).

In this instance, a mention that "For Emacs versions < 24.4, change (with-eval-after-load 'flycheck (unless to (eval-after-load 'flycheck '(unless" would seem perfectly adequate.

1
  • Good point of view (some other answers here are also good) - I agree with all you say. Just editing to make something backward-compatible can be helpful, but it is not as helpful as telling users why, perhaps mentioning both possibilities (and any drawbacks/limitations).
    – Drew
    Commented Jan 12, 2019 at 2:47

You must log in to answer this question.