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

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

[Drew Adams]

> > I'm trying to be clear that I _welcome_ your feature,
> > based on the description.  It sounds like something useful.
> >
> > I just don't think it's great that you feel you should
> > immediately replace other, existing ways to search,
> > including grabbing their key bindings.
> 
> Maybe you should actually try it before talking about it.

I'm not talking about it.  I'm talking about what it's replacing.

I can assume that it is wonderful.  And I understand something
about the usefulness of users seeing a set of search hits
together and being able to filter and choose among them.
I don't, for even a moment, doubt its advantages.

None of that speaks to why it should replace, instead of be an
addition to, the longstanding `A' and `Q' behavior, which do
not let users see a set of search hits.

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

[Drew Adams]

> > How can the new be considered a sufficient replacement, if it
> > means that `A' and `Q' no longer work for users without `grep'
> > or `find'?
> 
> We obviously don't consider that such a serious obstacle, and the
> commands are not popular enough for that to be an issue.

If you leave those keys alone then there is no issue whatsoever.
Users who want the traditional `A' and `Q' behavior need not
install `grep' or `find'.  Users who want the new behavior can
do so if they need to - no problem.

> > This change is not present in any Emacs release AFAIK.
> 
> I don't see how this fact is relevant.  The discussions were held here
> and on emacs-devel, with you and others reading it.

Sorry, but you don't know what I read and don't read.

> > > You were here all that time, so I don't understand why you raise
> > > this only now.
> >
> > Dunno what you mean by "here".
> 
> Here on this mailing list.

I read some messages in some bug reports, but certainly not most.

> > This is the first I've learned of this feature and the fact that it
> > requires users to install `grep' and `find' commands to use `A' and
> > `Q' in Dired.
> 
> May I suggest to pay more attention to on-going discussions in the
> future?

You can suggest it, but I already spend far too much time paying
attention to ongoing discussions here.

> > Had you simply _added_ this feature and not usurped the existing
> > bindings, you would likely have heard nothing from me about this.
> 
> These commands were introduced with the explicit intent to replace the
> old ones as 'A' and 'Q' bindings, so that tags-loop-continue would not
> be needed anymore.  Again, the discussions about that were all held
> here, for quite a few moons.

I give up.

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

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

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

>> These commands were introduced with the explicit intent to replace the old
>> ones as 'A' and 'Q' bindings, so that tags-loop-continue would not be
>> needed anymore. Again, the discussions about that were all held here, for
>> quite a few moons.

> I give up.

Hi Drew,

I think all of this is happening in an attempt to re-establish consistency
among usage patterns, keybindings, and other features, so that the old tag
lookup functionality can be entirely replaced by the new xref functionality.

Could it all have happened differently? Sure; but as Eli and Dmitry have said,
that ship has sailed. It happened under a different maintainer, and so now we
have to accept what it is and work toward the best solution using this
technology. It's that, or rip it all out altogether, which Eli assures me
would be an unfortunate loss of time, energy, and some very nice improvements.

So, if we could all just take a pause: nothing is perfect, and we're now
trying to achieve the best stability we can in preparation for the next
release. I'm quite open to future proposals regarding 26, if you want to start
those discussions. Until then, let's try our best to help Eli and Dmitry and
others to get these features ready for prime-time, rather than continuing to
question things that happened and were discussed quite some months ago.

Thanks!
-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

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

[Drew Adams]

> I think all of this is happening in an attempt to re-establish consistency
> among usage patterns, keybindings, and other features, so that the old tag
> lookup functionality can be entirely replaced by the new xref
> functionality.
> 
> Could it all have happened differently? Sure; but as Eli and Dmitry have
> said, that ship has sailed. It happened under a different maintainer,
> and so now we have to accept what it is and work toward the best solution 
> using this technology. It's that, or rip it all out altogether, which
> Eli assures me would be an unfortunate loss of time, energy, and some
> very nice improvements.

It's not clear to me why you are saying this.  I certainly have not
requested any ripping out of anything - altogether or otherwise.  I
have not said anything negative about this technology - no complaints.

I asked only that `A' and `Q' be left bound to their commands (which
are still available).  As I said, if those bindings were not being
co-opted immediately then I would have had nothing to say here.

I've heard no reason why different bindings, instead, are not given
to the new search and search-and-replace features, at least as long
as the original commands are supported.  No reason, that is, beyond
the statement that the ultimate aim is to replace the older commands.

