[Top][All Lists]

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

Re: Confused by y-or-n-p

From: Gregory Heytings
Subject: Re: Confused by y-or-n-p
Date: Wed, 06 Jan 2021 09:41:09 +0000
User-agent: Alpine 2.22 (NEB 394 2020-01-19)

I agree with you that this is already happening in the vast majority of cases, so why would it be problematic to make this a rule, that in principle any change to Emacs' behavior should provide a way to re-enable the old behavior? IIUC that's all Richard wants. Of course that rule would not apply to bugfixes, and exceptions would be possible with the explicit approval of a maintainer.

The problem is that I disagree with your "Of course": the whole difficulty is to decide which change falls in this category.

The problem is not that we don't follow the rule or that we don't have such a rule. It's that there's no hard-and-fast way to decide where that rule should apply: it's a judgment call and often this call is non-trivial (what one person calls "feature" qualifies as "bug fix" for another, what should be a cosmetic change may end up unexpectedly changing behavior), which is why sometimes it takes feedback from users to realize we got it wrong.

A rule is not a mathematical law, it's an action guideline. Such a rule would avoid having developers start working on something thinking that scratching the current state of affairs to create something they believe is better without thinking about backwards compatibility is okay.

This does happen, and this can lead and does lead to unnecessary disputes (one is underway), that could be avoided with such a rule.

By the way, the feedback in this case came from Richard, who wanted the old behavior back, and he got it back in a few days. I'm curious whether this would have happened if the feedback had been sent by a random user.

reply via email to

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