bug#35360: 26.2; Default bindings of `A' and `Q' in Dired, for MS Windows users

bug#35360: 26.2; Default bindings of `A' and `Q' in Dired, for MS Windows users

[Drew Adams]

These keys used to be bound to `dired-do-search' and
`dired-do-query-replace-regexp', by default.  Those commands, which
still exist (good), do not require a Windows user to have `find' or
`grep' OS commands available.  They require only an Emacs TAGS file.

Shouldn't the default bindings of `A' and `Q' DTRT on MS Windows out of
the box?  Why assume that Windows users have GNU/Linux commands or their
equivalents?  Can't Emacs either bind these keys to what they were bound
to previously or test first whether the requisite OS commands are
available before binding these keys to Emacs commands that won't be
usable for many Windows users?

It would be better, IMHO, to keep `A' and `Q' bound to their previous,
TAGS-based commands, and introduce new key bindings for the new xref
commands.  That would not break existing keys for MS Windows users.  And
if the availability of OS commands needed by the xref functions were
tested first then the new xref-command key bindings could be skipped if
those OS commands are not present.

In such an approach all users, on all platforms, would all once again
have the same commands for `A' and `Q'.

In GNU Emacs 26.2 (build 1, x86_64-w64-mingw32)
 of 2019-04-13
Repository revision: fd1b34bfba8f3f6298df47c8e10b61530426f749
Windowing system distributor `Microsoft Corp.', version 10.0.17134
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

bug#35360: 26.2; Default bindings of `A' and `Q' in Dired, for MS Windows users

[Eli Zaretskii]

> Date: Sun, 21 Apr 2019 13:47:26 +0000 (UTC)
> From: Drew Adams <drew.adams@oracle.com>
> 
> These keys used to be bound to `dired-do-search' and
> `dired-do-query-replace-regexp', by default.  Those commands, which
> still exist (good), do not require a Windows user to have `find' or
> `grep' OS commands available.  They require only an Emacs TAGS file.
> 
> Shouldn't the default bindings of `A' and `Q' DTRT on MS Windows out of
> the box?  Why assume that Windows users have GNU/Linux commands or their
> equivalents?  Can't Emacs either bind these keys to what they were bound
> to previously or test first whether the requisite OS commands are
> available before binding these keys to Emacs commands that won't be
> usable for many Windows users?

Patches welcome to use Lisp replacements for 'find' and 'grep' on
Windows (with a defcustom that will allow to use the external programs
when they are available).

> It would be better, IMHO, to keep `A' and `Q' bound to their previous,
> TAGS-based commands, and introduce new key bindings for the new xref
> commands.

I don't think this is going to happen, nor that it should happen.
We've had this discussion before, I think more than once, it's time to
let go.

bug#35360: 26.2; Default bindings of `A' and `Q' in Dired, for MS Windows users

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Patches welcome to use Lisp replacements for 'find' and 'grep' on
> Windows (with a defcustom that will allow to use the external programs
> when they are available).

Something like ls-lisp? Yes, that would be useful. We shall change the
title of this bug report, or divide it even into two reports, for
find-lisp and grep-lisp.

Best regards, Michael.

bug#35360: 26.2; Default bindings of `A' and `Q' in Dired, for MS Windows users

[Drew Adams]

> > Patches welcome to use Lisp replacements for 'find' and 'grep' on
> > Windows (with a defcustom that will allow to use the external programs
> > when they are available).
> 
> Something like ls-lisp? Yes, that would be useful. We shall change the
> title of this bug report, or divide it even into two reports, for
> find-lisp and grep-lisp.

That would be good.  But please create separate bug
reports for such enhancements.  Don't just retitle
this thread and change its meaning.

This bug thread is about the binding of commands that
cannot possibly work out of the box for MS Windows
users, where by out-of-the-box I mean without knowing
that they need to install some additional software
and then installing that.

And this thread is about the broken repurposing of
bindings that previously worked for such users - and
whose previous commands still work for them (and for
everyone else).

However you look at it, until/unless the enhancement
requests that Michael suggests are available this bug
needs fixing.  MS Windows users have lost something,
out of the box, at least.