And even if `A' and `Q' were to be co-opted, if the new commands
worked for all users of the old, I would no doubt have said nothing.

I spoke up here when I guessed that some users of `A' and `Q' today
would be unable to use them tomorrow, without installing some
non-Emacs software.  I spoke up to ask whether my guess was correct
(yes).  And apparently I was not the only one to whom this was news.

If the older commands are to be replaced, and not just supplemented,
by the new ones, then I do think this is a step backward for someone
who does not have `grep' or `find' (I have both, so this is not a
problem for me personally).  That's my opinion, and it does not
imply or call for ripping out anything.

If the older commands are kept available and the new commands are
given different key bindings, I see no problem at all.

I have nothing against the addition of commands that use `grep' and
`find' and show you all search hits.  Quite the contrary.  As I said
clearly, I _welcome_ such an approach.  To which explicit welcome
the response was a sarcastic "That's very generous of you."

Is it possible to welcome the new commands but point out disagreement
with their being assigned the keys `A' and `Q'?

If this is all about "an attempt to re-establish consistency among
usage patterns, keybindings, and other features" then I do not see
the imperative of assigning `A' and `Q' immediately to these new
search commands.

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

[John Wiegley]

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

> I asked only that `A' and `Q' be left bound to their commands (which are
> still available). As I said, if those bindings were not being co-opted
> immediately then I would have had nothing to say here.

Ah, I see. My apologies, Drew, I thought your comments were directed at the
functionality underlying the new bindings, not simply the bindings themselves.

I'm sure this has been discussed at length somewhere that I missed, but can
someone direct me again to the rationale for changing the bindings of 'A' and
'Q'? I'd like to review it in the light of Drew's comments.

Thanks,
-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

[Eli Zaretskii]

> From: "John Wiegley" <johnw@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  23426@debbugs.gnu.org,  dgutov@yandex.ru,  heinz@h-rommerskirchen.de,  kaushal.modi@gmail.com
> Date: Wed, 04 May 2016 14:13:13 -0700
> 
> I'm sure this has been discussed at length somewhere that I missed, but can
> someone direct me again to the rationale for changing the bindings of 'A' and
> 'Q'? I'd like to review it in the light of Drew's comments.

Rather than embarking on a search, I just repeated the rationale in a
previous message.

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

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Rather than embarking on a search, I just repeated the rationale in a
> previous message.

Thanks, Eli!  It made sense, and was much appreciated.

One thing about a comment you made:

> If we will feel free to revert recent decisions just because the leader who
> made them stepped down, this will make the leadership position much less
> attractive.

Conversely, if the leadership (hi) feels bound to uphold recent decisions made
by predecessors, this also makes the position less attractive, because one
should be free to enact the changes one sees as better for Emacs.

I respect that the decision was made by many, so I don't ever approach
throwing it out lightly; but I reserve the right to get ornery if something
strikes me as truly terrible for our future.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

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

[Eli Zaretskii]

> Date: Wed, 4 May 2016 13:09:06 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 23426@debbugs.gnu.org, dgutov@yandex.ru,
>         heinz@h-rommerskirchen.de, kaushal.modi@gmail.com
> 
> I asked only that `A' and `Q' be left bound to their commands (which
> are still available).  As I said, if those bindings were not being
> co-opted immediately then I would have had nothing to say here.
> 
> I've heard no reason why different bindings, instead, are not given
> to the new search and search-and-replace features, at least as long
> as the original commands are supported.  No reason, that is, beyond
> the statement that the ultimate aim is to replace the older commands.

You did hear the reasons.  I have now repeated them in a previous
message.

> I spoke up here when I guessed that some users of `A' and `Q' today
> would be unable to use them tomorrow, without installing some
> non-Emacs software.

Those same users will have to download and install Emacs itself, and
most probably also download and install the new versions of support
libraries (which are distributed separately).  Why doing that is any
different from installing Grep and Findutils (which, btw, are
available from the same site as those optional libraries), is unclear
to me.  Installing GNU tools on Windows always required a certain
amount of "tinkering", so let's trust our Windows users a bit more
that they are not too inept, okay?

Heck, we don't even know how many Emacs users on MS-Windows out there
don't _already_ have those packages installed.  (My guess: zero.)  We
also don't know how many Windows users actually know or care about
these two specific Dired commands.  (My guess: not too many.)

> Is it possible to welcome the new commands but point out disagreement
> with their being assigned the keys `A' and `Q'?

