bug#24977: 25.1; search and query-replace in Dired

bug#24977: 25.1; search and query-replace in Dired

[Drew Adams]

You unwisely changed `A' and `Q' in Dired to two completely different
commands.  You ignored arguments for keeping these as they were and
creating new bindings for the new, completely different, search and
replacement commands you provided.  You even claimed that you intend to
deprecate the "old" commands.  All of that is sorely misguided.

See bug #23428 for background:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23428

However, you did NOT change the menu bindings for `dired-do-search' and
`dired-do-query-replace-regexp' (the commands formerly bound to `A' and
`Q').  This is inconsistent.  Those menu items no longer show the
keyboard shortcuts, because they have none.  And the new commands are
not on menus at all.

It was unwise to change the key bindings.  They should be restored, and
new bindings should be sought for your new commands.

And the "old" commands should definitely not be deprecated.  The new
commands do NOT AT ALL replace their functionality.

The new commands are not incremental.  You cannot change the search
patterns on the fly.  Nor can you add and remove filter predicates on
the fly.

And of the new are limited to the kinds of regexps supported by certain
`grep' commands, which are external to Emacs.  The "old" require no
programs outside Emacs, and they support all Emacs regexps, including
those that match multiple lines.

The new commands are essentially just `grep' or `find' cousins.  They
are fine to have - in addition.  But they should not have usurped the
longstanding keybindings.

Please reconsider: Restore the `A' and `Q' keybindings as they were, and
come up with _additional_ key bindings for the new commands.  The new
commands are NOT better or a replacement; they are simply different.
Their power is strictly MORE limited (not incremental, and only limited
regexps), even if they do have certain advantages for certain cases
(fast, global view).

There is no need to wipe out extremely useful commands and their
bindings, just because you come up with new commands that do something
somewhat similar.

No users asked for these key-binding changes.  There was no reason you
could not add without subtracting.  Users and Emacs Dev can decide over
time, based on feedback and usage, which are the best keys for which
commands and whether any of the commands should be deprecated.  This
switcheroo was unnecessarily precipitous (if not downright arrogant).


In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-17 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --without-dbus --without-compress-install CFLAGS=-static'

bug#24977: 25.1; search and query-replace in Dired

[Drew Adams]

Sorry, this part of the bug report was not relevant (the
old commands are also not incremental):

 "The new commands are not incremental.  You cannot change
  the search patterns on the fly.  Nor can you add and
  remove filter predicates on the fly."

---

BTW: The correspondence between the key for `dired-do-search'
(`A') and the keys for incremental search has been lost.

An effort was made to give the Isearch key bindings for
Dired the same mnemonic as that for `dired-do-search': `a'
for `A' (`M-s' is the Isearch prefix).

 dired-do-search          A
 dired-do-isearch         M-s a C-s
 dired-do-isearch-regexp  M-s a C-M-s

bug#24977: 25.1; search and query-replace in Dired

[Tino Calancha]

Drew Adams <drew.adams@oracle.com> writes:

> You unwisely changed `A' and `Q' in Dired to two completely different
> commands. You even claimed that you intend to
> deprecate the "old" commands.
I sometimes need to use `Q' command.  I prefer
`dired-do-query-replace-regexp', because it acepts Emacs regexp syntaxis.

