GNU bug report logs -
#380
previous-matching-history-element beef up
Previous Next
Reported by: jidanni <at> jidanni.org
Date: Mon, 9 Jun 2008 18:15:03 UTC
Severity: wishlist
Tags: fixed
Fixed in version 27.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
Let's examine today the docstring for
M-r (translated from <escape> r) runs the command previous-matching-history-element
which is an interactive compiled Lisp function in `simple.el'.
It is bound to M-r.
(previous-matching-history-element REGEXP N)
Find the previous history element that matches REGEXP.
(Previous history elements refer to earlier actions.)
With prefix argument N, search for Nth previous match.
If N is negative, find the next or Nth next match.
Normally, history elements are matched case-insensitively if
`case-fold-search' is non-nil, but an uppercase letter in REGEXP
makes the search case-sensitive.
See also `minibuffer-history-case-insensitive-variables'.
OK, but what about when you want to search further back again: mention that you
just hit a second M-r RET...
And when one does hit that second M-r, it would be nice if the prompt
would show what the current default search string is. All it ever says is
"Previous element matching (regexp): " though indeed it remembers a
default all the time at least after first use.
Indeed it might even also say "found on history item 432" or "found at
18% of history" upon finding something, but maybe that's too verbose.
Also some of us would like C-r to "bust through" into previous lines,
so we don't have to use the less familiar M-r (ESC r for us old dogs
who never learned new ALT tricks). Maybe make a variable to allow
that.
All the above also applies to M-s.
This bug report was last modified 5 years and 279 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.