Yes, it is.  But the style of doing that matters.  Try assuming that
the reasons for the decisions with which you disagree are not "rush",
or ineptitude, or lack of understanding of basic UI design.  You
complain about sarcasm, but have you considered the flood of sarcasm
that you repeatedly pour on us?

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

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  23426@debbugs.gnu.org,  dgutov@yandex.ru,  heinz@h-rommerskirchen.de,  kaushal.modi@gmail.com
> Date: Wed, 04 May 2016 11:20:31 -0700
> 
> Could it all have happened differently? Sure; but as Eli and Dmitry have said,
> that ship has sailed. It happened under a different maintainer, and so now we
> have to accept what it is and work toward the best solution using this
> technology. It's that, or rip it all out altogether, which Eli assures me
> would be an unfortunate loss of time, energy, and some very nice improvements.

If we will feel free to revert recent decisions just because the
leader who made them stepped down, this will make the leadership
position much less attractive.  Not a good thing for us, as a project.

The record shows that I was one of the first to publish criticism
about the XREF UI, and to some extent about the design of the features
based on it.  That criticism was mostly rejected (although some of it
was used to improve the implementation).  With that decision taken, in
full view of everyone on this list, to me it's what the project as a
whole decided.

That's what I mean by "that ship sailed".

To revert that decision would IMO entail demonstrating, beyond any
doubt, that these features are grossly inefficient, or incapable of
supporting reasonable workflows, and that the flaws are so inherent in
the design as to be beyond repair.

Any other criticism should be in the form of bug reports about
specific problems.  Arguments and "bug reports" in the "Carthago
delenda est" style are explicitly _unhelpful_ and not welcome, and IMO
are simply unfair to the project as a whole.

Let me repeat the rationale for those who somehow missed it: the
decision was to move the tags-* commands to the new infrastructure and
the new API.  As part of that, 'M-,' was rebound to a new xref
command, thus leaving tags-loop-continue without a binding, on the
assumption that tags-loop-continue is no longer important enough to
have a default keybinding.  (That, too, was a conscious decision,
discussed at length here.)  Switching Dired keybindings that invoked
commands which used tags-loop-continue to the new UI is a logical move
on the path to stop using tags-loop-continue and minimize/eliminate
the need for it to have a keybinding.

That is why 'A' and 'Q' in Dired were rebound to new commands that are
based on XREF.  There's no stupidity here, and no ill will; nothing
but a step that follows a decision made by the project leadership not
so long ago.  We should respect that decision, and work together on
improving the features and fixing any issues left.

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

[Heinz Rommerskirchen]

dired-do-find-regexp can't find matches for a regexp containing newline.
To trigger the bug:
- start "emacs -Q"
- open "/usr/local/share/emacs/25.0.93/etc/" in dired
- mark the file NEWS and maybe a few more
- type "A C-q C-j C-q C-j"
- there is a message in the echo area: "No matches for:

"
In former versions of Emacs (e.g. 24.5.1) this same recipe brought you 
to the first empty line in one of the marked files.

In GNU Emacs 25.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.7, 
cairo version 1.14.2)
  of 2016-04-28 built on canna
Windowing system distributor 'The X.Org Foundation', version 11.0.11702000
System Description:	openSUSE Leap 42.1 (x86_64)

Configured using:
  'configure --with-cairo --with-modules --with-xwidgets'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO IMAGEMAGICK SOUND GPM DBUS GCONF
GSETTINGS NOTIFY GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES XWIDGETS

Important settings:
   value of $LC_COLLATE: C
   value of $LC_NUMERIC: C
   value of $LANG: de_DE.UTF-8
   value of $XMODIFIERS: @im=local
   locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   buffer-read-only: t
   line-number-mode: t
   transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
user-error: No matches for:
  [2 times]
Note: file is write protected
<C-f4> is undefined
user-error: No matches for:

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
password-cache epg epg-config gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils find-dired
semantic/fw mode-local find-func xref cl-seq project eieio byte-opt
bytecomp byte-compile cconv eieio-core cl-macs gv cl-extra help-mode
easymenu grep compile comint ansi-color ring dired-aux cl-loaddefs pcase
cl-lib dired time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting xwidget-internal
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 110376 4867)
  (symbols 48 21765 0)
  (miscs 40 70 143)
  (strings 32 20598 4326)
  (string-bytes 1 649249)
  (vectors 16 14946)
  (vector-slots 8 464287 4193)
  (floats 8 225 154)
  (intervals 56 513 0)
  (buffers 976 14)
  (heap 1024 42366 1243))

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

