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

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

> > 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?
> 
> Because we want to provide a coherent, consistent interface to the
> users. Since M-. has changes to the xref UI,

Same issue there.  Why replace that key binding?  Why not provide
your new feature separately?  What's the need to replace (now)?

I understand that you think this new does everything the old does,
and better.  That's still not a good reason to replace the old
immediately (including just taking over its key bindings).

Just add the new - that should be enough.  If it truly does
everything the old does, and better, that will soon enough be
clear to all, and there will be time enough to move out the old
eventually.

Emacs has long had parallel, different-behaving features that
filled more or less the same needs for users.  We haven't felt
the imperative to replace one with another.  You can use many
different commands or UIs in Emacs to get the same job done.
You can even emulate VI and CUA in Emacs.  Emacs has been a
big tent, not an in-with-the-new-way-out-with-the-old puptent.

I welcome a show-all-search-hits-and-let-me-filter-and-choose
approach for Dired searching.  I've even developed such features
myself, for my own use.  I do not object to this feature - quite
the opposite.

What I question is replacing the existing features - and yes,
even just appropriating their key bindings.  That is not
necessary - is it?  Can't you just add this feature, without
fiddling with the existing, different ways to search?  Why
must you insist on replacing and not be content to add?

> > 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?
> 
> xref could have been incubated in ELPA, and that would have been a
> reasonable choice as well, but at the time it was decided to be good
> enough to be installed in the core already. So that ship has sailed.

"That ship has sailed" seems to be the latest excuse for all kinds
of stuff.  Never heard that as an excuse here in past years.

And no; nothing has sailed.  None of this stuff has "shipped".
Not curly-quotitis, and not this feature.

This is a relatively recent phenomenon: wide-ranging, quick
changes to C code etc., followed by "too late to question;
already done; too late to back out now", even before released.

> >> 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?
> 
> There's no need to blame Eli for this, that's for sure.

I don't blame him (or anyone in particular) for the feature.
I mentioned Eli by name because he mentioned me by name, and
he attributed false motives to me.  My complaint was about his
personalizing things, not about his support of this feature.