As the first line of this thread says, "Shouldn't the
default bindings of `A' and `Q' DTRT on MS Windows out
of the box?"  That's what this bug is about.  How the
bug gets fixed is another matter.

If we won't restore `A' and `Q' to what they were before
for everyone (and Eli says we won't) then can we not do
something else to restore/replace what we broke for
Windows users by changing their bindings to commands
that they can use?  That is, not change `A' and `Q' back
for everyone, but do so for those that need a workaround.

As I said at the outset, "Can't Emacs either bind these
keys to what they were bound to previously [for Windows
users] or test first whether the requisite OS commands
are available before binding these keys to Emacs commands
that won't be usable for many Windows users?"

IOW, if we insist on binding `A' and `Q' generally to
commands that cannot be used by such users then can we
not at least fall back - for them - to commands that do
work?  Why make users themselves discover the gotcha
individually and work around it?

bug#35360: 26.2; Default bindings of `A' and `Q' in Dired, for MS Windows users

[Eli Zaretskii]

> Date: Sun, 21 Apr 2019 12:53:04 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 35360@debbugs.gnu.org
> 
> > > Patches welcome to use Lisp replacements for 'find' and 'grep' on
> > > Windows (with a defcustom that will allow to use the external programs
> > > when they are available).
> > 
> > Something like ls-lisp? Yes, that would be useful. We shall change the
> > title of this bug report, or divide it even into two reports, for
> > find-lisp and grep-lisp.
> 
> That would be good.  But please create separate bug
> reports for such enhancements.  Don't just retitle
> this thread and change its meaning.
> 
> This bug thread is about the binding of commands that
> cannot possibly work out of the box for MS Windows
> users, where by out-of-the-box I mean without knowing
> that they need to install some additional software
> and then installing that.
> 
> And this thread is about the broken repurposing of
> bindings that previously worked for such users - and
> whose previous commands still work for them (and for
> everyone else).

If you think that discussing ways to fix the problem for Windows users
who don't have 'find' and 'grep' does not belong to this bug report,
then why did you file this bug report?  Isn't fixing the problem the
goal of this report?  If not, what is its goal?

> However you look at it, until/unless the enhancement
> requests that Michael suggests are available this bug
> needs fixing.  MS Windows users have lost something,
> out of the box, at least.

We are discussing how to provide that.  What is it that you don't like
about this discussion?

> As the first line of this thread says, "Shouldn't the
> default bindings of `A' and `Q' DTRT on MS Windows out
> of the box?"  That's what this bug is about.  How the
> bug gets fixed is another matter.

Saying that we should fix it by replacing 'find' and 'grep' in Lisp
answers that question in my book.  By fixing the bug we acknowledge
that the answer to the question is positive.

> If we won't restore `A' and `Q' to what they were before
> for everyone (and Eli says we won't) then can we not do
> something else to restore/replace what we broke for
> Windows users by changing their bindings to commands
> that they can use?  That is, not change `A' and `Q' back
> for everyone, but do so for those that need a workaround.

This is the wrong way of fixing the problem, and therefore we won't do
it, as I said in my previous message.

bug#35360: 26.2; Default bindings of `A' and `Q' in Dired, for MS Windows users

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Drew Adams <drew.adams@oracle.com>,  35360@debbugs.gnu.org
> Date: Sun, 21 Apr 2019 21:25:33 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Patches welcome to use Lisp replacements for 'find' and 'grep' on
> > Windows (with a defcustom that will allow to use the external programs
> > when they are available).
> 
> Something like ls-lisp? Yes, that would be useful. We shall change the
> title of this bug report, or divide it even into two reports, for
> find-lisp and grep-lisp.

find-lisp.el already exists, as you know.  So I think we need a simple
extension of it, or maybe this is already supported, so we need to use
it.

bug#35360: 26.2; Default bindings of `A' and `Q' in Dired, for MS Windows users

[Drew Adams]