[Drew Adams]

> dired-do-find-regexp ...
> 
> In former versions of Emacs (e.g. 24.5.1) this same recipe brought you
> to the first empty line in one of the marked files.

AFAICT, there is no dired-do-find-regexp in 24.5.1.
It was introduced later.

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

[Drew Adams]

> > dired-do-find-regexp ...
> >
> > In former versions of Emacs (e.g. 24.5.1) this same recipe brought you
> > to the first empty line in one of the marked files.
> 
> AFAICT, there is no dired-do-find-regexp in 24.5.1.
> It was introduced later.

Sorry, I see that you referred to the same recipe, which uses
`A', which was `dired-do-search'.  (And why was the command changed?)

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

[Dmitry Gutov]

On 05/02/2016 08:17 PM, Heinz Rommerskirchen wrote:

> dired-do-find-regexp can't find matches for a regexp containing newline.
> To trigger the bug:
> - start "emacs -Q"
> - open "/usr/local/share/emacs/25.0.93/etc/" in dired
> - mark the file NEWS and maybe a few more
> - type "A C-q C-j C-q C-j"
> - there is a message in the echo area: "No matches for:
>
> "
> In former versions of Emacs (e.g. 24.5.1) this same recipe brought you
> to the first empty line in one of the marked files.

I don't know if it's possible to search for "A^J^J" using find+grep, and 
it's the implementation choice for this function.

On the one hand, it limits the variety of the regexp you can use. On the 
other hand, you can get results faster, and you can search inside 
directories (dired-do-search only searches within regular files and 
silently skips any marked directories).

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

[Glenn Morris]

Dmitry Gutov wrote:

>> - type "A C-q C-j C-q C-j"
[...]
>> In former versions of Emacs (e.g. 24.5.1) this same recipe brought you
>> to the first empty line in one of the marked files.
>
> I don't know if it's possible to search for "A^J^J" using find+grep,
> and it's the implementation choice for this function.

(The fact that it uses grep should perhaps be documented, since it
affects what one can search for.)

