bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Lars Ingebrigtsen]

`g' works fine for redoing, but it would be great if you could return to
the previous (and next) with the normal `r'/`n' commands.



In GNU Emacs 25.1.50.49 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.7)
 of 2016-02-11 built on mouse
Repository revision: e91b75de10881c1bb8b0f4cc14f35c68563dc356
Windowing system distributor 'The X.Org Foundation', version 11.0.11702000
System Description:	Ubuntu 15.10

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

Important settings:
  value of $LC_MONETARY: nb_NO.UTF-8
  value of $LC_NUMERIC: nb_NO.UTF-8
  value of $LC_TIME: nb_NO.UTF-8
  value of $LANG: C
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Grep

Minor modes in effect:
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-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

Recent messages:
Saving file /home/larsi/src/emacs/trunk/lisp/gnus/gnus-win.el...
Wrote /home/larsi/src/emacs/trunk/lisp/gnus/gnus-win.el
Saving file /home/larsi/src/emacs/trunk/ChangeLog...
Wrote /home/larsi/src/emacs/trunk/ChangeLog
Mark set
Grep finished (matches found)
user-error: Moved past last grep hit
l is undefined
Grep finished (matches found) [2 times]
Making completion list...

Load-path shadows:
~/src/emacs/elpa/packages/debbugs/debbugs-org hides /home/larsi/.emacs.d/elpa/debbugs-0.7/debbugs-org
~/src/emacs/elpa/packages/debbugs/debbugs-browse hides /home/larsi/.emacs.d/elpa/debbugs-0.7/debbugs-browse
~/src/emacs/elpa/packages/debbugs/debbugs-gnu hides /home/larsi/.emacs.d/elpa/debbugs-0.7/debbugs-gnu
~/src/emacs/elpa/packages/debbugs/debbugs hides /home/larsi/.emacs.d/elpa/debbugs-0.7/debbugs

Features:
(shadow ecomplete emacsbug sendmail whitespace eieio-opt speedbar
sb-image ezimage dframe find-func shell pcomplete grep compile comint
bug-reference log-edit ring pcvs-util vc-bzr vc-src vc-sccs vc-svn
vc-cvs vc-rcs vc-dir ewoc url-queue url-cache mm-archive sort smiley
ansi-color gnus-cite gnus-async gnus-dup qp copyright misearch
multi-isearch vc vc-dispatcher vc-git diff-mode map gnus-ml gmane
spam-gmane dns mm-url disp-table gnus-fun gnus-mdrtn nndraft nnmh utf-7
gnus-topic nnfolder network-stream nsm starttls nnir spam-report spam
spam-stat gnus-uu yenc gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig
nntp gnus-cache gnus-sum gnus-group gnus-undo gnus-start gnus-cloud
nnimap nnmail mail-source utf7 netrc nnoo parse-time gnus-spec gnus-int
gnus-range message format-spec rfc822 mml mml-sec epg mailabbrev
gmm-utils mailheader gnus-win gnus nnheader wid-edit movie mkv shr
browse-url imdb dom pvr debug debbugs-gnu easy-mmode derived subr-x
debbugs soap-client mm-decode mm-bodies mm-encode url-http tls gnutls
url-auth mail-parse rfc2231 url-gw puny url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
mailcap warnings rng-xsd rng-dt rng-util xsd-regexp xml ido seq flyspell
ispell dired dired-loaddefs add-log mail-extr jka-compr cl finder-inf
info package epg-config url-handlers url-parse auth-source cl-seq eieio
byte-opt bytecomp byte-compile cl-extra cconv eieio-core cl-macs gv
eieio-loaddefs gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums
mail-utils mm-util help-fns help-mode easymenu cl-loaddefs pcase cl-lib
mail-prsvr password-cache url-vars 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 obarray 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 move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 490407 86814)
 (symbols 48 123667 0)
 (miscs 40 417 1644)
 (strings 32 148615 10322)
 (string-bytes 1 5453824)
 (vectors 16 40139)
 (vector-slots 8 1598663 196673)
 (floats 8 569 807)
 (intervals 56 9600 1909)
 (buffers 976 59)
 (heap 1024 220484 33881))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 11 Feb 2016 16:52:14 +1100