It's confusing that '% g' handles Emacs regexp but `Q' or `A' use
a different one: IMO, it's more natural if we bind to keys those
commands accepting the native regexp syntaxis.

bug#24977: 25.1; search and query-replace in Dired

[Eli Zaretskii]

> Date: Sun, 20 Nov 2016 17:54:18 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> However, you did NOT change the menu bindings for `dired-do-search' and
> `dired-do-query-replace-regexp' (the commands formerly bound to `A' and
> `Q').  This is inconsistent.  Those menu items no longer show the
> keyboard shortcuts, because they have none.  And the new commands are
> not on menus at all.

Thanks, I fixed that now.

> It was unwise to change the key bindings.  They should be restored, and
> new bindings should be sought for your new commands.

Let's not start beating this dead horse again.

bug#24977: 25.1; search and query-replace in Dired

[Drew Adams]

> > However, you did NOT change the menu bindings for `dired-do-
> > search' and `dired-do-query-replace-regexp' (the commands formerly
> > bound to `A' and `Q').  This is inconsistent.  Those menu items no
> > longer show the keyboard shortcuts, because they have none.  And
> > the new commands are not on menus at all.
> 
> Thanks, I fixed that now.
> 
> > It was unwise to change the key bindings.  They should be
> > restored, and new bindings should be sought for your new commands.
> 
> Let's not start beating this dead horse again.

Then you did NOT fix this bug, and it should be closed as `wont fix'.
That's your choice, but please do not claim that you fixed the bug
that was reported if you did not.

The original search and query-replace commands, which were in the
menu, should also have keyboard key bindings (as before).  AND the
new commands should be added to the menu.

For the menu, I suggest:

 `Search Files' - as before
 `Search Files using `find' - for the new command

 `Query Replace' - as before
 `Query Replace using `find' - for the new command

Logically, the longstanding key bindings `A' and `Q' should be
restored to the original commands.  But if you refuse that then
they should at least be given other key bindings - `M-a' and
`M-q', for example.

Doing this, you can rightfully close this bug as fixed.
Otherwise, no.

bug#24977: 25.1; search and query-replace in Dired

[Dmitry Gutov]

On 21.11.2016 16:07, Tino Calancha wrote:

> I sometimes need to use `Q' command.  I prefer
> `dired-do-query-replace-regexp', because it acepts Emacs regexp syntaxis.

Please file provide examples (maybe in a new bug report), and I'll 
strive to fix those.

There will always remain edge cases, but the simpler ones should be 
doable without too much effort.

bug#24977: 25.1; search and query-replace in Dired

[Drew Adams]

> > I sometimes need to use `Q' command.  I prefer
> > `dired-do-query-replace-regexp', because it acepts Emacs regexp
> > syntaxis.
> 
> Please file provide examples (maybe in a new bug report), and I'll
> strive to fix those.

As already mentioned in this bug report:

* Any multiline regexp.

* Any regexp that is outside what the current `grep' syntax uses.

bug#24977: 25.1; search and query-replace in Dired

[Dmitry Gutov]

On 21.11.2016 19:41, Drew Adams wrote:

> * Any multiline regexp.

We obviously can't support those.

> * Any regexp that is outside what the current `grep' syntax uses.

Those should be doable, as long as the regexp contains at least 
_something_ else. So if we identify the examples that are actually 
important, that would speed things along.

bug#24977: 25.1; search and query-replace in Dired

[Drew Adams]

> > * Any multiline regexp.
> 
> We obviously can't support those.

But the commands whose bindings you displaced DO support them.

This is a major reason for this bug report (and bug #23428).
The replacement is strictly less powerful.  It is essentially
just a `grep' or `find'.  (And it depends on an outside program.)

> > * Any regexp that is outside what the current `grep' syntax uses.
> 
> Those should be doable, as long as the regexp contains at least
> _something_ else.

What does that mean?  Specify what you mean by "_something_ else".
Clearly you do NOT mean to support the regexps that Emacs supports.

> So if we identify the examples that are actually
> important, that would speed things along.

See above.  If you cannot replace Emacs regexp power, that's
OK, as long as we keep also the displaced commands that do
provide Emacs regexp power.

And those commands should preferably keep their longstanding
keybindings.

There is _no reason_ that you could not just add your new
commands and give them new keys.  This seems to have been a
gratuitous, and if not arrogant, expropriation.

bug#24977: 25.1; search and query-replace in Dired

[Dmitry Gutov]

On 21.11.2016 20:37, Drew Adams wrote:

> This is a major reason for this bug report (and bug #23428).
> The replacement is strictly less powerful.  It is essentially
> just a `grep' or `find'.  (And it depends on an outside program.)

It might be less powerful. On the flip side, the replacement is usually 
faster. Especially in the "many files, few matches" situations.

>> Those should be doable, as long as the regexp contains at least
>> _something_ else.
>
> What does that mean?  Specify what you mean by "_something_ else".
> Clearly you do NOT mean to support the regexps that Emacs supports.

For instance, if the regexp contains a simple literal and an Emacs-only 
construct, we can remove the latter before passing the regexp to 
find+grep, and then post-process the results inside Emacs using the full 
syntax.

bug#24977: 25.1; search and query-replace in Dired

[Drew Adams]

> > This is a major reason for this bug report (and bug #23428).
> > The replacement is strictly less powerful.  It is essentially
> > just a `grep' or `find'.  (And it depends on an outside program.)
> 
> It might be less powerful. On the flip side, the replacement is
> usually faster. Especially in the "many files, few matches" situations.

Yes, I acknowledged that the new commands are very good - good UIs
and very quick (including the search part, not just the replacement).

I have no argument with the new commands.  My argument is to keep
the old commands as well, with their bindings and menu items, and
to give the new commands new bindings and new menu items.

I don't even have a problem with Emacs putting the new commands
in the forefront somehow, making them more prominent in the doc
or whatever.  My complaint is quite limited - and reasonable, I
think.

> >> Those should be doable, as long as the regexp contains at least
> >> _something_ else.
> >
> > What does that mean?  Specify what you mean by "_something_ else".
> > Clearly you do NOT mean to support the regexps that Emacs
> > supports.
> 
> For instance, if the regexp contains a simple literal and an Emacs-
> only construct, we can remove the latter before passing the regexp to
> find+grep, and then post-process the results inside Emacs using the
> full syntax.

If I understand what you're saying, that would probably be an
improvement, yes.  It would need to be pointed out clearly to
users that that is what happens.  When you kinda sorta sometimes
get behavior that is similar to what you might expect (e.g. from
the regexp alone), the actual behavior can be all the more
confusing if this difference is not described clearly.

bug#24977: 25.1; search and query-replace in Dired

[Dmitry Gutov]

On 21.11.2016 20:51, Drew Adams wrote:

> I have no argument with the new commands.  My argument is to keep
> the old commands as well, with their bindings and menu items, and
> to give the new commands new bindings and new menu items.

Because that wouldn't be confusing. Either the menu items will look 
almost the same (but perform slightly differently), or they will have to 
be very long, to describe the difference.

> When you kinda sorta sometimes
> get behavior that is similar to what you might expect (e.g. from
> the regexp alone), the actual behavior can be all the more
> confusing if this difference is not described clearly.

Indeed. But careful handling of uncertain cases and showing user-error 
for tricky regexps should make the behavior make sense.

bug#24977: 25.1; search and query-replace in Dired

[Drew Adams]

> > I have no argument with the new commands.  My argument is to keep
> > the old commands as well, with their bindings and menu items, and
> > to give the new commands new bindings and new menu items.
> 
> Because that wouldn't be confusing. Either the menu items will look
> almost the same (but perform slightly differently), or they will
> have to be very long, to describe the difference.

They _should_ be similar because the functionality is similar
(regexp search & query-replace).  Their difference should reflect
their main difference.  The main difference I see is that one
searches using (any) Emacs regexps and the other searches using
`find' (with all of its advantages and disadvantages).

"... Using `find'" or "... With `find'" in the new menu items is
not long, and it says quite a _lot_ about what the command does.

> > When you kinda sorta sometimes
> > get behavior that is similar to what you might expect (e.g. from
> > the regexp alone), the actual behavior can be all the more
> > confusing if this difference is not described clearly.
> 
> Indeed. But careful handling of uncertain cases and showing user-
> error for tricky regexps should make the behavior make sense.

Making some more sense is no doubt possible.  Handling some
more cases is no doubt possible.  But as you said, some things
are not possible ("We obviously can't support those"), and any
simulation of ordinary Emacs searching would be ad hoc.

Again, I have no problem with adding these useful commands.
The problem is subtracting the older, also useful commands
(and their key bindings).  There is no reason to do that.