For this specific example, a grep-ish way to find empty lines is '^$'.
However, using "A" to search for that (or the empty regexp) causes Emacs
to hang indefinitely. :(

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

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Mon, 02 May 2016 21:18:42 -0400
> Cc: 23426@debbugs.gnu.org, Heinz Rommerskirchen <heinz@h-rommerskirchen.de>
> 
> Dmitry Gutov wrote:
> 
> >> - type "A C-q C-j C-q C-j"
> [...]
> >> In former versions of Emacs (e.g. 24.5.1) this same recipe brought you
> >> to the first empty line in one of the marked files.
> >
> > I don't know if it's possible to search for "A^J^J" using find+grep,
> > and it's the implementation choice for this function.
> 
> (The fact that it uses grep should perhaps be documented, since it
> affects what one can search for.)

I added that to the doc string.  I'm much less inclined to state this
ion the manual, as this seems to be a subtle implementation detail,
and is probably subject to change.

> For this specific example, a grep-ish way to find empty lines is '^$'.
> However, using "A" to search for that (or the empty regexp) causes Emacs
> to hang indefinitely. :(

That's a bug that should be fixed, for sure.

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

[Dmitry Gutov]

Version: 25.1

On 05/03/2016 07:18 PM, Eli Zaretskii wrote:

>> (The fact that it uses grep should perhaps be documented, since it
>> affects what one can search for.)
>
> I added that to the doc string.  I'm much less inclined to state this
> ion the manual, as this seems to be a subtle implementation detail,
> and is probably subject to change.

Right, and it's not easy to describe, because for now we support only 
constructs that Grep understands but require the user to escape the 
terms the way Emacs requires, not Grep (so the result is somewhere 
between BRE and ERE).

Hopefully, we'll allow more Emacs-specific terms in the future (by 
stripping them out before giving the regexp to Grep, and then verifying 
the matches in Emacs with the correct regexp).

>> For this specific example, a grep-ish way to find empty lines is '^$'.
>> However, using "A" to search for that (or the empty regexp) causes Emacs
>> to hang indefinitely. :(
>
> That's a bug that should be fixed, for sure.

Fixed in 4d8fd9c. Closing.

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

[Dmitry Gutov]

On 05/03/2016 04:18 AM, Glenn Morris wrote:

> For this specific example, a grep-ish way to find empty lines is '^$'.

You can't search for an empty line following a letter 'A' this way, though.

> However, using "A" to search for that (or the empty regexp) causes Emacs
> to hang indefinitely. :(

Yup, it's a bug in xref--collect-matches-1 (you can re-search-forward 
indefinitely for such a regexp, and that's what it does). I'll try not 
to forget about it.

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

[Glenn Morris]

Dmitry Gutov wrote:

> On 05/03/2016 04:18 AM, Glenn Morris wrote:
>
>> For this specific example, a grep-ish way to find empty lines is '^$'.
>
> You can't search for an empty line following a letter 'A' this way, though.

No, but that's not what the OP's example was.
(The "A" is the keybinding that triggers the search, not part of the search.)

There is "grep -z" for multi-line searches, BTW, but it's a bit clunky.
Also "pcregrep".

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

[Dmitry Gutov]

On 05/03/2016 10:00 PM, Glenn Morris wrote:

>> You can't search for an empty line following a letter 'A' this way, though.
>
> No, but that's not what the OP's example was.
> (The "A" is the keybinding that triggers the search, not part of the search.)

Oh. So your example is a direct equivalent. Thanks.

> There is "grep -z" for multi-line searches, BTW, but it's a bit clunky.

I looked at 'grep -zo', but it doesn't seem suitable for our purpose: 
there's no way to make it output the correct line number. So we'd have 
to load each file in Emacs fully and search it them through ourselves a 
second time.

> Also "pcregrep".

It looks like a better choice, but it's not installed on most systems 
AFAICT (it wasn't on mine), and xref doesn't really know what to do with 
multiline matches anyway yet (?).

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

[Drew Adams]

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.)

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

[Dmitry Gutov]

On 05/04/2016 05:05 AM, Drew Adams wrote:
> 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.

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

[Drew Adams]

> > 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.

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.

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.

Should have just added this to an ELPA repository, as something
optional that users might want to try out.

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

[Eli Zaretskii]

> Date: Tue, 3 May 2016 21:24:22 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 23426@debbugs.gnu.org, Heinz Rommerskirchen <heinz@h-rommerskirchen.de>
> 
> > > 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.

> 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.

> 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.

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.

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

[Drew Adams]

> > > > 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?

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

[Dmitry Gutov]

On 05/04/2016 06:31 PM, Drew Adams wrote:

> 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, it's better to use that UI 
in other searches when it's feasible.

> 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.

>> 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.

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

[Drew Adams]

> > 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.

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

[Eli Zaretskii]

> Date: Wed, 4 May 2016 09:04:39 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 23426@debbugs.gnu.org
> 
> > > 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?

Because that's not how Emacs development moves forward.  And because
we don't have enough resources for that.

> > > 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.

Why would I (or anyone else, for that matter) work on Emacs for so
many years, if doing that wasn't deeply personal for us?

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

[Eli Zaretskii]

> Date: Wed, 4 May 2016 08:31:33 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: dgutov@yandex.ru, 23426@debbugs.gnu.org
> 
> > 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?

It is easier to get users complain about what they dislike than report
what 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?

See above.

> What's the hurry to replace?

Maintaining too many alternative UIs is a maintenance burden we cannot
afford.

> > 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.  It's all personal to begin with.

> I don't claim ill will - never have.

May I suggest that you ask someone impartial to read all your posts,
and provide feedback?  You might be surprised to learn how your
messages read.

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

See above.

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

[Drew Adams]

> Maintaining too many alternative UIs is a maintenance burden we cannot
> afford.

Even if you left the existing `A' and `Q' code dormant, there
would likely be little noticeable problem.  At least for a few
years, while letting users experiment with the new.

Seriously, how much change has been needed recently for the
existing `A' and `Q' code?  Code which you are anyway not
removing immediately.

The question I raised is only about the key bindings.

> > I don't claim ill will - never have.
> 
> May I suggest that you ask someone impartial to read all your posts,
> and provide feedback?  You might be surprised to learn how your
> messages read.

Ditto.  Can you show where I claimed ill will on anyone's part
in making this change?  I'm sure the intentions were good ones.
That doesn't mean that the result is the best of all worlds.

As I said earlier, if the key bindings had not been taken over,
I would likely have said nothing at all about this new feature.
Except possibly (once I've played with it) "thank you" for it.

It's a minor complaint: Please leave the existing key bindings.

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

The maintenance burden of the existing `A' and `Q' code?
You're not removing it immediately anyway.  Why the need to
take over those keys immediately?

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

[Eli Zaretskii]

> Date: Wed, 4 May 2016 09:32:45 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: dgutov@yandex.ru, 23426@debbugs.gnu.org
> 
> > Maintaining too many alternative UIs is a maintenance burden we cannot
> > afford.
> 
> Even if you left the existing `A' and `Q' code dormant, there
> would likely be little noticeable problem.  At least for a few
> years, while letting users experiment with the new.
> 
> Seriously, how much change has been needed recently for the
> existing `A' and `Q' code?  Code which you are anyway not
> removing immediately.

Asked and answered already.

> The question I raised is only about the key bindings.

We cannot move to a new UI without moving the key bindings, so your
suggestion is at best impractical.

> Can you show where I claimed ill will on anyone's part in making
> this change?

All over.

> I'm sure the intentions were good ones.

We all know what happens with good intentions.

> As I said earlier, if the key bindings had not been taken over,
> I would likely have said nothing at all about this new feature.

It's not _what_ you say, it's _how_ you say it.

> The maintenance burden of the existing `A' and `Q' code?

The maintenance burden of the tags-loop-continue UI.

> You're not removing it immediately anyway.  Why the need to
> take over those keys immediately?

As a first significant step towards removing it.

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

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

> > Drew

> > 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.)

That's a valid point.

@Dmitry So does emacs revert to the old function if grep/find is not found
on the system? What happens if the system doesn't have either of those two.

For example, on Windows, (executable-find "grep") returns nil and
(exectuable-find "find") returns path to the Windows' find.exe, not GNU
find.
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1035 bytes --]

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

[Dmitry Gutov]

On 05/04/2016 08:00 AM, Kaushal Modi wrote:

> @Dmitry So does emacs revert to the old function if grep/find is not
> found on the system?

Not currently, no.

> What happens if the system doesn't have either of
> those two.

You go to https://sourceforge.net/projects/ezwinports/files/, and 
install them. Or avoid using the new features (which aren't limited to 
the commands bound to A and Q in Dired).

Or submit a patch that adds a fallback to xref-collect-matches to open 
all files and parse them in Emacs. I think we'd accept it.

But installing grep and find will work better anyway.

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

[Drew Adams]

> go to https://sourceforge.net/projects/ezwinports/files/, and
> install them. Or avoid using the new features (which aren't limited to
> the commands bound to A and Q in Dired).

Users should not need to "avoid" using the default settings.

The "new" is clearly not a sufficient replacement for the "old".
It should have been (should be) added only as an opt-in option,
not imposed as replacement.

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

[Dmitry Gutov]

On 05/04/2016 04:32 PM, Drew Adams wrote:

> Users should not need to "avoid" using the default settings.

Yes, they should install 'grep' and 'find'. Luckily, these programs are 
already available on the systems we care about most. And they're not so 
hard to install on the others.

> The "new" is clearly not a sufficient replacement for the "old".
> It should have been (should be) added only as an opt-in option,
> not imposed as replacement.

It's a tradeoff.

We, frankly, don't have the technical capability (code quality WRT 
extensibility and manpower) to never remove features while continuing to 
move forward.

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

[Drew Adams]

> > Users should not need to "avoid" using the default settings.
> 
> Yes, they should install 'grep' and 'find'.

Why "should" they?  Shouldn't users decide what users should do?

> > The "new" is clearly not a sufficient replacement for the "old".
> > It should have been (should be) added only as an opt-in option,
> > not imposed as replacement.
> 
> It's a tradeoff.

Let users discover the feature and choose the tradeoff they prefer.
Give Emacs Dev and users time to come to a more informed judgment.
That's been the approach for decades, and it's a wise one.  What's
the hurry to replace?

> We, frankly, don't have the technical capability (code quality WRT
> extensibility and manpower) to never remove features while continuing to
> move forward.