> 
> `g' works fine for redoing, but it would be great if you could return to
> the previous (and next) with the normal `r'/`n' commands.

We could have an optional feature whereby the Grep buffer is named
something like "*grep-the-command-line-used*".  Then as long as the
next Grep command is different, you will have a new buffer for its
output, and Bob's your uncle.

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Thu, 11 Feb 2016 16:52:14 +1100
>> 
>> `g' works fine for redoing, but it would be great if you could return to
>> the previous (and next) with the normal `r'/`n' commands.
>
> We could have an optional feature whereby the Grep buffer is named
> something like "*grep-the-command-line-used*".  Then as long as the
> next Grep command is different, you will have a new buffer for its
> output, and Bob's your uncle.

Having multiple grep buffers would also be a nice feature, but I think
just making the `r'/`l' commands work the way they do in, say, *Help*
and eww buffers would be sufficient for most needs.  We'd just need a
history variable that containts, uhm, the command and the directory we
were in when we executed that command...

I think I'll just implement that now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: 22627@debbugs.gnu.org
> Date: Sun, 03 Apr 2016 19:12:56 +0200
> 
> > We could have an optional feature whereby the Grep buffer is named
> > something like "*grep-the-command-line-used*".  Then as long as the
> > next Grep command is different, you will have a new buffer for its
> > output, and Bob's your uncle.
> 
> Having multiple grep buffers would also be a nice feature, but I think
> just making the `r'/`l' commands work the way they do in, say, *Help*
> and eww buffers would be sufficient for most needs.  We'd just need a
> history variable that containts, uhm, the command and the directory we
> were in when we executed that command...

Unlike Web pages, Grep searches are not connected by any links, so
traversing the history one buffer at a time will be frustrating and
unnatural, when there are a lot of them.  By contrast, naming them
uniquely will allow switching to the right one immediately.

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Unlike Web pages, Grep searches are not connected by any links, so
> traversing the history one buffer at a time will be frustrating and
> unnatural, when there are a lot of them.  By contrast, naming them
> uniquely will allow switching to the right one immediately.

That's true, so having an additional feature for multiple-buffer grep
commands would also be nice, but it's an orthogonal issue.  My common
use case is that I grep for "featurep 'xemacs", and then I grep for a
different function, and when I'm finished with that, I just want to
return to my previous search.  The `r'/`l' commands fit that perfectly.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Lars Magne Ingebrigtsen]

This has now been implemented on the trunk.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[John Wiegley]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> This has now been implemented on the trunk.  

Thank you, Lars!

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

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: 22627@debbugs.gnu.org
> Date: Sun, 03 Apr 2016 19:47:51 +0200
> 
> This has now been implemented on the trunk.  

I'm frustrated by your rushing to implement something that is still
under discussion.  FWIW, I'm not sure we want to maintain such a
feature.

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm frustrated by your rushing to implement something that is still
> under discussion.  FWIW, I'm not sure we want to maintain such a
> feature.

Well, I think all these modes (*Help*, grep, eww) should have the
`g'/`r'/`l' command set, where feasible.  They feel very natural.

Having multiple *Help*, grep and eww buffers is also nice.  Different
work flows for different people.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: 22627@debbugs.gnu.org
> Date: Sun, 03 Apr 2016 20:26:05 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm frustrated by your rushing to implement something that is still
> > under discussion.  FWIW, I'm not sure we want to maintain such a
> > feature.
> 
> Well, I think all these modes (*Help*, grep, eww) should have the
> `g'/`r'/`l' command set, where feasible.  They feel very natural.
> 
> Having multiple *Help*, grep and eww buffers is also nice.  Different
> work flows for different people.

That entirely misses the point, and you know it.

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[John Wiegley]

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

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

>> This has now been implemented on the trunk.  

> I'm frustrated by your rushing to implement something that is still under
> discussion. FWIW, I'm not sure we want to maintain such a feature.

I didn't realize you were not yet satisfied with the design of this feature,
Eli.

Lars, I have reverted both commits related to this feature, until we arrive at
a design that has a bit more consensus.

For the record, I never have more than one grep buffer open, but not because I
haven't wanted that in the past! I just never think to save the old one before
running grep again.

-- 
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#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Drew Adams]

