bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline

[Drew Adams <drew.adams@oracle.com>]

> > > > Do I understand correctly (forgive me if wrong; I have not
> > > > studied this, and my Emacs 25 build is quite old) that `A'
> > > > in Dired is now bound by default to a command that requires
> > > > a user to have an external `grep' command?  (This was not
> > > > the case previously.)
> > >
> > > Yusss. And 'find', too.
> >
> > Ugh.  Hard to believe this got accepted, replacing a perfectly
> > good command that everyone could use (and has used, for decades) -
> > no dependency on anything outside Emacs, worked on all platforms.
> 
> It didn't replace the old command, that one is still there, it just
> doesn't have a key binding by default.

It's the new feature that should perhaps not have a key.  At
least it should not grab an existing key.  There are plenty of
unbound keys in Dired.  And why not just provide the command,
for now, and let users bind it themselves if they like?

> > This new feature should have been added as, uh, err, well, just
> > a new feature - a new command, totally unrelated to existing `A'
> > etc.  Bad idea to usurp `A' for a command that requires a user
> > to have `grep' and `find'.  Bad Emacs.
> 
> We want to stop maintaining the etags-derived UI for moving
> through hits, so this is part of a plan.

So what?  Introduce the new as optional behavior.  Let users
decide.  What's the hurry to replace?

> > But it seems that the new trend in Emacs Dev is to willy nilly
> > replace longstanding stuff, rather than just introducing new
> > stuff, letting users experiment with it, and after years of
> > experience and feedback PERHAPS change some default behavior
> > to make better use of it by default.
> 
> FUD.  As a matter of fact, we did exactly what you call for:
> introduced a new UI and commands to go with them, and let users
> experiment with them, while the old ones are still available, and the
> way to get back old behavior is described in NEWS.

You changed the default behavior immediately.  That's a far
cry from providing, say, an ELPA package with the new feature
and letting users adopt it by choice, and then, after a few
years, discussing and deciding whether to replace the existing
default behavior.  What's the hurry to replace?

> OTOH, when Drew will stop assuming "Emacs devs" have ill will, and
> release knee-jerk reactions, such as this one, based on that, is
> anyone's guess.

When will Eli stop personalizing everything?

I don't claim ill will - never have.  I do see a difference
in approach from what has been the practice.

What's the imperative behind this key-binding replacement?
Why not just offer the new feature as a plus, not a
plus-and-minus?