Sounds like a BS imperative, to me.  As if this new feature
were a must-have, and replacing the existing feature(s) were
a must-do-immediately (e.g. a security hole).

Better: "move forward" separately, with a library/feature that
people can choose to adopt.  If it's a better mousetrap then
users will choose it - no problem.  If you are confident in the
new feature, that's the way to show it.

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

[Eli Zaretskii]

> Date: Wed, 4 May 2016 08:31:30 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 23426@debbugs.gnu.org
> 
> Sounds like a BS imperative, to me.

If you are still looking for proof of hostility in your messages,
here's one.

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

[Eli Zaretskii]

> Date: Wed, 4 May 2016 06:32:20 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 23426@debbugs.gnu.org, heinz@h-rommerskirchen.de
> 
> The "new" is clearly not a sufficient replacement for the "old".
> It should have been (should be) added only as an opt-in option,
> not imposed as replacement.

We obviously disagree.  And that ship has sailed long ago, btw.  You
were here all that time, so I don't understand why you raise this only
now.

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 4 May 2016 13:32:41 +0300
> Cc: 23426@debbugs.gnu.org, heinz@h-rommerskirchen.de
> 
> Or submit a patch that adds a fallback to xref-collect-matches to open 
> all files and parse them in Emacs. I think we'd accept it.