> > > > Patches welcome to use Lisp replacements for 'find' and 'grep' on
> > > > Windows (with a defcustom that will allow to use the external programs
> > > > when they are available).
> > >
> > > Something like ls-lisp? Yes, that would be useful. We shall change the
> > > title of this bug report, or divide it even into two reports, for
> > > find-lisp and grep-lisp.
> >
> > That would be good.  But please create separate bug
> > reports for such enhancements.  Don't just retitle
> > this thread and change its meaning.
> >
> > This bug thread is about the binding of commands that
> > cannot possibly work out of the box for MS Windows
> > users, where by out-of-the-box I mean without knowing
> > that they need to install some additional software
> > and then installing that.
> >
> > And this thread is about the broken repurposing of
> > bindings that previously worked for such users - and
> > whose previous commands still work for them (and for
> > everyone else).
> 
> If you think that discussing ways to fix the problem for Windows users
> who don't have 'find' and 'grep' does not belong to this bug report,
> then why did you file this bug report?  Isn't fixing the problem the
> goal of this report?  If not, what is its goal?

Certainly if you do fix the problem in the way suggested
by Michael then this bug report will also be taken care of.

But this need not wait to be fixed that way - it need not
wait (how long?) for such a complete solution.

We have, essentially, a regression.  There are simple ways
to work around it - while waiting for the more complete
solution that Michael suggests.  My suggestion is to do one
of those things _until or unless_ the more complete solution
is available.  Let's not just leave things broken until then.

IOW, fix this quickly in some less-than-perfect way, to get
things back to "normal" in some sense.  That does not prevent
a more satisfactory solution being implemented.

If you prefer to keep all of that in the same bug thread
that's fine by me.  But I would like to see a quick fix
in some way.  What I don't want to see is nothing happen,
in the vague hope that someday there will be pie in the
sky.  If/when there is pie in the sky I'll be happy, of
course.

> > However you look at it, until/unless the enhancement
                            ^^^^^^^^^^^^
> > requests that Michael suggests are available this bug
> > needs fixing.  MS Windows users have lost something,
> > out of the box, at least.
> 
> We are discussing how to provide that.  What is it that you don't like
> about this discussion?

See above.  I have no problem with discussing, as long as
the ideal doesn't become the enemy of the immediately good.

> > As the first line of this thread says, "Shouldn't the
> > default bindings of `A' and `Q' DTRT on MS Windows out
> > of the box?"  That's what this bug is about.  How the
> > bug gets fixed is another matter.
> 
> Saying that we should fix it by replacing 'find' and 'grep' in Lisp
> answers that question in my book.  By fixing the bug we acknowledge
> that the answer to the question is positive.

Great.  And how about a quick workaround fix in the mean
time?

> > If we won't restore `A' and `Q' to what they were before
> > for everyone (and Eli says we won't) then can we not do
> > something else to restore/replace what we broke for
> > Windows users by changing their bindings to commands
> > that they can use?  That is, not change `A' and `Q' back
> > for everyone, but do so for those that need a workaround.
> 
> This is the wrong way of fixing the problem, and therefore we won't do
> it, as I said in my previous message.

I said from the outset that it is not the right fix.
But it is a quick workaround to back out of a regression
for those users affected.  When do you expect to have the
right fix implemented.

In any case, I'm happy and grateful to hear that you intend
to fix this correctly.

bug#35360: 26.2; Default bindings of `A' and `Q' in Dired, for MS Windows users

[Eli Zaretskii]

> Date: Mon, 22 Apr 2019 02:58:41 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: michael.albinus@gmx.de, 35360@debbugs.gnu.org
> 
> > If you think that discussing ways to fix the problem for Windows users
> > who don't have 'find' and 'grep' does not belong to this bug report,
> > then why did you file this bug report?  Isn't fixing the problem the
> > goal of this report?  If not, what is its goal?
> 
> Certainly if you do fix the problem in the way suggested
> by Michael then this bug report will also be taken care of.
> 
> But this need not wait to be fixed that way - it need not
> wait (how long?) for such a complete solution.

If you, or someone else, submit a fix soon, then the problem will be
solved soon.  I don't know how to fix the problem sooner than a patch
for it is available.

> We have, essentially, a regression.  There are simple ways
> to work around it - while waiting for the more complete
> solution that Michael suggests.  My suggestion is to do one
> of those things _until or unless_ the more complete solution
> is available.  Let's not just leave things broken until then.

We don't want to use the workaround you suggested, because it's a step
backward.

> In any case, I'm happy and grateful to hear that you intend
> to fix this correctly.

That should have been clear since the first response to your bug
report.