bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#31796: 27.1; dired-do-find-regexp-and-replace fails to find multilin


From: Andreas Abel
Subject: bug#31796: 27.1; dired-do-find-regexp-and-replace fails to find multiline regexps
Date: Tue, 24 Nov 2020 00:49:24 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.4.3

With a software as old as emacs the most important feature is

  1. backwards-compatibility

The second most important feature is

  2. backwards-compatibility

The third most important feature is

  3. backwards-compatibility

It is like with C and LaTeX. If you cannot ensure that things keep working as they did, don't change anything.

Tramp?  I had to google this term.

How often do programmers work on their local files in their day-to-day business, how often with remote files via tramp?

If you contribute a new feature for 0.1% percent of the use cases but disrupt something (even minor) for 99.9% of the use cases, then with an old tool like emacs the choice is: don't replace the old functionality with your new functionality.

Just don't break things.  Please.

If you want fancy functionality that works with remote files, this is fine. There are enough keys on the keyboard you can bind the new functionality to.

Please don't break things that worked.

There are gazillion emacs users out there that dread each new emacs version because it will break their setup, their workflows, their habits. We do not want to spend days after upgrades to get our work environment back.

We value stability and conservativity over everything else.

Thanks to everyone who contributes to emacs.  --Andreas

On 2020-11-23 22:28, Dmitry Gutov wrote:
On 23.11.2020 11:09, Andreas Abel wrote:
- Why isn't the more robust

   dired-do-query-replace-regexp

bound to Q?

Which is the "more robust", though? dired-do-query-replace-regexp doesn't work with Tramp. dired-do-find-regexp-and-replace does.

And even if the former is fixed to work, the latter will work much faster remotely. It's also going to be faster in many "local" cases too.

If we don't manage to find a portable enough solution to do multiline searches, we could at least warn the user interactively about unsupported features, though.

--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel@gu.se
http://www.cse.chalmers.se/~abela/





reply via email to

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