Indeed, patches to that effect are welcome.

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

[Drew Adams]

> > The "new" is clearly not a sufficient replacement for the "old".
> > It should have been (should be) added only as an opt-in option,
> > not imposed as replacement.
> 
> We obviously disagree.

How can the new be considered a sufficient replacement, if it
means that `A' and `Q' no longer work for users without `grep'
or `find'?

> And that ship has sailed long ago, btw.

When did it sail?  This change is not present in any Emacs release
AFAIK.

> You were here all that time, so I don't understand why you raise
> this only now.

Dunno what you mean by "here".  This is the first I've learned of
this feature and the fact that it requires users to install `grep'
and `find' commands to use `A' and `Q' in Dired.

Had you simply _added_ this feature and not usurped the existing
bindings, you would likely have heard nothing from me about this.
I have no objection to the _addition_ of another way to search
and replace in Dired.

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

[Dmitry Gutov]

On 05/04/2016 06:39 PM, Drew Adams wrote:

> Had you simply _added_ this feature and not usurped the existing
> bindings, you would likely have heard nothing from me about this.
> I have no objection to the _addition_ of another way to search
> and replace in Dired.

That's very generous of you.

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

[Drew Adams]

> > Had you simply _added_ this feature and not usurped the existing
> > bindings, you would likely have heard nothing from me about this.
> > I have no objection to the _addition_ of another way to search
> > and replace in Dired.
> 
> That's very generous of you.

I don't understand the hostility/sarcasm.

I'm trying to be clear that I _welcome_ your feature,
based on the description.  It sounds like something useful.

I just don't think it's great that you feel you should
immediately replace other, existing ways to search,
including grabbing their key bindings.

It's a minor complaint: Keep the new feature, but please
don't tread on existing keys and their features.  Not
without a good reason, at least.  Is that too much to ask?

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

[Eli Zaretskii]

> Date: Wed, 4 May 2016 09:10:24 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 23426@debbugs.gnu.org, heinz@h-rommerskirchen.de, kaushal.modi@gmail.com
> 
> I'm trying to be clear that I _welcome_ your feature,
> based on the description.  It sounds like something useful.
> 
> I just don't think it's great that you feel you should
> immediately replace other, existing ways to search,
> including grabbing their key bindings.

Maybe you should actually try it before talking about it.

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

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

Hi all,

Even understanding that users would need to install GNU find & grep on
their Windows system to use the new implementations bound to A/Q in dired,
I believe that we should have the following:

- NOT bind A/Q at all if the right dependencies are not found. I tried the
A binding on Windows, it looked like it was grepping for the strings I
entered and returned an empty *xref* window. The same search on same files
worked as expected in RHEL (to be honest I love this new feature on RHEL,
and I might start using the A binding). Currently the implementation on
Windows gives an appearance that something was searched for and no results
were found. That is misleading!

- Another alternative would be (if we want to keep A/Q bindings) that a
user-error or error be thrown if the correct external dependencies are not
installed. The user should be let known that they need to install the GNU
find/grep executables for their platform in order to use those commands. In
the current implementation, the user will just assume that they searched
something and nothing got returned.

- The requirement to have find/grep installed should also go to backward
incompatible changes section in NEWS.

WDYT?
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1413 bytes --]

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

[Dmitry Gutov]

On 05/04/2016 07:20 PM, Kaushal Modi wrote:

> - Another alternative would be (if we want to keep A/Q bindings) that a
> user-error or error be thrown if the correct external dependencies are
> not installed. The user should be let known that they need to install
> the GNU find/grep executables for their platform in order to use those
> commands. In the current implementation, the user will just assume that
> they searched something and nothing got returned.

Please file a separate bug about that.

> - The requirement to have find/grep installed should also go to backward
> incompatible changes section in NEWS.