> For the record, I never have more than one grep buffer open, but not because
> I haven't wanted that in the past! I just never think to save the old one
> before running grep again.

FWIW, I have a simple key that prompts for a new name for the buffer.
I use it all the time, for *Help*, *grep*, *Pp Eval Output*, etc.

On the other hand, I also reuse the same *grep* buffer for different
searches, and rerun a previous search (in the same dir or not) by
retrieving its args from the history list.  I don't understand what
the missing feature is that is being discussed.  Why is it hard to
rerun a previous `grep' command?

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Drew Adams]

> > Unlike Web pages, Grep searches are not connected by any links, so
> > traversing the history one buffer at a time will be frustrating and
> > unnatural, when there are a lot of them.  By contrast, naming them
> > uniquely will allow switching to the right one immediately.
> 
> That's true, so having an additional feature for multiple-buffer grep
> commands would also be nice, but it's an orthogonal issue.  My common
> use case is that I grep for "featurep 'xemacs", and then I grep for a
> different function, and when I'm finished with that, I just want to
> return to my previous search.  The `r'/`l' commands fit that perfectly.

What's wrong with hitting the up arrow or `C-p' to retrieve
previous `grep' command input?  If you want an earlier one
and don't want to cycle to it, use `M-r'.  As usual.

You can also use `C-x ESC ESC' to repeat previous commands,
editing the command as needed.  As usual.

Nothing new here.  I don't see what wishlist feature you're
looking for.  Command `grep' already has a minibuffer history.
And `M-x' already has a command history.  What's the problem?

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: 22627@debbugs.gnu.org
> Date: Sun, 03 Apr 2016 19:41:32 +0200
> 
> My common use case is that I grep for "featurep 'xemacs", and then I
> grep for a different function, and when I'm finished with that, I
> just want to return to my previous search.  The `r'/`l' commands fit
> that perfectly.

Is it reasonable to assume that an average Emacs session will have
only a couple of Grep buffers?  Or that the user will only care about
the last 2 or 3 of them?  I think it isn't reasonable, in which case
your use case doesn't scale well enough to the needs of others.  By
contrast, having a distinct name will cater both to your use case and
to that of others, where dozens of Grep buffers could exist in the
same session.

Besides, the 'gid' command, which is part of ID-Utils, and runs the
'lid' command, already behaves like I described, so we at least have a
precedent here.

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Is it reasonable to assume that an average Emacs session will have
> only a couple of Grep buffers?  Or that the user will only care about
> the last 2 or 3 of them?  I think it isn't reasonable, in which case
> your use case doesn't scale well enough to the needs of others.

I've never had more than one grep buffer, and since that's the default,
I assume that that's quite normal.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Drew Adams]

> > Is it reasonable to assume that an average Emacs session will have
> > only a couple of Grep buffers?  Or that the user will only care about
> > the last 2 or 3 of them?  I think it isn't reasonable, in which case
> > your use case doesn't scale well enough to the needs of others.
> 
> I've never had more than one grep buffer, and since that's the default,
> I assume that that's quite normal.

So the only "normal" possibilities for Emacs users are:
(a) whatever is the default and (b) whatever Lars uses?

FWIW, I often have more than one grep buffer open.
But I guess that's not "normal".

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Óscar Fuentes]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Lars Ingebrigtsen <larsi@gnus.org>
>>> Date: Thu, 11 Feb 2016 16:52:14 +1100
>>> 
>>> `g' works fine for redoing, but it would be great if you could return to
>>> the previous (and next) with the normal `r'/`n' commands.
>>
>> We could have an optional feature whereby the Grep buffer is named
>> something like "*grep-the-command-line-used*".  Then as long as the
>> next Grep command is different, you will have a new buffer for its
>> output, and Bob's your uncle.

That's what ag.el (which drives the `ag' search command) does. For
instance:

*ag search text:foo dir:/home/oscar/bar*

which makes convenient locating an ag buffer by searched text and/or
directory. It tends to create large buffer names which don't play well
with tools that have a limited sprace for buffer names (ibuffer) but
otherwise it is useful.

> Having multiple grep buffers would also be a nice feature,

I do that with compilation-buffer-name-function.

[snip]

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Juri Linkov]

