GNU bug report logs - #31796
26.1; dired-do-find-regexp-and-replace fails to find multiline regexps

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Andreas Abel <abela <at> chalmers.se>
Cc: 31796 <at> debbugs.gnu.org
Subject: bug#31796: 27.1; dired-do-find-regexp-and-replace fails to find multiline regexps
Date: Tue, 24 Nov 2020 17:43:53 +0200

On 24.11.2020 17:16, Eli Zaretskii wrote:

> In fact, some of the passion in Dmitry's response wasn't directed at
> you, it was directed at myself and other senior maintainers who
> frequently object to changes and/or request complicated
> backward-compatibility shims, for that very reason.

In a way, perhaps. Even though I've been on the other side of these 
discussions as well.

But I was mostly pointing out a logical incompatibility to a user who 
installs a new release, but doesn't want to see anything change, ever.

> So please don't assume we don't care about stability, or don't care
> enough.  It would be simply unfair to make such assumptions.  We
> certainly don't need lectures about keeping Emacs stable and
> compatible.

That's true.

> What you see in this case is not the result of negligence or
> carelessness, it is the result of not being aware of this (relatively
> rare) use case becoming broken when we changed the UI of this and
> similar commands to a more convenient one.  It took time for people to
> report the problem, and it takes us more time to come up with a good
> solution.  That's all.

We've been aware of it for at least two years now. So what are we, then, 
negligent, careless, or incompetent?

If you're saying we can't afford to break even a minor feature like 
this, I don't think there are a lot of options.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.