Not sure. I think we only have an "incompatible changes in Lisp" section.

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

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Wed, 04 May 2016 16:20:25 +0000
> Cc: 23426@debbugs.gnu.org, heinz@h-rommerskirchen.de
> 
> - NOT bind A/Q at all if the right dependencies are not found.

That's not possible.  To find the dependencies, we need a trigger,
which is the command itself.  So it must be bound.

> - Another alternative would be (if we want to keep A/Q bindings) that a user-error or error be thrown if the
> correct external dependencies are not installed. The user should be let known that they need to install the GNU
> find/grep executables for their platform in order to use those commands. In the current implementation, the
> user will just assume that they searched something and nothing got returned.

Detecting the situation and signaling an error is probably a good
thing.  But I'm not sure it isn't too late for such changes, unless we
want to delay the release.

> - The requirement to have find/grep installed should also go to backward incompatible changes section in
> NEWS.

As Dmitry points out, there is no such section.

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

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]

OK, I have filed a new bug report for this request:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23451


> That's not possible.  To find the dependencies, we need a trigger,
> which is the command itself.  So it must be bound.
>

I meant that the A/Q keys be left unbound if dependencies are not found.


> Detecting the situation and signaling an error is probably a good
> thing.  But I'm not sure it isn't too late for such changes, unless we
> want to delay the release.
>

The current state keeps the Windows user believing that the A/Q action did
not find anything, without giving them a hint that they don't have
find/grep installed (which would be the case most of the time). If we want
the Windows users to use the new implementation, they at least should know
that they are missing the executables and that they need to install them
manually. IMO this counts like a blocking bug.


> > - The requirement to have find/grep installed should also go to backward
> incompatible changes section in
> > NEWS.
>
> As Dmitry points out, there is no such section.
>

Sorry, I got the impression that such section existed based on this recent
commit:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25&id=c68a09107c1f7459c626d38be5e0e991912e57ec
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2103 bytes --]

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

[Dmitry Gutov]

On 05/04/2016 07:10 PM, Drew Adams wrote:
>>> Had you simply _added_ this feature and not usurped the existing
>>> bindings, you would likely have heard nothing from me about this.
>>> I have no objection to the _addition_ of another way to search
>>> and replace in Dired.
>>
>> That's very generous of you.
>
> I don't understand the hostility/sarcasm.

It is sarcasm. Designed to point out that your paragraph above is an 
empty statement.

Of course if a change has no bearing on any user's workflow except on 
those who choose to opt in, there is literally nothing for you to 
complain about. But there are fewer things to be happy about as well.

> It's a minor complaint: Keep the new feature, but please
> don't tread on existing keys and their features.  Not
> without a good reason, at least.  Is that too much to ask?

It is.

And if the complaint is minor, maybe spend less time arguing about it 
next time?

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

[Eli Zaretskii]

> Date: Wed, 4 May 2016 08:39:42 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: dgutov@yandex.ru, kaushal.modi@gmail.com, 23426@debbugs.gnu.org,
>         heinz@h-rommerskirchen.de
> 
> > > The "new" is clearly not a sufficient replacement for the "old".
> > > It should have been (should be) added only as an opt-in option,
> > > not imposed as replacement.
> > 
> > We obviously disagree.
> 
> How can the new be considered a sufficient replacement, if it
> means that `A' and `Q' no longer work for users without `grep'
> or `find'?

We obviously don't consider that such a serious obstacle, and the
commands are not popular enough for that to be an issue.

> > And that ship has sailed long ago, btw.
> 
> When did it sail?

When it was decided to replace tags-* commands with xref-* commands,
about a year ago, I'd say, maybe more.

> This change is not present in any Emacs release AFAIK.

I don't see how this fact is relevant.  The discussions were held here
and on emacs-devel, with you and others reading it.

> > You were here all that time, so I don't understand why you raise
> > this only now.
> 
> Dunno what you mean by "here".

Here on this mailing list.

> This is the first I've learned of this feature and the fact that it
> requires users to install `grep' and `find' commands to use `A' and
> `Q' in Dired.

May I suggest to pay more attention to on-going discussions in the
future?

> Had you simply _added_ this feature and not usurped the existing
> bindings, you would likely have heard nothing from me about this.

These commands were introduced with the explicit intent to replace the
old ones as 'A' and 'Q' bindings, so that tags-loop-continue would not
be needed anymore.  Again, the discussions about that were all held
here, for quite a few moons.