> `g' works fine for redoing, but it would be great if you could return to
> the previous (and next) with the normal `r'/`n' commands.

We can have either a history of grep command lines or a history of
grep outputs (kinda works already by using ‘undo’ in the grep buffer).

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Charles A. Roelli]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 11 Feb 2016 16:52:14 +1100
> 
> `g' works fine for redoing, but it would be great if you could return to
> the previous (and next) with the normal `r'/`n' commands.
> 
> 
> 
> In GNU Emacs 25.1.50.49 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.7)
>  of 2016-02-11 built on mouse
> Repository revision: e91b75de10881c1bb8b0f4cc14f35c68563dc356
> Windowing system distributor 'The X.Org Foundation', version 11.0.11702000
> System Description:	Ubuntu 15.10

This bug is marked as fixed in 26.1, but I don't think the feature was
ever added.  Maybe it would still be interesting to design a set of
generic history commands/bindings for use in grep/occur/compilation
buffers?

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Lars Ingebrigtsen]

charles@aurox.ch (Charles A. Roelli) writes:

> This bug is marked as fixed in 26.1, but I don't think the feature was
> ever added.  Maybe it would still be interesting to design a set of
> generic history commands/bindings for use in grep/occur/compilation
> buffers?

It was added and then reverted because the maintainers didn't like it or
something.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Charles A. Roelli]

reopen 22627
quit

> It was added and then reverted because the maintainers didn't like it or
> something.

Thanks.  Maybe we could build on your patch to make it work across all
the grep/occur/compilation-related modes?  I don't think anyone had
objections to that.

(reopening the bug)

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Drew Adams]

> > `g' works fine for redoing, but it would be great if you could return to
> > the previous (and next) with the normal `r'/`n' commands.
> 
> We could have an optional feature whereby the Grep buffer is named
> something like "*grep-the-command-line-used*".  Then as long as the
> next Grep command is different, you will have a new buffer for its
> output, and Bob's your uncle.

FWIW, in my `grep+.el':

 . You can automatically rename the current grep buffer to reflect the args
   using (add-hook 'grep-mode-hook 'grepp-rename-buffer-to-last-no-confirm)

 . You can rename it thus on demand using `r'.

 . `+' renames current grep buffer uniquely (without the args) and switches
   to buffer `*grep*'

 . `b' reads a grep buffer name and switches to that buffer.  A grep buffer
   here is any buffer whose name matches `'\\*grep\\*', which includes those
   whose names include the arguments.

You might want to do something similar for grep.el.

https://www.emacswiki.org/emacs/download/grep%2b.el

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

   > . You can automatically rename the current grep buffer to reflect the args
   >   using (add-hook 'grep-mode-hook 'grepp-rename-buffer-to-last-no-confirm)

   > . You can rename it thus on demand using `r'.

   > . `+' renames current grep buffer uniquely (without the args) and switches
   >   to buffer `*grep*'

   > . `b' reads a grep buffer name and switches to that buffer.  A grep buffer
   >   here is any buffer whose name matches `'\\*grep\\*', which includes those
   >   whose names include the arguments.

It would be nice to put buttons at the start of the buffer
to do some of these things.  That way, users would not need
to remember commands for them.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#22627: 25.1.50; Wishlist: It would be nice if the grep buffer had a history

[Drew Adams]

>> . You can automatically rename the current grep buffer to reflect
>>   the args using
>>   (add-hook 'grep-mode-hook 'grepp-rename-buffer-to-last-no-confirm)
>>
>> . You can rename it thus on demand using `r'.
>>
>> . `+' renames current grep buffer uniquely (without the args) and
>>   switches to buffer `*grep*'
>>
>> . `b' reads a grep buffer name and switches to that buffer.  A grep
>>   buffer here is any buffer whose name matches `'\\*grep\\*', which
>>   includes those whose names include the arguments.
> 
> It would be nice to put buttons at the start of the buffer
> to do some of these things.  That way, users would not need
> to remember commands for them.

Maybe.  But there is something to be said for keeping the buffer
content as just `grep' output.  In `grep+.el' I've added the commands
to the menu-bar `Grep' menu instead.  (And there is `C-h m', which
mentions the keys in my version of `grep'.)

https://www.emacswiki.org/emacs/download/grep%2b.el