GNU bug report logs -
#29321
Isearch hit count
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29321 in the body.
You can then email your comments to 29321 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Thu, 16 Nov 2017 19:28:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
charles <at> aurox.ch (Charles A. Roelli):
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 16 Nov 2017 19:28:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Isearch could show in the mode line how many matches follow or precede
the currently highlighted one (or we could write "3 of 4 matches", as,
e.g., Firefox does). For big files, it could be helpful to calculate
this information either lazily or in another thread.
If we had this, it would also be convenient to say "go forward n
matches", so that typing "M-3 C-s" during a search would be the
equivalent of typing C-s three times. To do this we could add numeric
prefix arg handling to C-s/C-r/C-M-s/C-M-r, if that isn't already
taken for some other behavior.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Thu, 16 Nov 2017 22:26:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> Isearch could show in the mode line how many matches follow or precede
> the currently highlighted one (or we could write "3 of 4 matches", as,
> e.g., Firefox does). For big files, it could be helpful to calculate
> this information either lazily or in another thread.
>
> If we had this, it would also be convenient to say "go forward n
> matches", so that typing "M-3 C-s" during a search would be the
> equivalent of typing C-s three times. To do this we could add numeric
> prefix arg handling to C-s/C-r/C-M-s/C-M-r, if that isn't already
> taken for some other behavior.
I don't think Isearch determines all of the hits at once (even
in just the current search direction and starting from point).
Instead, it searches only on demand, *incrementally*, as the
name suggests.
The most it does that is similar to what you request, I think,
is to do some unlazy "lazy" highlighting of hits (before and
after point) that are currently visible (but see option
`lazy-highlight-max-at-a-time'). It's UNlazy because it
eagerly highlights search hits that you may never visit.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 19 Nov 2017 17:12:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 16 Nov 2017 14:25:29 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
>
> I don't think Isearch determines all of the hits at once (even
> in just the current search direction and starting from point).
> Instead, it searches only on demand, *incrementally*, as the
> name suggests.
Right, and that behavior is useful when doing an Isearch in, for
example, shell buffers, where new matches for a search string might
enter the buffer after the search begins, or in large buffers, where
finding each match would be prohibitive. But in most other cases,
giving some contextual information as to how many search matches are
after or before point would be a cheap operation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 19 Nov 2017 19:08:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> > I don't think Isearch determines all of the hits at once (even
> > in just the current search direction and starting from point).
> > Instead, it searches only on demand, *incrementally*, as the
> > name suggests.
>
> Right, and that behavior is useful when doing an Isearch in, for
> example, shell buffers, where new matches for a search string might
> enter the buffer after the search begins, or in large buffers, where
> finding each match would be prohibitive. But in most other cases,
> giving some contextual information as to how many search matches are
> after or before point would be a cheap operation.
My point was that Isearc, so far, is designed for search
only within the visible part of the buffer. All of the
possible hits in the search space are not found; hits
are found only within the visible part of the buffer
(and that is only by lazy-highlighting).
That doesn't mean that a different search approach couldn't
be used, e.g., for a different search command.
And it doesn't even mean that a different approach couldn't
be integrated with Isearch, e.g., by a user option or a
toggle key that switches to a find-all-search-hits approach.
However, depending on the context - in particular the size
of the search space (e.g. buffer) but also on the kind
(difficulty) of searching (e.g. char-fold, with symmetric
matches), such an approach would not necessarily always be
cheap.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Mon, 20 Nov 2017 19:25:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 19 Nov 2017 11:06:39 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
>
> > > I don't think Isearch determines all of the hits at once (even
> > > in just the current search direction and starting from point).
> > > Instead, it searches only on demand, *incrementally*, as the
> > > name suggests.
> >
> > Right, and that behavior is useful when doing an Isearch in, for
> > example, shell buffers, where new matches for a search string might
> > enter the buffer after the search begins, or in large buffers, where
> > finding each match would be prohibitive. But in most other cases,
> > giving some contextual information as to how many search matches are
> > after or before point would be a cheap operation.
>
> My point was that Isearc, so far, is designed for search
> only within the visible part of the buffer. All of the
> possible hits in the search space are not found; hits
> are found only within the visible part of the buffer
> (and that is only by lazy-highlighting).
>
> That doesn't mean that a different search approach couldn't
> be used, e.g., for a different search command.
>
> And it doesn't even mean that a different approach couldn't
> be integrated with Isearch, e.g., by a user option or a
> toggle key that switches to a find-all-search-hits approach.
Sure, an interactive toggle and a corresponding defvar/defcustom to
control the default behavior would be a good fit.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sat, 27 Oct 2018 20:58:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 29321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Isearch could show in the mode line how many matches follow or precede
> the currently highlighted one (or we could write "3 of 4 matches", as,
> e.g., Firefox does). For big files, it could be helpful to calculate
> this information either lazily or in another thread.
Thanks to Drew, now we have the full-buffer lazy-highlighting
loop that can be reused for Isearch hit count.
Here is a minimal patch that implements this feature:
[isearch-lazy-count.1.diff (text/x-diff, inline)]
diff --git a/lisp/isearch.el b/lisp/isearch.el
index 580b3ac40a..8c264ab3ed 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -316,6 +316,13 @@ isearch-lazy-highlight
:group 'lazy-highlight
:group 'isearch)
+(defcustom isearch-lazy-count nil
+ "Counts matches in the full buffer.
+When non-nil, all matches in the full buffer are counted."
+ :type 'boolean
+ :group 'isearch
+ :version "27.1")
+
;;; Lazy highlight customization.
(defgroup lazy-highlight nil
@@ -2794,7 +2801,15 @@ isearch-message-prefix
(concat " [" current-input-method-title "]: "))
": ")
)))
- (propertize (concat (upcase (substring m 0 1)) (substring m 1))
+ (propertize (concat (if (and isearch-lazy-count isearch-lazy-count-current)
+ (format "%d/%d " (if isearch-forward
+ isearch-lazy-count-current
+ (- isearch-lazy-count-total
+ isearch-lazy-count-current
+ -1))
+ (or isearch-lazy-count-total "?"))
+ "")
+ (upcase (substring m 0 1)) (substring m 1))
'face 'minibuffer-prompt)))
(defun isearch-message-suffix (&optional c-q-hack)
@@ -3212,6 +3227,10 @@ 'isearch-lazy-highlight-word
(defvar isearch-lazy-highlight-regexp-function nil)
(defvar isearch-lazy-highlight-forward nil)
(defvar isearch-lazy-highlight-error nil)
+(defvar isearch-lazy-count-current nil)
+(defvar isearch-lazy-count-total nil)
+(defvar isearch-lazy-count-start nil)
+(defvar isearch-lazy-count-hash (make-hash-table))
(defun lazy-highlight-cleanup (&optional force procrastinate)
"Stop lazy highlighting and remove extra highlighting from current buffer.
@@ -3235,8 +3254,7 @@ isearch-lazy-highlight-new-loop
This is called when `isearch-update' is invoked (which can cause the
search string to change or the window to scroll). It is also used
by other Emacs features."
- (when (and (null executing-kbd-macro)
- (sit-for 0) ;make sure (window-start) is credible
+ (setq isearch-lazy-count-start
(or (not (equal isearch-string
isearch-lazy-highlight-last-string))
(not (memq (selected-window)
@@ -3251,17 +3269,20 @@ isearch-lazy-highlight-new-loop
isearch-lax-whitespace))
(not (eq isearch-lazy-highlight-regexp-lax-whitespace
isearch-regexp-lax-whitespace))
- (not (or lazy-highlight-buffer
- (= (window-group-start)
- isearch-lazy-highlight-window-start)))
- (not (or lazy-highlight-buffer
- (= (window-group-end) ; Window may have been split/joined.
- isearch-lazy-highlight-window-end)))
(not (eq isearch-forward
isearch-lazy-highlight-forward))
;; In case we are recovering from an error.
(not (equal isearch-error
isearch-lazy-highlight-error))))
+ (when (and (null executing-kbd-macro)
+ (sit-for 0) ;make sure (window-start) is credible
+ (or isearch-lazy-count-start
+ (not (or lazy-highlight-buffer
+ (= (window-group-start)
+ isearch-lazy-highlight-window-start)))
+ (not (or lazy-highlight-buffer
+ (= (window-group-end) ; Window may have been split/joined.
+ isearch-lazy-highlight-window-end)))))
;; something important did indeed change
(lazy-highlight-cleanup t (not (equal isearch-string ""))) ;stop old timer
(setq isearch-lazy-highlight-error isearch-error)
@@ -3303,9 +3324,18 @@ isearch-lazy-highlight-new-loop
(1- (length isearch-lazy-highlight-last-string)))
(point-min))))
(unless (equal isearch-string "")
+ (when (and isearch-lazy-count isearch-mode)
+ (when isearch-lazy-count-start
+ (clrhash isearch-lazy-count-hash)
+ (setq isearch-lazy-count-current nil
+ isearch-lazy-count-total nil)))
(setq isearch-lazy-highlight-timer
(run-with-idle-timer lazy-highlight-initial-delay nil
- 'isearch-lazy-highlight-start)))))
+ 'isearch-lazy-highlight-start))))
+ (when (and isearch-lazy-count isearch-mode)
+ (setq isearch-lazy-count-current
+ (gethash isearch-other-end isearch-lazy-count-hash))
+ (funcall (or isearch-message-function #'isearch-message) nil t)))
(defun isearch-lazy-highlight-search (string bound)
"Search ahead for the next or previous match, for lazy highlighting.
@@ -3426,7 +3456,8 @@ isearch-lazy-highlight-update
(goto-char (min (or isearch-lazy-highlight-end-limit (point-max))
window-end)))))))
(if nomore
- (when isearch-lazy-highlight-buffer
+ (when (or isearch-lazy-highlight-buffer
+ isearch-lazy-count-start)
(if isearch-lazy-highlight-forward
(setq isearch-lazy-highlight-end (point-min))
(setq isearch-lazy-highlight-start (point-max)))
@@ -3475,8 +3506,13 @@ isearch-lazy-highlight-buffer-update
(if (= mb (point-min))
(setq found nil)
(forward-char -1)))
+ (setq isearch-lazy-count-total (1+ (or isearch-lazy-count-total 0)))
+ (puthash (if isearch-lazy-highlight-forward mb me)
+ isearch-lazy-count-total
+ isearch-lazy-count-hash)
;; Already highlighted by isearch-lazy-highlight-update
- (unless (and (>= mb window-start) (<= me window-end))
+ (unless (or (and (>= mb window-start) (<= me window-end))
+ (not isearch-lazy-highlight-buffer))
;; non-zero-length match
(isearch-lazy-highlight-match mb me)))
;; Remember the current position of point for
@@ -3491,6 +3527,10 @@ isearch-lazy-highlight-buffer-update
(setq looping nil
nomore t))))
(unless nomore
+ (when (and isearch-lazy-count isearch-mode)
+ (setq isearch-lazy-count-current
+ (gethash isearch-other-end isearch-lazy-count-hash))
+ (funcall (or isearch-message-function #'isearch-message) nil t))
(setq isearch-lazy-highlight-timer
(run-at-time lazy-highlight-interval nil
'isearch-lazy-highlight-buffer-update)))))))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sat, 27 Oct 2018 21:32:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> > Isearch could show in the mode line how many matches follow or precede
> > the currently highlighted one (or we could write "3 of 4 matches", as,
> > e.g., Firefox does). For big files, it could be helpful to calculate
> > this information either lazily or in another thread.
>
> Thanks to Drew,
Thanks to you, not me. I did something similar, but partial
and misguided, trying to use only *-max-*. The code you
added is similar but DTRT.
> now we have the full-buffer lazy-highlighting
> loop that can be reused for Isearch hit count.
>
> Here is a minimal patch that implements this feature:
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sat, 27 Oct 2018 22:26:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> > Isearch could show in the mode line how many matches follow or precede
> > the currently highlighted one (or we could write "3 of 4 matches", as,
> > e.g., Firefox does). For big files, it could be helpful to calculate
> > this information either lazily or in another thread.
1. The doc for `isearch-lazy-count' says this:
Counts matches in the full buffer.
When non-nil, all matches in the full buffer are counted.
The user-visible difference is the indication in the Isearch
prompt of the current match number and the total number.
The current doc makes it sounds like it maybe counts matches
other than for the full buffer when nil, or that this depends
in some way on `isearch-lazy-highlight-buffer'. And it doesn't
say what is done with the count.
Suggested doc (or similar):
Show match number in the Isearch prompt.
Non-nil means show CURRENT/TOTAL, where CURRENT is the current match
number and TOTAL is the number of matches in the buffer (or its
restriction).
2. If I set `isearch-lazy-highlight' to nil after using search
with it as t, the last lazy count indication remains present,
even though the count does not get updated.
3. Since (presumably) this counting feature is available only
when `isearch-lazy-highlight' is non-nil, which justifies the
use of "lazy" in the option value, this fact should be mentioned
in the doc.
Suggested doc (or similar):
Show match number in the Isearch prompt.
When both this option and `isearch-lazy-highlight' are non-nil, show
CURRENT/TOTAL, where CURRENT is the current match number and TOTAL is
the total number of matches in the buffer (or its restriction).
4. Maybe the option should be called `isearch-show-match-number',
but `isearch-lazy-count' sounds better, and it hints that it
depends on `isearch-lazy-highlight'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sat, 27 Oct 2018 22:59:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 29321 <at> debbugs.gnu.org (full text, mbox):
Juri: Adapting your patch to my code, I notice that it uses
`isearch-lazy-highlight-buffer' instead of
`isearch-lazy-highlight-buffer-p' now. Did you intend that
change back to using the option in those occurrences?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sat, 27 Oct 2018 23:24:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> Juri: Adapting your patch to my code, I notice that it uses
> `isearch-lazy-highlight-buffer' instead of
> `isearch-lazy-highlight-buffer-p' now. Did you intend that
> change back to using the option in those occurrences?
More exactly, it seems like you use a mix now of
`isearch-lazy-highlight-buffer' and `lazy-highlight-buffer'
(no `isearch-'), the latter of which is not in your previous
patches at all (for bug #29360).
Please advise. What replaced what exactly, in this regard?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 28 Oct 2018 00:04:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> > Juri: Adapting your patch to my code, I notice that it uses
> > `isearch-lazy-highlight-buffer' instead of
> > `isearch-lazy-highlight-buffer-p' now. Did you intend that
> > change back to using the option in those occurrences?
>
> More exactly, it seems like you use a mix now of
> `isearch-lazy-highlight-buffer' and `lazy-highlight-buffer'
> (no `isearch-'), the latter of which is not in your previous
> patches at all (for bug #29360).
>
> Please advise. What replaced what exactly, in this regard?
I guess that since your patch to the bug thread you just renamed
isearch-lazy-highlight-buffer to lazy-highlight-buffer and you
renamed isearch-lazy-highlight-buffer-p to
isearch-lazy-highlight-buffer.
If something other or more than that was involved, please let me know.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 28 Oct 2018 03:36:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 29321 <at> debbugs.gnu.org (full text, mbox):
I'm seeing a bug, I think, when I switch directions. I
applied your patch manually, so perhaps I made a mistake,
but this is what I see:
E.g., I search for "ea" in the patched isearch.el, starting
about 1/2 way through the file, say at the beginning of the
line "(isearch-define-mode-toggle invisible..."
First, when I hit `C-s ea' I see 1248/2520, but then another
`C-s' shows 1249/2530 - the total has jumped by 10.
I continue searching forward, and the numbering seems normal:
1250/2530, 1251/2530. OK, so the initial total was off by 10.
But at match #1251 I switch to `C-r', and the match number is
1241/2520: both the match number and the total are off by 10.
On a small buffer I don't notice this problem.
Do you see this too? If not, maybe I patched mistakenly.
----
Another problem I see is that sometimes when I switch
directions no match number is displayed. After a few
repeated searches in the new direction sometimes the match
number reappears.
E.g., I start and repeat a forward search for "ea" a few
lines before the end of the buffer, then I reverse to `C-r'.
But this problem is not reproducible reliably: sometimes
it happens, sometimes the match number is shown each time,
immediately.
Dunno whether you will see this one. But if I didn't make
a mistake applying the patch (to vanilla isearch.el) then
I think you should be able to see the wrong-numbers problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 28 Oct 2018 22:41:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 29321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> First, when I hit `C-s ea' I see 1248/2520, but then another
> `C-s' shows 1249/2530 - the total has jumped by 10.
>
> I continue searching forward, and the numbering seems normal:
> 1250/2530, 1251/2530. OK, so the initial total was off by 10.
>
> But at match #1251 I switch to `C-r', and the match number is
> 1241/2520: both the match number and the total are off by 10.
>
> On a small buffer I don't notice this problem.
>
> Do you see this too? If not, maybe I patched mistakenly.
I see this too. The problem was in too frequent updating
of the Isearch prompt - the loop updated it after every
max-at-a-time (default 20) matches, thus causing flickering
(that didn't update the final number). Now changed to show
only the final number without showing intermediate numbers
(that are invalid during counting anyway).
Please try a new patch, it removes flickering:
[isearch-lazy-count.2.diff (text/x-diff, inline)]
diff --git a/lisp/isearch.el b/lisp/isearch.el
index 580b3ac40a..9127c4561a 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -316,6 +316,15 @@ isearch-lazy-highlight
:group 'lazy-highlight
:group 'isearch)
+(defcustom isearch-lazy-count nil
+ "Show match number in the Isearch prompt.
+When both this option and `isearch-lazy-highlight' are non-nil, show
+CURRENT/TOTAL, where CURRENT is the current match number and TOTAL is
+the total number of matches in the buffer (or its restriction)."
+ :type 'boolean
+ :group 'isearch
+ :version "27.1")
+
;;; Lazy highlight customization.
(defgroup lazy-highlight nil
@@ -2802,7 +2811,16 @@ isearch-message-suffix
(if isearch-error
(concat " [" isearch-error "]")
"")
- (or isearch-message-suffix-add ""))
+ (or isearch-message-suffix-add "")
+ (if (and isearch-lazy-count isearch-lazy-count-current)
+ (format " (%d of %d)"
+ (if isearch-forward
+ isearch-lazy-count-current
+ (- isearch-lazy-count-total
+ isearch-lazy-count-current
+ -1))
+ (or isearch-lazy-count-total "?"))
+ ""))
'face 'minibuffer-prompt))
@@ -3212,6 +3230,10 @@ 'isearch-lazy-highlight-word
(defvar isearch-lazy-highlight-regexp-function nil)
(defvar isearch-lazy-highlight-forward nil)
(defvar isearch-lazy-highlight-error nil)
+(defvar isearch-lazy-count-current nil)
+(defvar isearch-lazy-count-total nil)
+(defvar isearch-lazy-count-start nil)
+(defvar isearch-lazy-count-hash (make-hash-table))
(defun lazy-highlight-cleanup (&optional force procrastinate)
"Stop lazy highlighting and remove extra highlighting from current buffer.
@@ -3235,33 +3257,35 @@ isearch-lazy-highlight-new-loop
This is called when `isearch-update' is invoked (which can cause the
search string to change or the window to scroll). It is also used
by other Emacs features."
+ (setq isearch-lazy-count-start
+ (or (not (equal isearch-string
+ isearch-lazy-highlight-last-string))
+ (not (memq (selected-window)
+ isearch-lazy-highlight-window-group))
+ (not (eq isearch-lazy-highlight-case-fold-search
+ isearch-case-fold-search))
+ (not (eq isearch-lazy-highlight-regexp
+ isearch-regexp))
+ (not (eq isearch-lazy-highlight-regexp-function
+ isearch-regexp-function))
+ (not (eq isearch-lazy-highlight-lax-whitespace
+ isearch-lax-whitespace))
+ (not (eq isearch-lazy-highlight-regexp-lax-whitespace
+ isearch-regexp-lax-whitespace))
+ (not (eq isearch-forward
+ isearch-lazy-highlight-forward))
+ ;; In case we are recovering from an error.
+ (not (equal isearch-error
+ isearch-lazy-highlight-error))))
(when (and (null executing-kbd-macro)
(sit-for 0) ;make sure (window-start) is credible
- (or (not (equal isearch-string
- isearch-lazy-highlight-last-string))
- (not (memq (selected-window)
- isearch-lazy-highlight-window-group))
- (not (eq isearch-lazy-highlight-case-fold-search
- isearch-case-fold-search))
- (not (eq isearch-lazy-highlight-regexp
- isearch-regexp))
- (not (eq isearch-lazy-highlight-regexp-function
- isearch-regexp-function))
- (not (eq isearch-lazy-highlight-lax-whitespace
- isearch-lax-whitespace))
- (not (eq isearch-lazy-highlight-regexp-lax-whitespace
- isearch-regexp-lax-whitespace))
- (not (or lazy-highlight-buffer
- (= (window-group-start)
+ (or isearch-lazy-count-start
+ (not (or lazy-highlight-buffer
+ (= (window-group-start)
isearch-lazy-highlight-window-start)))
- (not (or lazy-highlight-buffer
- (= (window-group-end) ; Window may have been split/joined.
- isearch-lazy-highlight-window-end)))
- (not (eq isearch-forward
- isearch-lazy-highlight-forward))
- ;; In case we are recovering from an error.
- (not (equal isearch-error
- isearch-lazy-highlight-error))))
+ (not (or lazy-highlight-buffer
+ (= (window-group-end) ; Window may have been split/joined.
+ isearch-lazy-highlight-window-end)))))
;; something important did indeed change
(lazy-highlight-cleanup t (not (equal isearch-string ""))) ;stop old timer
(setq isearch-lazy-highlight-error isearch-error)
@@ -3303,9 +3327,22 @@ isearch-lazy-highlight-new-loop
(1- (length isearch-lazy-highlight-last-string)))
(point-min))))
(unless (equal isearch-string "")
+ (when (and isearch-lazy-count isearch-mode)
+ (when isearch-lazy-count-start
+ (clrhash isearch-lazy-count-hash)
+ (setq isearch-lazy-count-current nil
+ isearch-lazy-count-total nil)
+ (funcall (or isearch-message-function #'isearch-message) nil t)))
(setq isearch-lazy-highlight-timer
(run-with-idle-timer lazy-highlight-initial-delay nil
- 'isearch-lazy-highlight-start)))))
+ 'isearch-lazy-highlight-start))))
+ (when (and isearch-lazy-count isearch-mode)
+ ;; Update isearch-lazy-count-current only when it was already set
+ ;; at the end of isearch-lazy-highlight-buffer-update
+ (when isearch-lazy-count-current
+ (setq isearch-lazy-count-current
+ (gethash isearch-other-end isearch-lazy-count-hash))
+ (funcall (or isearch-message-function #'isearch-message) nil t))))
(defun isearch-lazy-highlight-search (string bound)
"Search ahead for the next or previous match, for lazy highlighting.
@@ -3426,7 +3463,8 @@ isearch-lazy-highlight-update
(goto-char (min (or isearch-lazy-highlight-end-limit (point-max))
window-end)))))))
(if nomore
- (when isearch-lazy-highlight-buffer
+ (when (or isearch-lazy-highlight-buffer
+ isearch-lazy-count-start)
(if isearch-lazy-highlight-forward
(setq isearch-lazy-highlight-end (point-min))
(setq isearch-lazy-highlight-start (point-max)))
@@ -3475,8 +3513,13 @@ isearch-lazy-highlight-buffer-update
(if (= mb (point-min))
(setq found nil)
(forward-char -1)))
+ (setq isearch-lazy-count-total (1+ (or isearch-lazy-count-total 0)))
+ (puthash (if isearch-lazy-highlight-forward mb me)
+ isearch-lazy-count-total
+ isearch-lazy-count-hash)
;; Already highlighted by isearch-lazy-highlight-update
- (unless (and (>= mb window-start) (<= me window-end))
+ (unless (or (and (>= mb window-start) (<= me window-end))
+ (not isearch-lazy-highlight-buffer))
;; non-zero-length match
(isearch-lazy-highlight-match mb me)))
;; Remember the current position of point for
@@ -3490,7 +3533,11 @@ isearch-lazy-highlight-buffer-update
(if (not found)
(setq looping nil
nomore t))))
- (unless nomore
+ (if nomore
+ (when (and isearch-lazy-count isearch-mode)
+ (setq isearch-lazy-count-current
+ (gethash isearch-other-end isearch-lazy-count-hash))
+ (funcall (or isearch-message-function #'isearch-message) nil t))
(setq isearch-lazy-highlight-timer
(run-at-time lazy-highlight-interval nil
'isearch-lazy-highlight-buffer-update)))))))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Mon, 29 Oct 2018 00:23:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 29321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> > First, when I hit `C-s ea' I see 1248/2520, but then another
> > `C-s' shows 1249/2530 - the total has jumped by 10.
> >
> > I continue searching forward, and the numbering seems normal:
> > 1250/2530, 1251/2530. OK, so the initial total was off by 10.
> >
> > But at match #1251 I switch to `C-r', and the match number is
> > 1241/2520: both the match number and the total are off by 10.
> >
> > On a small buffer I don't notice this problem.
> >
> > Do you see this too? If not, maybe I patched mistakenly.
>
> I see this too. The problem was in too frequent updating
> of the Isearch prompt - the loop updated it after every
> max-at-a-time (default 20) matches, thus causing flickering
> (that didn't update the final number). Now changed to show
> only the final number without showing intermediate numbers
> (that are invalid during counting anyway).
>
> Please try a new patch, it removes flickering:
OK, I applied the new patch.
Here's my feedback, in case it helps.
For my own code, after the update search seems very slow.
Just mentioning that - not that it's relevant.
For vanilla Emacs after the update:
1. When I repeat searching quickly the count can freeze
(not get updated), and when I stop or slow down, and
then start (repeat) again, it is still frozen.
2. When that's happened and I reverse direction, it's
also frozen, even without repeating quickly. And
what's worse, the match number is completely wrong.
E.g., if I'm near the buffer beginning the match
number is near the end. Perhaps it is the complement
(numbering from the end and not from the beginning,
when C-M-r direction.
In general, the numbers seem quite messed up now.
I can go to the end of the file and get different
numbers for the last match, neither of which is the
highest match number (i.e., not = total).
BTW, with the previous update I'm pretty sure I at
one point saw the same thing about the numbering
switching to the complement (might not be the exact
complement). I even thought that might be intended,
and so I reworded the doc string of the option to fit
that. But afterward I never saw that again yesterday.
See attached screenshot. Note that this was a new
search with the same input as a previous search.
But once it has the wrong numbering it seems to stick
with the "complement" numbers.
Dunno how much this helps. I again applied the patch
manually. I've attached the resulting file - perhaps
you can diff it against what it should be, to see if
it is faithful or I made a mistake. That might save
us some time, if I did make a mistake. I don't want
to provide misleading feedback.
Less relevant - just personal opinion: I prefer the
numbering in the prefix form CURRENT/TOTAL, rather
than the suffix, I think. But I could change my mind.
What are the reasons you prefer it as a suffix - or is
it just better in terms of implementation/performance?
BTW: I just noticed that the doc string for the option
is now wrong, since it still says "CURRENT/TOTAL".
Maybe you should to change it to just say something
like "show the current match number and the total
number of..."
HTH, and thanks for working on this. - Drew
[isearch-2018-10-27a-AFTER-JURI-10-28a.el (application/octet-stream, attachment)]
[throw-isearch-count-2018-10-28.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Mon, 29 Oct 2018 23:34:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 29321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> OK, I applied the new patch.
>
> Here's my feedback, in case it helps.
>
> For my own code, after the update search seems very slow.
> Just mentioning that - not that it's relevant.
It is slow when you set lazy-highlight-buffer to t
at the same when isearch-lazy-count is t because
adding overlays to all matches in the full buffer
is very slow and it slows down the counting of matches
that is preformed in the same loop.
Maybe for optimization we should run the matches-counting loop
first and only after that the full-buffer highlighting loop?
> Dunno how much this helps. I again applied the patch
> manually. I've attached the resulting file - perhaps
> you can diff it against what it should be, to see if
> it is faithful or I made a mistake. That might save
> us some time, if I did make a mistake. I don't want
> to provide misleading feedback.
I see that your version misses an important change in
isearch-lazy-highlight-new-loop. So for your convenience
I attached below a complete patched isearch.el.
> Less relevant - just personal opinion: I prefer the
> numbering in the prefix form CURRENT/TOTAL, rather
> than the suffix, I think. But I could change my mind.
> What are the reasons you prefer it as a suffix - or is
> it just better in terms of implementation/performance?
I have no preference. For example, Chromium displays the
count as CURRENT/TOTAL whereas Firefox as (CURRENT of TOTAL).
So I changed back to CURRENT/TOTAL in the prefix here:
[isearch.count.3.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Tue, 30 Oct 2018 02:45:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> > OK, I applied the new patch.
> >
> > Here's my feedback, in case it helps.
> >
> > For my own code, after the update search seems very slow.
> > Just mentioning that - not that it's relevant.
>
> It is slow when you set lazy-highlight-buffer to t
> at the same when isearch-lazy-count is t because
> adding overlays to all matches in the full buffer
> is very slow and it slows down the counting of matches
> that is preformed in the same loop.
No, I meant with lazy-highlight-buffer nil. But again,
that was only with my own code. I won't worry about
that now.
> Maybe for optimization we should run the matches-counting loop
> first and only after that the full-buffer highlighting loop?
Dunno. I'm not worried yet about any interaction between
them. But if you want to think about that, good.
> > Dunno how much this helps. I again applied the patch
> > manually. I've attached the resulting file - perhaps
> > you can diff it against what it should be, to see if
> > it is faithful or I made a mistake. That might save
> > us some time, if I did make a mistake. I don't want
> > to provide misleading feedback.
>
> I see that your version misses an important change in
> isearch-lazy-highlight-new-loop. So for your convenience
> I attached below a complete patched isearch.el.
Ah! Thanks for checking. I'm glad to hear I made
a mistake patching. Sorry for taking your time to
check it.
> > Less relevant - just personal opinion: I prefer the
> > numbering in the prefix form CURRENT/TOTAL, rather
> > than the suffix, I think. But I could change my mind.
> > What are the reasons you prefer it as a suffix - or is
> > it just better in terms of implementation/performance?
>
> I have no preference. For example, Chromium displays the
> count as CURRENT/TOTAL whereas Firefox as (CURRENT of TOTAL).
> So I changed back to CURRENT/TOTAL in the prefix here:
Thanks. I'll take a look and get back to you.
- D
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Tue, 30 Oct 2018 03:21:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 29321 <at> debbugs.gnu.org (full text, mbox):
OK, tried it. Yes, I apparently mispatched last time.
This version is more like the first version (and the
code looks more like what I had before, for *-new-loop*).
I still do see the problem (did I mention this one?)
that if I reverse direction so that the prompt changes
to, say, Overwrapped..., there is no count shown. But
later sometimes it comes back.
Does this make sense? Why would the prompt sometimes
disappear? That must mean that, for some reason,
`isearch-lazy-count-current' is nil, right?
Do you see this? It might help to repeat-search
quickly; dunno. I'm still searching just with the
regexp "se\(.*\)r", FWIW.
But what's weird is that other times when I do (what
I think is) the exact same thing I see no problem -
no loss of count from the prompt when switching
direction.
In any case, if I quit search and restart it the
count is always displayed again in the prompt.
Maybe play with it a bit to see if you don't see
what I mentioned sometimes?
I think I can make it happen by repeating slowly
just after switching direction (either direction).
I have a feeling it's related to the fact that when
you first switch direction the count is missing
from the prompt, just as it is missing when you
first type `C-M-s' or `C-M-r', to start Isearch.
I'm guessing that sometimes that initial state
remains, for some reason - as if it were the first
time, just starting Isearch. Does this ring a bell
at all? Is there some way it might think that it's
just starting out and so does not show the count?
HTH - Drew
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Tue, 30 Oct 2018 03:49:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 29321 <at> debbugs.gnu.org (full text, mbox):
Here's another hypothesis for losing the count in the
prompt. It might also explain why it's easier in my
code, which is slower, to lose the prompt.
It's harder to lose the count in vanilla Emacs with
your file, but with my version (my code) I can lose
it quite easily by doing this:
Repeat searching so fast (hold down the key) that
Isearch does not bother to lazy-highlight each hit -
it just moves forward to the next match each time,
rapidly, skipping lazy highlighting (because there
is no time to lazy highlight - all effort is spent
on moving to the next match).
When I do that, in my (slower) code, the count is
lost from the prompt, pretty consistently. And
even if I then slow down it does not come back.
Eventually it might come back. And changing
direction also seems to be a time when it can get
lost.
Dunno whether this info helps, especially because
I see the problem much more with my own version.
It's harder to repro it for vanilla Emacs (just
your file).
Thx - Drew
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Tue, 30 Oct 2018 04:03:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 29321 <at> debbugs.gnu.org (full text, mbox):
I'll stop after this message; sorry for all the noise.
Just wanted to add to that hypothesis. I think it
happens only if I start out repeating fast, that is,
if the display of lazy highlighting never has a
chance to kick in.
The prompt disappears entirely of course, while search
just moves to the next hit without lazy highlighting.
But in that context the count never gets added, even
if I slow down or stop, so that lazy highlighting
catches up. But once it's caught up, if I switch
direction at that point then the count comes back.
HTH.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Tue, 30 Oct 2018 23:13:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 29321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I still do see the problem (did I mention this one?)
> that if I reverse direction so that the prompt changes
> to, say, Overwrapped..., there is no count shown. But
> later sometimes it comes back.
>
> Does this make sense? Why would the prompt sometimes
> disappear? That must mean that, for some reason,
> `isearch-lazy-count-current' is nil, right?
>
> Do you see this? It might help to repeat-search
> quickly; dunno. I'm still searching just with the
> regexp "se\(.*\)r", FWIW.
Congratulations, you stumbled upon long-standing backward regexp
search controversy.
Reversing direction invalidates the number of matches
because it will find another number. Did you notice
that the total number of matches is different after
switching direction e.g. for "se\(.*\)r"?
Here is a minimal test case:
0. emacs -Q
1. Paste this text to the end of *scratch*:
Does this make sense? Why would the prompt sometimes disappear?
2. For convenience, put this regexp to the regexp search history:
C-M-s se\(.*\)r RET
3. Go to the beginning of *scratch*
4. Type C-M-s C-s
See the following text is matched and highlighted:
sense? Why would the prompt sometimes disappear?
5. Type C-r
See another part of this text is matched and highlighted:
se? Why would the prompt sometimes disappear?
6. Type C-s
See the second text is matched and highlighted:
se? Why would the prompt sometimes disappear?
not the initial text:
sense? Why would the prompt sometimes disappear?
This is why no count is shown. Lazy-count searches
from the top of the buffer. However, C-s C-r C-s
finds a shorter match after switching direction.
The problem occurs only with different values of
isearch-other-end that corresponds to match-beginning,
not with match-end that coincides with point.
Initially I planned to use point, not isearch-other-end.
But since there is no special isearch variable for point,
and the value of point is changed by the lazy updating,
I was too lazy to add a corresponding variable for point.
Now a new version attached below just let-binds the
initial value of point. You can compare it with the
previous version to see the change. The fix is very small.
[isearch.count.4.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Tue, 30 Oct 2018 23:36:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> > I still do see the problem (did I mention this one?)
> > that if I reverse direction so that the prompt changes
> > to, say, Overwrapped..., there is no count shown. But
> > later sometimes it comes back.
> >
> > Does this make sense? Why would the prompt sometimes
> > disappear? That must mean that, for some reason,
> > `isearch-lazy-count-current' is nil, right?
> >
> > Do you see this? It might help to repeat-search
> > quickly; dunno. I'm still searching just with the
> > regexp "se\(.*\)r", FWIW.
>
> Congratulations, you stumbled upon long-standing backward regexp
> search controversy.
>
> Reversing direction invalidates the number of matches
> because it will find another number. Did you notice
> that the total number of matches is different after
> switching direction e.g. for "se\(.*\)r"?
I didn't notice it, but sure, I understand that matching
backward is not the same as forward.
Dunno why that would produce the symptoms I described,
however.
> Here is a minimal test case:
>
> 0. emacs -Q
> 1. Paste this text to the end of *scratch*:
> Does this make sense? Why would the prompt sometimes disappear?
> 2. For convenience, put this regexp to the regexp search history:
> C-M-s se\(.*\)r RET
> 3. Go to the beginning of *scratch*
> 4. Type C-M-s C-s
>
> See the following text is matched and highlighted:
> sense? Why would the prompt sometimes disappear?
> 5. Type C-r
> See another part of this text is matched and highlighted:
> se? Why would the prompt sometimes disappear?
> 6. Type C-s
> See the second text is matched and highlighted:
> se? Why would the prompt sometimes disappear?
>
> not the initial text:
> sense? Why would the prompt sometimes disappear?
>
> This is why no count is shown. Lazy-count searches
> from the top of the buffer. However, C-s C-r C-s
> finds a shorter match after switching direction.
That all makes sense.
But I don't think that explains the part of the
behavior where the prompt does not appear without
changing direction, just by repeating search (e.g.
always forward) very quickly. Or if it does explain
it somehow, I don't quite get it yet.
> The problem occurs only with different values of
> isearch-other-end that corresponds to match-beginning,
> not with match-end that coincides with point.
>
> Initially I planned to use point, not isearch-other-end.
> But since there is no special isearch variable for point,
> and the value of point is changed by the lazy updating,
> I was too lazy to add a corresponding variable for point.
>
> Now a new version attached below just let-binds the
> initial value of point. You can compare it with the
> previous version to see the change. The fix is very small.
I'll give it a try.
Thx - Drew
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Tue, 30 Oct 2018 23:44:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 29321 <at> debbugs.gnu.org (full text, mbox):
I tried it, but I still see the problem. If I repeat
quickly there won't be a count in the prompt, and not
just at the beginning. Or there might be one, but
then when I switch direction it disappears (rightly
so, as you pointed out), but if I continue repeating
in that new direction the count never appears.
In sum, I see pretty much the same thing I reported.
Maybe this can be ignored. But it would be good if
you could confirm that you see the same thing, at
least.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Wed, 31 Oct 2018 21:37:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> I tried it, but I still see the problem. If I repeat
> quickly there won't be a count in the prompt, and not
> just at the beginning. Or there might be one, but
> then when I switch direction it disappears (rightly
> so, as you pointed out), but if I continue repeating
> in that new direction the count never appears.
When you type too quickly, lazy-highlighting (that also counts
the number of matches) has no chance to run its timer function.
It runs with (run-with-idle-timer lazy-highlight-initial-delay ...)
This means that it runs only after lazy-highlight-initial-delay
(by default, 0.25 secs) of inactivity.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Wed, 31 Oct 2018 22:08:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> > I tried it, but I still see the problem. If I repeat
> > quickly there won't be a count in the prompt, and not
> > just at the beginning. Or there might be one, but
> > then when I switch direction it disappears (rightly
> > so, as you pointed out), but if I continue repeating
> > in that new direction the count never appears.
>
> When you type too quickly, lazy-highlighting (that also counts
> the number of matches) has no chance to run its timer function.
> It runs with (run-with-idle-timer lazy-highlight-initial-delay ...)
> This means that it runs only after lazy-highlight-initial-delay
> (by default, 0.25 secs) of inactivity.
Sure, but why does the count not get displayed after you
slow down or even stop (while remaining in Isearch).
That's my question.
That it doesn't get shown as long as you just keep C-M-s
pressed, without letting up, is understandable. But why
isn't the count shown when you let up?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Thu, 01 Nov 2018 22:47:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 29321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> > I tried it, but I still see the problem. If I repeat
>> > quickly there won't be a count in the prompt, and not
>> > just at the beginning. Or there might be one, but
>> > then when I switch direction it disappears (rightly
>> > so, as you pointed out), but if I continue repeating
>> > in that new direction the count never appears.
>>
>> When you type too quickly, lazy-highlighting (that also counts
>> the number of matches) has no chance to run its timer function.
>> It runs with (run-with-idle-timer lazy-highlight-initial-delay ...)
>> This means that it runs only after lazy-highlight-initial-delay
>> (by default, 0.25 secs) of inactivity.
>
> Sure, but why does the count not get displayed after you
> slow down or even stop (while remaining in Isearch).
> That's my question.
>
> That it doesn't get shown as long as you just keep C-M-s
> pressed, without letting up, is understandable. But why
> isn't the count shown when you let up?
I now see that you are testing in the *info* buffer.
Yes, I see the same - the number of matches and overlays
are not updated when going to another Info node.
I fixed this to check the previous and current values
of (point-min) and (point-max) - they are different in
different Info nodes.
Another problem when the number was not displayed is
when you start searching forward at the end of the buffer,
and there are matches above. I fixed it to display e.g.
"0/123", meaning there are 123 matches total, but there is
no current match yet.
Also in a new version attached I added a new function
isearch-lazy-count-format that is easy to redefine
to display current/total in another format either
in the message prefix or suffix.
[isearch.count.5.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Thu, 01 Nov 2018 23:47:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> >> > I tried it, but I still see the problem. If I repeat
> >> > quickly there won't be a count in the prompt, and not
> >> > just at the beginning. Or there might be one, but
> >> > then when I switch direction it disappears (rightly
> >> > so, as you pointed out), but if I continue repeating
> >> > in that new direction the count never appears.
> >>
> >> When you type too quickly, lazy-highlighting (that also counts
> >> the number of matches) has no chance to run its timer function.
> >> It runs with (run-with-idle-timer lazy-highlight-initial-delay ...)
> >> This means that it runs only after lazy-highlight-initial-delay
> >> (by default, 0.25 secs) of inactivity.
> >
> > Sure, but why does the count not get displayed after you
> > slow down or even stop (while remaining in Isearch).
> > That's my question.
> >
> > That it doesn't get shown as long as you just keep C-M-s
> > pressed, without letting up, is understandable. But why
> > isn't the count shown when you let up?
>
> I now see that you are testing in the *info* buffer.
> Yes, I see the same - the number of matches and overlays
> are not updated when going to another Info node.
> I fixed this to check the previous and current values
> of (point-min) and (point-max) - they are different in
> different Info nodes.
>
> Another problem when the number was not displayed is
> when you start searching forward at the end of the buffer,
> and there are matches above. I fixed it to display e.g.
> "0/123", meaning there are 123 matches total, but there is
> no current match yet.
>
> Also in a new version attached I added a new function
> isearch-lazy-count-format that is easy to redefine
> to display current/total in another format either
> in the message prefix or suffix.
Thanks for checking and for the new version. I'll give
it a try when I can.
But no, I wasn't testing in *info*. I think I was testing
just in isearch.el (the new one). I don't recall for sure.
But what made you think I was testing in *info*? And why
does the buffer matter?
Being able to specify the format is good. (Haven't looked
at the code yet, but I would have expected a variable (even
an option perhaps) instead of a function, a priori.)
Thx - Drew
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Fri, 02 Nov 2018 12:52:02 GMT)
Full text and
rfc822 format available.
Message #83 received at submit <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
Hi,
>>> > I tried it, but I still see the problem. If I repeat
>>> > quickly there won't be a count in the prompt, and not
>>> > just at the beginning. Or there might be one, but
>>> > then when I switch direction it disappears (rightly
>>> > so, as you pointed out), but if I continue repeating
>>> > in that new direction the count never appears.
>>>
>>> When you type too quickly, lazy-highlighting (that also counts
>>> the number of matches) has no chance to run its timer function.
>>> It runs with (run-with-idle-timer lazy-highlight-initial-delay ...)
>>> This means that it runs only after lazy-highlight-initial-delay
>>> (by default, 0.25 secs) of inactivity.
>>
>> Sure, but why does the count not get displayed after you
>> slow down or even stop (while remaining in Isearch).
>> That's my question.
>>
>> That it doesn't get shown as long as you just keep C-M-s
>> pressed, without letting up, is understandable. But why
>> isn't the count shown when you let up?
>
> I now see that you are testing in the *info* buffer.
> Yes, I see the same - the number of matches and overlays
> are not updated when going to another Info node.
> I fixed this to check the previous and current values
> of (point-min) and (point-max) - they are different in
> different Info nodes.
>
> Another problem when the number was not displayed is
> when you start searching forward at the end of the buffer,
> and there are matches above. I fixed it to display e.g.
> "0/123", meaning there are 123 matches total, but there is
> no current match yet.
>
> Also in a new version attached I added a new function
> isearch-lazy-count-format that is easy to redefine
> to display current/total in another format either
> in the message prefix or suffix.
Thank you for adding this!
Now that you have the count, would it be posible to add a
command to specify which occurane of a match to go to and/or
highlight?
Lets say there are 100 matches. I search through them and wind
up at 42/100. I stop seaching and do something else. I decide
I want to go back to my previous search. It would be very handy
to have a command to do "goto match 42" or "goto match 67" or
"goto match last-match" .e.g. go directly to 100/100 (since 100
is the last found numbered match reported by isearch) and I would
then see the 100th match highlighted and the indicator displaying
"100/100".
Let me know if this should be a separate enhancement request.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 04 Nov 2018 00:38:03 GMT)
Full text and
rfc822 format available.
Message #86 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> Now that you have the count, would it be posible to add a
> command to specify which occurane of a match to go to and/or
> highlight?
>
> Lets say there are 100 matches. I search through them and wind
> up at 42/100. I stop seaching and do something else. I decide
> I want to go back to my previous search. It would be very handy
> to have a command to do "goto match 42" or "goto match 67" or
> "goto match last-match" .e.g. go directly to 100/100 (since 100
> is the last found numbered match reported by isearch) and I would
> then see the 100th match highlighted and the indicator displaying
> "100/100".
>
> Let me know if this should be a separate enhancement request.
Thanks for the enhancement request. This is possible to do with
this patch. It allows to go to the beginning of the buffer and type
'C-s C-4 C-2 C-s', and it will go to the 42th match using the
previous search string:
diff --git a/lisp/isearch.el b/lisp/isearch.el
index 580b3ac40a..2dbb890d88 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -1563,15 +1572,19 @@ isearch-repeat
(isearch-push-state)
(isearch-update))
-(defun isearch-repeat-forward ()
- "Repeat incremental search forwards."
- (interactive)
- (isearch-repeat 'forward))
+(defun isearch-repeat-forward (&optional arg)
+ "Repeat incremental search forwards.
+With a prefix argument, repeat a search ARG times."
+ (interactive "p")
+ (dotimes (_ (or arg 1))
+ (isearch-repeat 'forward)))
-(defun isearch-repeat-backward ()
- "Repeat incremental search backwards."
+(defun isearch-repeat-backward (&optional arg)
+ "Repeat incremental search backwards.
+With a prefix argument, repeat a search ARG times."
(interactive)
- (isearch-repeat 'backward))
+ (dotimes (_ (or arg 1))
+ (isearch-repeat 'backward)))
;;; Toggles for `isearch-regexp-function' and `search-default-mode'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 04 Nov 2018 00:38:03 GMT)
Full text and
rfc822 format available.
Message #89 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> Lets say there are 100 matches. I search through them and wind
> up at 42/100. I stop seaching and do something else. I decide
> I want to go back to my previous search. It would be very handy
> to have a command to do "goto match 42" or "goto match 67" or
> "goto match last-match" .e.g. go directly to 100/100 (since 100
> is the last found numbered match reported by isearch) and I would
> then see the 100th match highlighted and the indicator displaying
> "100/100".
Regarding going to the last match, maybe simpler would be to have
these commands?
(defun isearch-beginning-of-buffer ()
"Go to the first occurrence of the current match.
Move isearch point to the beginning of the buffer and repeat the search."
(interactive)
(goto-char (point-min))
(isearch-repeat-forward))
(define-key isearch-mode-map "\M-s\M-<" 'isearch-beginning-of-buffer)
(defun isearch-end-of-buffer ()
"Go to the last occurrence of the current match.
Move isearch point to the end of the buffer and repeat the search."
(interactive)
(goto-char (point-max))
(isearch-repeat-backward))
(define-key isearch-mode-map "\M-s\M->" 'isearch-end-of-buffer)
where in isearch-mode 'M-s M-<' will jump to the first match,
and 'M-s M->' will jump to the last match.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 04 Nov 2018 01:23:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 29321 <at> debbugs.gnu.org (full text, mbox):
I haven't looked at your patches for this (goto match #)
yet. (I haven't even had a chance to check your last patch
for the count yet.)
I was thinking about this request, and thinking along these
lines: Where we count, push (match # . buffer-position)
to an alist variable. The variable would get reinitialized
when counting gets reinitialized (e.g. for a new search
string, direction change, or startup of Isearch).
That alist could be used to go to any given match, either
during the current Isearch or later. If they wanted, users
could even save copies of the alist for different searches,
for subsequent reuse.
Just a (naive) thought. Haven't really thought it through.
It should be possible to move directly to a given match
occurrence, without starting anew from the start of the
buffer, no?
Feel free to say such an approach would be silly. Or slow
or whatever.
I was thinking of binding a key during Isearch to move to
an occurrence by its match number. `M-g' perhaps. With
a numeric prefix arg it would move to that number. With
no prefix arg it would prompt for the number (with
completion requiring a match against the alist).
Just a thought.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 04 Nov 2018 16:48:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 29321 <at> debbugs.gnu.org (full text, mbox):
1. FWIW, I still see, with Emacs -Q (Emacs 26.1), after
loading `isearch.count.5.el', the same behavior of
no prompt when repeating quickly (holding down the
key) and reversing direction (and holding down the
key). Stopping and waiting does not change this -
the prompt never appears.
This is with `isearch.count.5.el' as the buffer
being searched, with regexp search with search
pattern se\(.*\)r.
Do you confirm that you see this also?
2. Instead of a user needing to redefine function
`isearch-lazy-count-format' wouldn't it be better
to provide a variable (perhaps even an option) to
control the prefix-vs-suffix behavior?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 04 Nov 2018 19:15:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 29321 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> Lets say there are 100 matches. I search through them and wind
>> up at 42/100. I stop seaching and do something else. I decide
>> I want to go back to my previous search. It would be very handy
>> to have a command to do "goto match 42" or "goto match 67" or
>> "goto match last-match" .e.g. go directly to 100/100 (since 100
>> is the last found numbered match reported by isearch) and I would
>> then see the 100th match highlighted and the indicator displaying
>> "100/100".
>
> Regarding going to the last match, maybe simpler would be to have
> these commands?
>
> (defun isearch-beginning-of-buffer ()
> "Go to the first occurrence of the current match.
> Move isearch point to the beginning of the buffer and repeat the search."
> (interactive)
> (goto-char (point-min))
> (isearch-repeat-forward))
>
> (define-key isearch-mode-map "\M-s\M-<" 'isearch-beginning-of-buffer)
>
> (defun isearch-end-of-buffer ()
> "Go to the last occurrence of the current match.
> Move isearch point to the end of the buffer and repeat the search."
> (interactive)
> (goto-char (point-max))
> (isearch-repeat-backward))
>
> (define-key isearch-mode-map "\M-s\M->" 'isearch-end-of-buffer)
>
> where in isearch-mode 'M-s M-<' will jump to the first match,
> and 'M-s M->' will jump to the last match.
Perfect! with an excellent choice of keybindings!
Thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 04 Nov 2018 23:02:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> I was thinking about this request, and thinking along these
> lines: Where we count, push (match # . buffer-position)
> to an alist variable. The variable would get reinitialized
> when counting gets reinitialized (e.g. for a new search
> string, direction change, or startup of Isearch).
>
> That alist could be used to go to any given match, either
> during the current Isearch or later. If they wanted, users
> could even save copies of the alist for different searches,
> for subsequent reuse.
A mapping from search parameters (search string, direction, etc.)
to the matches and buffer-positions invalidates too quickly.
Even using point-markers doesn't help when a user deletes
a large region with former matches.
> I was thinking of binding a key during Isearch to move to
> an occurrence by its match number. `M-g' perhaps. With
> a numeric prefix arg it would move to that number. With
> no prefix arg it would prompt for the number (with
> completion requiring a match against the alist).
I understand that in addition to relative counting like
'C-u 42 C-s' would do, you propose absolute counting like
'C-s M-g 42 RET'. But a question: shouldn't 'M-g'
exit the search since it's a global prefix key.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 04 Nov 2018 23:02:04 GMT)
Full text and
rfc822 format available.
Message #104 received at 29321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 1. FWIW, I still see, with Emacs -Q (Emacs 26.1), after
> loading `isearch.count.5.el', the same behavior of
> no prompt when repeating quickly (holding down the
> key) and reversing direction (and holding down the
> key). Stopping and waiting does not change this -
> the prompt never appears.
>
> This is with `isearch.count.5.el' as the buffer
> being searched, with regexp search with search
> pattern se\(.*\)r.
>
> Do you confirm that you see this also?
Thanks for checking this version. Now I can confirm
the same after changing lazy-highlight-initial-delay
from 0 to 0.25. This is now fixed in a new version.
> 2. Instead of a user needing to redefine function
> `isearch-lazy-count-format' wouldn't it be better
> to provide a variable (perhaps even an option) to
> control the prefix-vs-suffix behavior?
Like you suggested, I added a new option in a new version.
(defcustom isearch-lazy-count-prefix #'isearch-lazy-count-prefix-default
But maybe better to allow the users to specify the format like
(defcustom isearch-lazy-count-prefix-format "%s/%s"
What do you think?
Here is a new version:
[isearch.count.6.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Mon, 05 Nov 2018 02:42:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> Here is a new version:
I'll check this when I can. Probably not before a couple
days, though.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Mon, 05 Nov 2018 03:11:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> > I was thinking about this request, and thinking along these
> > lines: Where we count, push (match-# . buffer-position)
> > to an alist variable. The variable would get reinitialized
> > when counting gets reinitialized (e.g. for a new search
> > string, direction change, or startup of Isearch).
> >
> > That alist could be used to go to any given match, either
> > during the current Isearch or later. If they wanted, users
> > could even save copies of the alist for different searches,
> > for subsequent reuse.
>
> A mapping from search parameters (search string, direction, etc.)
> to the matches and buffer-positions invalidates too quickly.
> Even using point-markers doesn't help when a user deletes
> a large region with former matches.
I don't see why. Sure, if someone edits the buffer during
an Isearch recursive edit and then resumes searching it is
possible that some things might be thrown off a bit. But
in general I think the position will be mostly accurate
(obviously different ends of the match would be recorded,
depending on the current search direction).
And even if the position recorded were sometimes off a bit,
resuming search from that position should put you where you
wanted to be almost all of the time. IOW, it would move you
very near, even if not always exactly to, the relevant search
occurrence. So searching from there would be right on, or
maybe one occurrence away from, the desired occurrence.
It's possible I'm not understanding you, however. I don't
see a real problem here, but that doesn't mean there isn't
one. Maybe you can elaborate a bit about the problem, or
maybe give an example.
> > I was thinking of binding a key during Isearch to move to
> > an occurrence by its match number. `M-g' perhaps. With
> > a numeric prefix arg it would move to that number. With
> > no prefix arg it would prompt for the number (with
> > completion requiring a match against the alist).
>
> I understand that in addition to relative counting like
> 'C-u 42 C-s' would do, you propose absolute counting like
> 'C-s M-g 42 RET'. But a question: shouldn't 'M-g'
> exit the search since it's a global prefix key.
Yes, I was talking about moving to an absolute match
number - what you see in the prompt, not N matches
forward or backward.
I don't really care what key would be used - `M-g' was
just a suggestion.
As you know, I personally don't have a problem with
Isearch co-opting a key that currently ends Isearch,
depending on the key. I have no problem with Isearch
using `M-g' for that (so that if you wanted to stop
Isearch and do `goto-char' you would need to do
`RET M-g c' instead of just `M-g c'.
In what I suggested you could do `C-u 42 M-g' during
Isearch, provided `isearch-allow-prefix' is non-nil.
You could alternatively do `M-g 42 RET' (replying to
a prompt for reading the number), regardless of the
value of `isearch-allow-prefix'.
(BTW, to use your `C-u 42 C-s` during Isearch, wouldn't
option `isearch-allow-prefix' also need to be non-nil?
Or didn't you intend that to be used also during Isearch?)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sat, 10 Nov 2018 14:27:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Mon, 05 Nov 2018 00:59:20 +0200
>
> Here is a new version:
>
> [isearch.count.6.el (344kB)]
Works great here. Thanks for working on this, Juri.
Could we prevent the "0/0" count from showing when searching for an
incomplete regexp? For example, typing characters after C-M-s [
results in the isearch prompt shifting when the "0/0" count is
displayed lazily after each keypress.
Also, the count is shown in the prompt even for "M-e". For example,
C-s buf M-e shows "1/2 I-search:" as the (static) prompt, which is not
necessary (and it may be outdated as soon as the user changes the text
in the minibuffer).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sat, 10 Nov 2018 21:59:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 29321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Could we prevent the "0/0" count from showing when searching for an
> incomplete regexp? For example, typing characters after C-M-s [
> results in the isearch prompt shifting when the "0/0" count is
> displayed lazily after each keypress.
>
> Also, the count is shown in the prompt even for "M-e". For example,
> C-s buf M-e shows "1/2 I-search:" as the (static) prompt, which is not
> necessary (and it may be outdated as soon as the user changes the text
> in the minibuffer).
I agree on both accounts, and fixed this in a new patch that also
includes two new customizable variables lazy-count-prefix-format and
lazy-count-suffix-format:
[isearch.count.7.patch (text/x-diff, inline)]
diff --git a/lisp/isearch.el b/lisp/isearch.el
index 42b3aa42ba..5f75e90387 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -316,6 +316,29 @@ isearch-lazy-highlight
:group 'lazy-highlight
:group 'isearch)
+(defcustom isearch-lazy-count nil
+ "Show match number in the Isearch prompt.
+When both this option and `isearch-lazy-highlight' are non-nil,
+show the current match number and the total number of matches
+in the buffer (or its restriction)."
+ :type 'boolean
+ :group 'isearch
+ :version "27.1")
+
+(defcustom lazy-count-prefix-format "%s/%s "
+ "Format of the current/total number of matches for message prefix."
+ :type '(choice (const :tag "No prefix" nil)
+ (string :tag "Prefix format string" "%s/%s "))
+ :group 'isearch
+ :version "27.1")
+
+(defcustom lazy-count-suffix-format nil
+ "Format of the current/total number of matches for message suffix."
+ :type '(choice (const :tag "No suffix" nil)
+ (string :tag "Suffix format string" " [%s of %s]"))
+ :group 'isearch
+ :version "27.1")
+
;;; Lazy highlight customization.
(defgroup lazy-highlight nil
@@ -2794,7 +2821,8 @@ isearch-message-prefix
(concat " [" current-input-method-title "]: "))
": ")
)))
- (propertize (concat (upcase (substring m 0 1)) (substring m 1))
+ (propertize (concat (isearch-lazy-count-format)
+ (upcase (substring m 0 1)) (substring m 1))
'face 'minibuffer-prompt)))
(defun isearch-message-suffix (&optional c-q-hack)
@@ -2802,9 +2830,33 @@ isearch-message-suffix
(if isearch-error
(concat " [" isearch-error "]")
"")
+ (isearch-lazy-count-format 'suffix)
(or isearch-message-suffix-add ""))
'face 'minibuffer-prompt))
+(defun isearch-lazy-count-format (&optional suffix-p)
+ "Format the current match number and the total number of matches.
+When SUFFIX-P is non-nil, the returned string is indended for
+isearch-message-suffix. Otherwise, for isearch-message-prefix."
+ (let ((format-string (if suffix-p
+ lazy-count-suffix-format
+ lazy-count-prefix-format)))
+ (if (and format-string
+ isearch-lazy-count
+ isearch-lazy-count-current
+ (not isearch-error)
+ (not isearch-suspended))
+ (format format-string
+ (if isearch-forward
+ isearch-lazy-count-current
+ (if (eq isearch-lazy-count-current 0)
+ 0
+ (- isearch-lazy-count-total
+ isearch-lazy-count-current
+ -1)))
+ (or isearch-lazy-count-total "?"))
+ "")))
+
;; Searching
@@ -3202,6 +3254,8 @@ isearch-lazy-highlight-window
(defvar isearch-lazy-highlight-window-group nil)
(defvar isearch-lazy-highlight-window-start nil)
(defvar isearch-lazy-highlight-window-end nil)
+(defvar isearch-lazy-highlight-window-start-changed nil)
+(defvar isearch-lazy-highlight-window-end-changed nil)
(defvar isearch-lazy-highlight-point-min nil)
(defvar isearch-lazy-highlight-point-max nil)
(defvar isearch-lazy-highlight-buffer nil)
@@ -3214,6 +3268,9 @@ 'isearch-lazy-highlight-word
(defvar isearch-lazy-highlight-regexp-function nil)
(defvar isearch-lazy-highlight-forward nil)
(defvar isearch-lazy-highlight-error nil)
+(defvar isearch-lazy-count-current nil)
+(defvar isearch-lazy-count-total nil)
+(defvar isearch-lazy-count-hash (make-hash-table))
(defun lazy-highlight-cleanup (&optional force procrastinate)
"Stop lazy highlighting and remove extra highlighting from current buffer.
@@ -3258,18 +3315,36 @@ isearch-lazy-highlight-new-loop
;; In case we are recovering from an error.
(not (equal isearch-error
isearch-lazy-highlight-error))
- (not (if lazy-highlight-buffer
- (= (point-min)
- isearch-lazy-highlight-point-min)
- (= (window-group-start)
- isearch-lazy-highlight-window-start)))
- (not (if lazy-highlight-buffer
- (= (point-max)
- isearch-lazy-highlight-point-max)
- (= (window-group-end) ; Window may have been split/joined.
- isearch-lazy-highlight-window-end)))))
+ (if lazy-highlight-buffer
+ (not (= (point-min)
+ isearch-lazy-highlight-point-min))
+ (setq isearch-lazy-highlight-window-start-changed
+ (not (= (window-group-start)
+ isearch-lazy-highlight-window-start))))
+ (if lazy-highlight-buffer
+ (not (= (point-max)
+ isearch-lazy-highlight-point-max))
+ (setq isearch-lazy-highlight-window-end-changed
+ (not (= (window-group-end) ; Window may have been split/joined.
+ isearch-lazy-highlight-window-end))))))
;; something important did indeed change
(lazy-highlight-cleanup t (not (equal isearch-string ""))) ;stop old timer
+ (when (and isearch-lazy-count isearch-mode)
+ (when (or (equal isearch-string "")
+ (and (not isearch-lazy-highlight-window-start-changed)
+ (not isearch-lazy-highlight-window-end-changed))
+ (not (= (point-min)
+ isearch-lazy-highlight-point-min))
+ (not (= (point-max)
+ isearch-lazy-highlight-point-max)))
+ ;; Reset old counter before going to count new numbers
+ (clrhash isearch-lazy-count-hash)
+ (setq isearch-lazy-count-current nil
+ isearch-lazy-count-total nil)
+ (when (null isearch-message-function)
+ (isearch-message nil t))))
+ (setq isearch-lazy-highlight-window-start-changed nil)
+ (setq isearch-lazy-highlight-window-end-changed nil)
(setq isearch-lazy-highlight-error isearch-error)
;; It used to check for `(not isearch-error)' here, but actually
;; lazy-highlighting might find matches to highlight even when
@@ -3313,7 +3388,14 @@ isearch-lazy-highlight-new-loop
(unless (equal isearch-string "")
(setq isearch-lazy-highlight-timer
(run-with-idle-timer lazy-highlight-initial-delay nil
- 'isearch-lazy-highlight-start)))))
+ 'isearch-lazy-highlight-start))))
+ (when (and isearch-lazy-count isearch-mode (null isearch-message-function))
+ ;; Update isearch-lazy-count-current only when it was already set
+ ;; at the end of isearch-lazy-highlight-buffer-update
+ (when isearch-lazy-count-current
+ (setq isearch-lazy-count-current
+ (or (gethash (point) isearch-lazy-count-hash) 0))
+ (isearch-message nil t))))
(defun isearch-lazy-highlight-search (string bound)
"Search ahead for the next or previous match, for lazy highlighting.
@@ -3434,7 +3516,8 @@ isearch-lazy-highlight-update
(goto-char (min (or isearch-lazy-highlight-end-limit (point-max))
window-end)))))))
(if nomore
- (when isearch-lazy-highlight-buffer
+ (when (or isearch-lazy-highlight-buffer
+ (and isearch-lazy-count (null isearch-lazy-count-current)))
(if isearch-lazy-highlight-forward
(setq isearch-lazy-highlight-end (point-min))
(setq isearch-lazy-highlight-start (point-max)))
@@ -3448,7 +3531,8 @@ isearch-lazy-highlight-buffer-update
"Update highlighting of other matches in the full buffer."
(let ((max lazy-highlight-buffer-max-at-a-time)
(looping t)
- nomore window-start window-end)
+ nomore window-start window-end
+ (opoint (point)))
(with-local-quit
(save-selected-window
(if (and (window-live-p isearch-lazy-highlight-window)
@@ -3483,8 +3567,14 @@ isearch-lazy-highlight-buffer-update
(if (= mb (point-min))
(setq found nil)
(forward-char -1)))
+ (when isearch-lazy-count
+ (setq isearch-lazy-count-total (1+ (or isearch-lazy-count-total 0)))
+ (puthash (if isearch-lazy-highlight-forward me mb)
+ isearch-lazy-count-total
+ isearch-lazy-count-hash))
;; Already highlighted by isearch-lazy-highlight-update
- (unless (and (>= mb window-start) (<= me window-end))
+ (unless (or (not isearch-lazy-highlight-buffer)
+ (and (>= mb window-start) (<= me window-end)))
;; non-zero-length match
(isearch-lazy-highlight-match mb me)))
;; Remember the current position of point for
@@ -3498,7 +3588,13 @@ isearch-lazy-highlight-buffer-update
(if (not found)
(setq looping nil
nomore t))))
- (unless nomore
+ (if nomore
+ (when (and isearch-lazy-count isearch-mode (null isearch-message-function))
+ (unless isearch-lazy-count-total
+ (setq isearch-lazy-count-total 0))
+ (setq isearch-lazy-count-current
+ (or (gethash opoint isearch-lazy-count-hash) 0))
+ (isearch-message nil t))
(setq isearch-lazy-highlight-timer
(run-at-time lazy-highlight-interval nil
'isearch-lazy-highlight-buffer-update)))))))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 11 Nov 2018 09:49:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Sat, 10 Nov 2018 22:45:35 +0200
>
> I agree on both accounts, and fixed this in a new patch that also
> includes two new customizable variables lazy-count-prefix-format and
> lazy-count-suffix-format:
Thanks, this works well.
Should the variables lazy-count-prefix-format and
lazy-count-suffix-format be prefixed with "isearch-"? If we will have
a customizable option isearch-lazy-count, it would make sense to have
these two variables share the same prefix. They would not match the
other existing "lazy-" prefixed defcustoms, but hopefully we can amend
those in a future change to gain the same prefix ("isearch-").
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sun, 11 Nov 2018 20:29:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> Should the variables lazy-count-prefix-format and
> lazy-count-suffix-format be prefixed with "isearch-"? If we will have
> a customizable option isearch-lazy-count, it would make sense to have
> these two variables share the same prefix. They would not match the
> other existing "lazy-" prefixed defcustoms, but hopefully we can amend
> those in a future change to gain the same prefix ("isearch-").
These variables have no prefix isearch- because I thought that maybe later
the same variables could be shared to define the same format in the search
prompt for other search types like the search in the minibuffer history
where counting matches in the minibuffer history would require
an implementation different from counting matches in a regular buffer.
This could reuse the same format variables, but should allow enabling
and disabling counting with a variable other than isearch-lazy-count,
with a name like minibuffer-history-isearch-lazy-count.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Tue, 13 Nov 2018 21:50:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 29321 <at> debbugs.gnu.org (full text, mbox):
FYI: I was able to update my library (isearch+.el) to
incorporate the match # in message prefix finally.
Your last patch did the trick. The previous patch
made things worse after I applied it, for some reason.
(Possibly I made a mistake.)
Thanks for working on this, and on the full-buffer
lazy highlighting.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Wed, 14 Nov 2018 22:40:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 29321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Isearch could show in the mode line how many matches follow or precede
> the currently highlighted one (or we could write "3 of 4 matches", as,
> e.g., Firefox does). For big files, it could be helpful to calculate
> this information either lazily or in another thread.
Lazy-counting is now pushed to master.
> If we had this, it would also be convenient to say "go forward n
> matches", so that typing "M-3 C-s" during a search would be the
> equivalent of typing C-s three times. To do this we could add numeric
> prefix arg handling to C-s/C-r/C-M-s/C-M-r, if that isn't already
> taken for some other behavior.
Adding a numeric prefix arg to C-s/C-r is implemented in
https://debbugs.gnu.org/29321#86
But this implementation causes flicker because it updates
isearch highlighting on every search hit while traversing
all found matches COUNT times until it reaches COUNT-th match.
Attached is a better approach that adds the COUNT arg to
isearch functions down to the lowest-level isearch function,
thus making it compatible with the COUNT arg of re-search-forward:
[isearch-repeat-count.2.patch (text/x-diff, inline)]
diff --git a/lisp/isearch.el b/lisp/isearch.el
index 035ff69327..3e6e696a74 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -1547,7 +1547,7 @@ isearch-abort
(isearch-pop-state))
(isearch-update)))
-(defun isearch-repeat (direction)
+(defun isearch-repeat (direction &optional count)
;; Utility for isearch-repeat-forward and -backward.
(if (eq isearch-forward (eq direction 'forward))
;; C-s in forward or C-r in reverse.
@@ -1590,21 +1590,29 @@ isearch-repeat
(setq isearch-success nil)
(ding))
(forward-char (if isearch-forward 1 -1))
- (isearch-search))
- (isearch-search)))
+ (isearch-search count))
+ (isearch-search count)))
(isearch-push-state)
(isearch-update))
-(defun isearch-repeat-forward ()
- "Repeat incremental search forwards."
- (interactive)
- (isearch-repeat 'forward))
-
-(defun isearch-repeat-backward ()
- "Repeat incremental search backwards."
- (interactive)
- (isearch-repeat 'backward))
+(defun isearch-repeat-forward (&optional arg)
+ "Repeat incremental search forwards.
+With a prefix argument, repeat a search ARG times."
+ (interactive "P")
+ (let ((count (and arg (abs (prefix-numeric-value arg)))))
+ ;; Take into account one search iteration to reverse direction.
+ (when (and count (not isearch-forward)) (setq count (1+ count)))
+ (isearch-repeat 'forward count)))
+
+(defun isearch-repeat-backward (&optional arg)
+ "Repeat incremental search backwards.
+With a prefix argument, repeat a search ARG times."
+ (interactive "P")
+ (let ((count (and arg (abs (prefix-numeric-value arg)))))
+ ;; Take into account one search iteration to reverse direction.
+ (when (and count isearch-forward) (setq count (1+ count)))
+ (isearch-repeat 'backward count)))
;;; Toggles for `isearch-regexp-function' and `search-default-mode'.
@@ -2910,7 +2918,7 @@ isearch-search-fun-default
(t (regexp-quote string)))
bound noerror count))))
-(defun isearch-search-string (string bound noerror)
+(defun isearch-search-string (string bound noerror &optional count)
"Search for the first occurrence of STRING or its translation.
STRING's characters are translated using `translation-table-for-input'
if that is non-nil.
@@ -2921,7 +2929,10 @@ isearch-search-string
Optional third argument, if t, means if fail just return nil (no error).
If not nil and not t, move to limit of search and return nil."
(let* ((func (isearch-search-fun))
- (pos1 (save-excursion (funcall func string bound noerror)))
+ (pos1 (save-excursion (if count
+ (funcall func string bound noerror count)
+ ;; Backward-compatibility for functions that don't support count arg
+ (funcall func string bound noerror))))
pos2)
(when (and
;; Avoid "obsolete" warnings for translation-table-for-input.
@@ -2960,7 +2971,7 @@ isearch-search-string
(goto-char pos1)
pos1)))
-(defun isearch-search ()
+(defun isearch-search (&optional count)
;; Do the search with the current search string.
(if (and (eq isearch-case-fold-search t) search-upper-case)
(setq isearch-case-fold-search
@@ -2974,7 +2985,7 @@ isearch-search
(setq isearch-error nil)
(while retry
(setq isearch-success
- (isearch-search-string isearch-string nil t))
+ (isearch-search-string isearch-string nil t count))
;; Clear RETRY unless the search predicate says
;; to skip this search hit.
(if (or (not isearch-success)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Thu, 15 Nov 2018 08:04:01 GMT)
Full text and
rfc822 format available.
Message #131 received at submit <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> Isearch could show in the mode line how many matches follow or precede
>> the currently highlighted one (or we could write "3 of 4 matches", as,
>> e.g., Firefox does). For big files, it could be helpful to calculate
>> this information either lazily or in another thread.
>
> Lazy-counting is now pushed to master.
>
>> If we had this, it would also be convenient to say "go forward n
>> matches", so that typing "M-3 C-s" during a search would be the
>> equivalent of typing C-s three times. To do this we could add numeric
>> prefix arg handling to C-s/C-r/C-M-s/C-M-r, if that isn't already
>> taken for some other behavior.
>
> Adding a numeric prefix arg to C-s/C-r is implemented in
> https://debbugs.gnu.org/29321#86
Thanks!
>
> But this implementation causes flicker because it updates
> isearch highlighting on every search hit while traversing
> all found matches COUNT times until it reaches COUNT-th match.
>
> Attached is a better approach that adds the COUNT arg to
> isearch functions down to the lowest-level isearch function,
> thus making it compatible with the COUNT arg of re-search-forward:
Unfortunately, this patch (below) had errrs for me:
0. emacs -Q &
1. M-: (setq isearch-lazy-count t)
2. M-x load-file RET isearch-new.el RET
3. C-x C-r isearch-new.el
I then search for the string "-count" ...
4. C-s -c
...and in the echo area I see:
0/0 I-search: -c [(void-variable +)]
The cursor doesn't move and no matches are not highlighted nor
is there a "Failing I-search" " meassage.
Thanks.
>
> diff --git a/lisp/isearch.el b/lisp/isearch.el
> index 035ff69327..3e6e696a74 100644
> --- a/lisp/isearch.el
> +++ b/lisp/isearch.el
> @@ -1547,7 +1547,7 @@ isearch-abort
> (isearch-pop-state))
> (isearch-update)))
>
> -(defun isearch-repeat (direction)
> +(defun isearch-repeat (direction &optional count)
> ;; Utility for isearch-repeat-forward and -backward.
> (if (eq isearch-forward (eq direction 'forward))
> ;; C-s in forward or C-r in reverse.
> @@ -1590,21 +1590,29 @@ isearch-repeat
> (setq isearch-success nil)
> (ding))
> (forward-char (if isearch-forward 1 -1))
> - (isearch-search))
> - (isearch-search)))
> + (isearch-search count))
> + (isearch-search count)))
>
> (isearch-push-state)
> (isearch-update))
>
> -(defun isearch-repeat-forward ()
> - "Repeat incremental search forwards."
> - (interactive)
> - (isearch-repeat 'forward))
> -
> -(defun isearch-repeat-backward ()
> - "Repeat incremental search backwards."
> - (interactive)
> - (isearch-repeat 'backward))
> +(defun isearch-repeat-forward (&optional arg)
> + "Repeat incremental search forwards.
> +With a prefix argument, repeat a search ARG times."
> + (interactive "P")
> + (let ((count (and arg (abs (prefix-numeric-value arg)))))
> + ;; Take into account one search iteration to reverse direction.
> + (when (and count (not isearch-forward)) (setq count (1+ count)))
> + (isearch-repeat 'forward count)))
> +
> +(defun isearch-repeat-backward (&optional arg)
> + "Repeat incremental search backwards.
> +With a prefix argument, repeat a search ARG times."
> + (interactive "P")
> + (let ((count (and arg (abs (prefix-numeric-value arg)))))
> + ;; Take into account one search iteration to reverse direction.
> + (when (and count isearch-forward) (setq count (1+ count)))
> + (isearch-repeat 'backward count)))
>
>
> ;;; Toggles for `isearch-regexp-function' and `search-default-mode'.
> @@ -2910,7 +2918,7 @@ isearch-search-fun-default
> (t (regexp-quote string)))
> bound noerror count))))
>
> -(defun isearch-search-string (string bound noerror)
> +(defun isearch-search-string (string bound noerror &optional count)
> "Search for the first occurrence of STRING or its translation.
> STRING's characters are translated using `translation-table-for-input'
> if that is non-nil.
> @@ -2921,7 +2929,10 @@ isearch-search-string
> Optional third argument, if t, means if fail just return nil (no error).
> If not nil and not t, move to limit of search and return nil."
> (let* ((func (isearch-search-fun))
> - (pos1 (save-excursion (funcall func string bound noerror)))
> + (pos1 (save-excursion (if count
> + (funcall func string bound noerror count)
> + ;; Backward-compatibility for functions that don't support count arg
> + (funcall func string bound noerror))))
> pos2)
> (when (and
> ;; Avoid "obsolete" warnings for translation-table-for-input.
> @@ -2960,7 +2971,7 @@ isearch-search-string
> (goto-char pos1)
> pos1)))
>
> -(defun isearch-search ()
> +(defun isearch-search (&optional count)
> ;; Do the search with the current search string.
> (if (and (eq isearch-case-fold-search t) search-upper-case)
> (setq isearch-case-fold-search
> @@ -2974,7 +2985,7 @@ isearch-search
> (setq isearch-error nil)
> (while retry
> (setq isearch-success
> - (isearch-search-string isearch-string nil t))
> + (isearch-search-string isearch-string nil t count))
> ;; Clear RETRY unless the search predicate says
> ;; to skip this search hit.
> (if (or (not isearch-success)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Thu, 15 Nov 2018 21:15:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Thu, 15 Nov 2018 00:36:37 +0200
>
> Lazy-counting is now pushed to master.
Great!
> Adding a numeric prefix arg to C-s/C-r is implemented in
> https://debbugs.gnu.org/29321#86
>
> But this implementation causes flicker because it updates
> isearch highlighting on every search hit while traversing
> all found matches COUNT times until it reaches COUNT-th match.
>
> Attached is a better approach that adds the COUNT arg to
> isearch functions down to the lowest-level isearch function,
> thus making it compatible with the COUNT arg of re-search-forward:
Thanks.
Do you think adding similar behavior to
"isearch-forward"/"isearch-backward" would be feasible? For example,
C-6 C-s foo could move point forward to the sixth next occurrence of
"foo".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Thu, 15 Nov 2018 21:53:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 29321 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> But this implementation causes flicker because it updates
>> isearch highlighting on every search hit while traversing
>> all found matches COUNT times until it reaches COUNT-th match.
>>
>> Attached is a better approach that adds the COUNT arg to
>> isearch functions down to the lowest-level isearch function,
>> thus making it compatible with the COUNT arg of re-search-forward:
>
> Unfortunately, this patch (below) had errrs for me:
>
> ...and in the echo area I see:
>
> 0/0 I-search: -c [(void-variable +)]
It seems this `+' comes from the diff indicator from the
beginning of the diff line from failed patching.
So I attached a whole new file isearch-repeat.3.el
for your convenience.
But please note that it contains a new implementation
because I found problems in the previous implementation:
when COUNT is added to low-level isearch functions then
they don't skip filtered-out matches.
So a better place is in isearch-search after
`funcall isearch-filter-predicate'. But the problem
is that when (= (match-beginning 0) (match-end 0))
then it doesn't move point one character forward like
isearch-repeat does. So the right place to use COUNT is in
isearch-repeat.
Please try a new implementation:
[isearch-repeat.3.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Thu, 15 Nov 2018 21:59:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> Do you think adding similar behavior to
> "isearch-forward"/"isearch-backward" would be feasible? For example,
> C-6 C-s foo could move point forward to the sixth next occurrence of
> "foo".
It's unclear how it should progress incrementally. After starting
to type `C-6 C-s f' it can find the sixth next occurrence of "f".
To find the sixth next occurrence of "foo", it needs to search
non-incrementally.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Fri, 16 Nov 2018 20:02:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Thu, 15 Nov 2018 23:58:21 +0200
>
> It's unclear how it should progress incrementally. After starting
> to type `C-6 C-s f' it can find the sixth next occurrence of "f".
> To find the sixth next occurrence of "foo", it needs to search
> non-incrementally.
In what sense non-incrementally? It would still do the same job as
normal Isearch, after skipping the first 5 results.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sat, 17 Nov 2018 22:02:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 29321 <at> debbugs.gnu.org (full text, mbox):
>> It's unclear how it should progress incrementally. After starting
>> to type `C-6 C-s f' it can find the sixth next occurrence of "f".
>> To find the sixth next occurrence of "foo", it needs to search
>> non-incrementally.
>
> In what sense non-incrementally? It would still do the same job as
> normal Isearch, after skipping the first 5 results.
To find the sixth occurrence of "foo", "foo" should be already
in the current search string before typing `C-6 C-s'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Tue, 20 Nov 2018 23:47:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> But please note that it contains a new implementation
> because I found problems in the previous implementation:
> when COUNT is added to low-level isearch functions then
> they don't skip filtered-out matches.
>
> So a better place is in isearch-search after
> `funcall isearch-filter-predicate'. But the problem
> is that when (= (match-beginning 0) (match-end 0))
> then it doesn't move point one character forward like
> isearch-repeat does. So the right place to use COUNT is in
> isearch-repeat.
>
> Please try a new implementation:
Now this is pushed to master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Tue, 20 Nov 2018 23:54:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> Do you think adding similar behavior to
> "isearch-forward"/"isearch-backward" would be feasible? For example,
> C-6 C-s foo could move point forward to the sixth next occurrence of
> "foo".
Now that isearch-repeat-forward supports a prefix arg, it's easy to do
this for isearch-forward-symbol-at-point with a small patch below.
This allows a trivial implementation of corresponding
Vi-like keybindings. I don't like Vi-keybindings, but here's
the implementation for anyone who likes Vi-keybindings:
(defun isearch-forward-search-symbol-at-point (&optional count)
(interactive "p")
(isearch-forward-symbol-at-point (or count 1)))
(define-key search-map "*" 'isearch-forward-search-symbol-at-point)
(defun isearch-backward-search-symbol-at-point (&optional count)
(interactive "p")
(isearch-forward-symbol-at-point (- (or count 1))))
(define-key search-map "#" 'isearch-backward-search-symbol-at-point)
Here's the patch that adds a prefix arg:
diff --git a/lisp/isearch.el b/lisp/isearch.el
index 6d94ef6693..78c4d7b275 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -887,21 +887,26 @@ isearch-backward-regexp
(interactive "P\np")
(isearch-mode nil (null not-regexp) nil (not no-recursive-edit)))
-(defun isearch-forward-symbol-at-point ()
+(defun isearch-forward-symbol-at-point (&optional arg)
"Do incremental search forward for a symbol found near point.
Like ordinary incremental search except that the symbol found at point
is added to the search string initially as a regexp surrounded
by symbol boundary constructs \\_< and \\_>.
-See the command `isearch-forward-symbol' for more information."
- (interactive)
+See the command `isearch-forward-symbol' for more information.
+With a prefix argument, search for ARGth symbol forward if ARG is
+positive, or search for ARGth symbol backward if ARG is negative."
+ (interactive "P")
(isearch-forward-symbol nil 1)
- (let ((bounds (find-tag-default-bounds)))
+ (let ((bounds (find-tag-default-bounds))
+ (count (and arg (prefix-numeric-value arg))))
(cond
(bounds
(when (< (car bounds) (point))
(goto-char (car bounds)))
(isearch-yank-string
- (buffer-substring-no-properties (car bounds) (cdr bounds))))
+ (buffer-substring-no-properties (car bounds) (cdr bounds)))
+ (when count
+ (isearch-repeat-forward count)))
(t
(setq isearch-error "No symbol at point")
(isearch-push-state)
Reply sent
to
Juri Linkov <juri <at> linkov.net>:
You have taken responsibility.
(Thu, 22 Nov 2018 22:05:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
charles <at> aurox.ch (Charles A. Roelli):
bug acknowledged by developer.
(Thu, 22 Nov 2018 22:05:02 GMT)
Full text and
rfc822 format available.
Message #157 received at 29321-done <at> debbugs.gnu.org (full text, mbox):
>> where in isearch-mode 'M-s M-<' will jump to the first match,
>> and 'M-s M->' will jump to the last match.
>
> Perfect! with an excellent choice of keybindings!
>
> Thanks!
This is pushed to master as well, and since everything is implemented,
I'm closing this as done.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#29321; Package
emacs.
(Sat, 24 Nov 2018 12:54:02 GMT)
Full text and
rfc822 format available.
Message #160 received at 29321 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Fri, 23 Nov 2018 00:03:25 +0200
>
> >> where in isearch-mode 'M-s M-<' will jump to the first match,
> >> and 'M-s M->' will jump to the last match.
> >
> > Perfect! with an excellent choice of keybindings!
> >
> > Thanks!
>
> This is pushed to master as well, and since everything is implemented,
> I'm closing this as done.
Thanks, this is great!
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 23 Dec 2018 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 328 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.