bug#25562: 25.1; isearch-forward-word first matches a non-word

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Antoine Levitt]

emacs -Q
M-<
M-s w
it

see that the "it" of "visit" is matched, and should not be. Subsequent
C-s fix this.

Best,
Antoine

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Juri Linkov]

merge 22589 25562
thanks

> emacs -Q
> M-<
> M-s w
> it
>
> see that the "it" of "visit" is matched, and should not be. Subsequent
> C-s fix this.

Thanks for the report.  Please see the rationale for this behavior in
https://debbugs.gnu.org/22589

Do you think the proposed change suits your case?

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Antoine Levitt]

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

I see, thanks for the explanation. That's still unsatisfactory to me. I
think an ideal incremental word search would just start over from the
current point each time a new character is typed (that's what most users
would expect). Then any non-insertion command would make the user "commit"
to the particular search and the incremental search proper would begin. Is
that compatible with the current design of isearch?

Best,
Antoine

On 29 Jan 2017 01:50, "Juri Linkov" <juri@linkov.net> wrote:

> merge 22589 25562
> thanks
>
> > emacs -Q
> > M-<
> > M-s w
> > it
> >
> > see that the "it" of "visit" is matched, and should not be. Subsequent
> > C-s fix this.
>
> Thanks for the report.  Please see the rationale for this behavior in
> https://debbugs.gnu.org/22589
>
> Do you think the proposed change suits your case?
>

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

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Juri Linkov]

> I see, thanks for the explanation. That's still unsatisfactory to me. I
> think an ideal incremental word search would just start over from the
> current point each time a new character is typed (that's what most users
> would expect). Then any non-insertion command would make the user "commit"
> to the particular search and the incremental search proper would begin. Is
> that compatible with the current design of isearch?

What you describe looks like isearch-barrier used for subsequent \| in regexps,
e.g. typing ‘C-M-s ^\<it\>’ and then ‘\|’ moves point back to the beginning
of the search.  But wouldn't this make the search too “jumpy”, especially
while typing long words?

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Antoine Levitt]

30 January 2017 01:30 +0100, Juri Linkov <juri@linkov.net>:
>> I see, thanks for the explanation. That's still unsatisfactory to me. I
>> think an ideal incremental word search would just start over from the
>> current point each time a new character is typed (that's what most users
>> would expect). Then any non-insertion command would make the user "commit"
>> to the particular search and the incremental search proper would begin. Is
>> that compatible with the current design of isearch?
>
> What you describe looks like isearch-barrier used for subsequent \| in regexps,
> e.g. typing ‘C-M-s ^\<it\>’ and then ‘\|’ moves point back to the beginning
> of the search.  But wouldn't this make the search too “jumpy”, especially
> while typing long words?

My use case of isearch-word is mainly short words, e.g. variable names
such as f in f(x) in latex. I'd guess that's a pretty common pattern.
Even for long words, I think an user would type a word quickly, and be
confused that their first match is not really a match. That offsets the
potential jumpiness (ie what happens when the user is typing the word)
for me.

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Juri Linkov]

>>> I see, thanks for the explanation. That's still unsatisfactory to me. I
>>> think an ideal incremental word search would just start over from the
>>> current point each time a new character is typed (that's what most users
>>> would expect). Then any non-insertion command would make the user "commit"
>>> to the particular search and the incremental search proper would begin. Is
>>> that compatible with the current design of isearch?
>>
>> What you describe looks like isearch-barrier used for subsequent \| in regexps,
>> e.g. typing ‘C-M-s ^\<it\>’ and then ‘\|’ moves point back to the beginning
>> of the search.  But wouldn't this make the search too “jumpy”, especially
>> while typing long words?
>
> My use case of isearch-word is mainly short words, e.g. variable names
> such as f in f(x) in latex. I'd guess that's a pretty common pattern.
> Even for long words, I think an user would type a word quickly, and be
> confused that their first match is not really a match. That offsets the
> potential jumpiness (ie what happens when the user is typing the word)
> for me.

You can try yourself using the minimal patch below that demonstrates your idea.

But from what I see, it's not too good, using the recipe from your top post:

emacs -Q
M-<
M-s w
i

After typing the letter “i”, isearch fails, beeps, flashes the screen,
with a clear indication that something went wrong.  This is more confusing
for a user, because now a user has to stop and think about what is wrong.

Here is the patch to help seeing this in action:

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 5c48c30..85b9365 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -1616,6 +1616,7 @@ (defun word-search-regexp (string &optional lax)
 
 Used in `word-search-forward', `word-search-backward',
 `word-search-forward-lax', `word-search-backward-lax'."
+  (setq lax nil)
   (cond
    ((equal string "") "")
    ((string-match-p "\\`\\W+\\'" string) "\\W+")
@@ -2465,6 +2466,11 @@ (defun isearch-process-search-char (char &optional count)
   ;; } and | are special in regexps when preceded by \.
   ;; Nothing special for + because it matches at least once.
   (cond
+   ((eq isearch-regexp-function t)
+    (goto-char isearch-barrier)
+    (setq isearch-other-end isearch-barrier
+          isearch-success t
+          isearch-error nil))
    ((memq char '(?* ??)) (isearch-fallback nil))
    ((eq   char ?\})      (isearch-fallback t t))
    ((eq   char ?|)       (isearch-fallback t nil t)))

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 31 Jan 2017 01:24:07 +0200
> Cc: 25562@debbugs.gnu.org
> 
> You can try yourself using the minimal patch below that demonstrates your idea.
> 
> But from what I see, it's not too good, using the recipe from your top post:
> 
> emacs -Q
> M-<
> M-s w
> i
> 
> After typing the letter “i”, isearch fails, beeps, flashes the screen,
> with a clear indication that something went wrong.  This is more confusing
> for a user, because now a user has to stop and think about what is wrong.

I think this is a consequence of the simple fact that "word search"
and "incremental search" contradict each other: as long as "the word"
was not fully specified, searching for it incrementally is not a
well-defined operation.

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Antoine Levitt]

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

I agree it's an ill defined problem ; but then, so is isearching for
foo\|bar.

I disabled the beeping and screen flashing, so it doesn't bother me, but I
get the point.

In the end, it's mostly a matter of personal convenience. The patched
behavior suits me better, and seems more consistent with the way regexp are
handled.

Best,
Antoine


On 31 Jan 2017 04:29, "Eli Zaretskii" <eliz@gnu.org> wrote:

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 31 Jan 2017 01:24:07 +0200
> Cc: 25562@debbugs.gnu.org
>
> You can try yourself using the minimal patch below that demonstrates your
idea.
>
> But from what I see, it's not too good, using the recipe from your top
post:
>
> emacs -Q
> M-<
> M-s w
> i
>
> After typing the letter “i”, isearch fails, beeps, flashes the screen,
> with a clear indication that something went wrong.  This is more confusing
> for a user, because now a user has to stop and think about what is wrong.

I think this is a consequence of the simple fact that "word search"
and "incremental search" contradict each other: as long as "the word"
was not fully specified, searching for it incrementally is not a
well-defined operation.

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

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Eli Zaretskii]

> From: Antoine Levitt <antoine.levitt@gmail.com>
> Date: Tue, 31 Jan 2017 08:57:37 +0100
> Cc: Juri Linkov <juri@linkov.net>, 25562@debbugs.gnu.org
> 
> I agree it's an ill defined problem ; but then, so is isearching for foo\|bar.
> 
> I disabled the beeping and screen flashing, so it doesn't bother me, but I get the point. 
> 
> In the end, it's mostly a matter of personal convenience. The patched behavior suits me better, and seems
> more consistent with the way regexp are handled.

Did you try typing RET right after "C-s M-s w", then typing the word
to search, and then typing "C-s C-s" again to repeat that?  This might
be better suited to your needs, I think, and it doesn't require any
changes.

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Juri Linkov]

>> I agree it's an ill defined problem ; but then, so is isearching for foo\|bar.
>>
>> I disabled the beeping and screen flashing, so it doesn't bother me, but I get the point.
>>
>> In the end, it's mostly a matter of personal convenience. The patched behavior suits me better, and seems
>> more consistent with the way regexp are handled.
>
> Did you try typing RET right after "C-s M-s w", then typing the word
> to search, and then typing "C-s C-s" again to repeat that?  This might
> be better suited to your needs, I think, and it doesn't require any
> changes.

Since incrementality of word search is not well-defined,
it makes sense to type the word in non-incremental mode indeed.

One problem I noticed is that it's not easy to get back to incremental
mode: after typing a word in non-incremental mode ‘M-s w RET it’
typing ‘C-s’ in the minibuffer doesn't go back to incremental mode.
Also ‘C-s C-s’ doesn't reuse the previous word search.
We need to fix this.

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Juri Linkov]

>>> I agree it's an ill defined problem ; but then, so is isearching for foo\|bar.
>>>
>>> I disabled the beeping and screen flashing, so it doesn't bother me, but I get the point.
>>>
>>> In the end, it's mostly a matter of personal convenience. The patched behavior suits me better, and seems
>>> more consistent with the way regexp are handled.
>>
>> Did you try typing RET right after "C-s M-s w", then typing the word
>> to search, and then typing "C-s C-s" again to repeat that?  This might
>> be better suited to your needs, I think, and it doesn't require any
>> changes.
>
> Since incrementality of word search is not well-defined,
> it makes sense to type the word in non-incremental mode indeed.
>
> One problem I noticed is that it's not easy to get back to incremental
> mode: after typing a word in non-incremental mode ‘M-s w RET it’
> typing ‘C-s’ in the minibuffer doesn't go back to incremental mode.

IIRC, it was supposed to work this way, i.e.:

‘M-s w RET it RET’ to quit isearch and search the word nonincrementally,
as documented in (info "(emacs) Word Search")

‘M-s w RET it C-s’ to enter the word and continue searching incrementally,
as documented in the docstrings of ‘isearch-forward-exit-minibuffer’ and
‘isearch-reverse-exit-minibuffer’, but at some point the implementation
deviated from its documentation.  Here is the patch to restore it:

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 4b35f25..23ca18c 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -638,6 +638,9 @@ (defvar isearch-recursive-edit nil)
 ;; Should isearch be terminated after doing one search?
 (defvar isearch-nonincremental nil)
 
+;; New value of isearch-nonincremental after isearch-edit-string.
+(defvar isearch-new-nonincremental nil)
+
 ;; New value of isearch-forward after isearch-edit-string.
 (defvar isearch-new-forward nil)
 
@@ -1228,7 +1231,7 @@ (defmacro with-isearch-suspended (&rest body)
   "Exit Isearch mode, run BODY, and reinvoke the pending search.
 You can update the global isearch variables by setting new values to
 `isearch-new-string', `isearch-new-message', `isearch-new-forward',
-`isearch-new-regexp-function', `isearch-new-case-fold'."
+`isearch-new-nonincremental', `isearch-new-regexp-function', `isearch-new-case-fold'."
   ;; This code is very hairy for several reasons, explained in the code.
   ;; Mainly, isearch-mode must be terminated while editing and then restarted.
   ;; If there were a way to catch any change of buffer from the minibuffer,
@@ -1236,7 +1239,7 @@ (defmacro with-isearch-suspended (&rest body)
   ;; Editing doesn't back up the search point.  Should it?
   `(condition-case nil
       (progn
-	(let ((isearch-nonincremental isearch-nonincremental)
+	(let ((isearch-new-nonincremental isearch-nonincremental)
 
 	      ;; Locally bind all isearch global variables to protect them
 	      ;; from recursive isearching.
@@ -1315,6 +1318,7 @@ (defmacro with-isearch-suspended (&rest body)
 	    (setq isearch-string isearch-new-string
 		  isearch-message isearch-new-message
 		  isearch-forward isearch-new-forward
+		  isearch-nonincremental isearch-new-nonincremental
 		  isearch-regexp-function isearch-new-regexp-function
 		  isearch-case-fold-search isearch-new-case-fold
 		  multi-isearch-current-buffer multi-isearch-current-buffer-new
@@ -1405,22 +1409,22 @@ (defun isearch-edit-string ()
 
 (defun isearch-nonincremental-exit-minibuffer ()
   (interactive)
-  (setq isearch-nonincremental t)
+  (setq isearch-new-nonincremental t)
   (exit-minibuffer))
-;; Changing the value of `isearch-nonincremental' has no effect here,
-;; because `isearch-edit-string' ignores this change.  Thus marked as obsolete.
+;; It makes no sense to change the value of `isearch-new-nonincremental'
+;; from nil to t during `isearch-edit-string'.   Thus marked as obsolete.
 (make-obsolete 'isearch-nonincremental-exit-minibuffer 'exit-minibuffer "24.4")
 
 (defun isearch-forward-exit-minibuffer ()
   "Resume isearching forward from the minibuffer that edits the search string."
   (interactive)
-  (setq isearch-new-forward t)
+  (setq isearch-new-forward t isearch-new-nonincremental nil)
   (exit-minibuffer))
 
 (defun isearch-reverse-exit-minibuffer ()
   "Resume isearching backward from the minibuffer that edits the search string."
   (interactive)
-  (setq isearch-new-forward nil)
+  (setq isearch-new-forward nil isearch-new-nonincremental nil)
   (exit-minibuffer))
 

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Juri Linkov]

> IIRC, it was supposed to work this way, i.e.:
>
> ‘M-s w RET it RET’ to quit isearch and search the word nonincrementally,
> as documented in (info "(emacs) Word Search")
>
> ‘M-s w RET it C-s’ to enter the word and continue searching incrementally,
> as documented in the docstrings of ‘isearch-forward-exit-minibuffer’ and
> ‘isearch-reverse-exit-minibuffer’, but at some point the implementation
> deviated from its documentation.  Here is the patch to restore it:

Installed as well.  I guess updating NEWS is not needed because
it already used to work this way some time ago, and the Emacs manual
mentions this feature in several places, e.g. in ‘(emacs) Repeat Isearch’:
“Type <RET>, `C-s' or `C-r' to finish editing the string and search for it.”

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Michael Heerdegen]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> I see, thanks for the explanation. That's still unsatisfactory to
> me. I think an ideal incremental word search would just start over
> from the current point each time a new character is typed (that's what
> most users would expect).

It's what I had expected, too.  But after I had tried it, I changed my
mind.  AFAIR I was especially annoyed that i could not anymore use C-w
to extend the search string because isearch did not go to partial
matches any more.


Michael.

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> merge 22589 25562
> thanks

AFAIK you didn't yet make the change so that the lax matching state is
recognizable from the prompt.  No hurry, but I think this report shows
that the current behavior is at first surprising to users.  Maybe even a
stronger term than your suggested "Pending" would be appropriate.


Thanks,

Michael.

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Juri Linkov]

>> merge 22589 25562
>> thanks
>
> AFAIK you didn't yet make the change so that the lax matching state is
> recognizable from the prompt.  No hurry, but I think this report shows
> that the current behavior is at first surprising to users.  Maybe even a
> stronger term than your suggested "Pending" would be appropriate.

Thanks for confirming that it would be a good solution.
We are already using "Pending" indication in the search prompt
in other places to show that the search is not yet fully accepted.
This could do the same for word search as well:

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 5c48c30..3c9dff1 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -2741,6 +2747,8 @@ (defun isearch-search-fun-default ()
            (if isearch-forward #'re-search-forward #'re-search-backward)
            (cond (isearch-regexp-function
                   (let ((lax (isearch--lax-regexp-function-p)))
+                    (when lax
+                      (setq isearch-adjusted t))
                     (if (functionp isearch-regexp-function)
                         (funcall isearch-regexp-function string lax)
                       (word-search-regexp string lax))))

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Thanks for confirming that it would be a good solution.  We are
> already using "Pending" indication in the search prompt in other
> places to show that the search is not yet fully accepted.

Ok, then let's just do this.

> This could do the same for word search as well:
>
> diff --git a/lisp/isearch.el b/lisp/isearch.el
> index 5c48c30..3c9dff1 100644
> --- a/lisp/isearch.el
> +++ b/lisp/isearch.el
> @@ -2741,6 +2747,8 @@ (defun isearch-search-fun-default ()
>             (if isearch-forward #'re-search-forward #'re-search-backward)
>             (cond (isearch-regexp-function
>                    (let ((lax (isearch--lax-regexp-function-p)))
> +                    (when lax
> +                      (setq isearch-adjusted t))
>                      (if (functionp isearch-regexp-function)
>                          (funcall isearch-regexp-function string lax)
>                        (word-search-regexp string lax))))

I tried it.  Works as I would expect in *scratch* and dired, but hmm,
not in Info (the prompt just doesn't contain "pending" there).  I tried
with emacs -Q, and in any buffer I started a word search and just began
typing characters.


BTW, a different question: when I delete characters from my input (with
backspace) in a word search and then add some new characters, I somehow
expected that isearch would return to that "pending" state.  But I got
the jumpy (nonlax) incremental search behavior instead.  I don't have an
opinion about that, just wanted to mention it.


Regards,

Michael.

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Juri Linkov]

> I tried it.  Works as I would expect in *scratch* and dired, but hmm,
> not in Info (the prompt just doesn't contain "pending" there).  I tried
> with emacs -Q, and in any buffer I started a word search and just began
> typing characters.

Thanks for discovering the problem in Info, it will be fixed by the next patch.
It seems to work while I used it to search for the mentions of the word
“pending” in the Emacs manual - there is no one, so we could document it
in (info "(emacs) Word Search") with the second patch below.

> BTW, a different question: when I delete characters from my input (with
> backspace) in a word search and then add some new characters, I somehow
> expected that isearch would return to that "pending" state.  But I got
> the jumpy (nonlax) incremental search behavior instead.  I don't have an
> opinion about that, just wanted to mention it.

“Pending” is not displayed in the prompt while deleting with backspace
since this state in not stored in isearch-cmds.  But I see no problem
because “pending” appears again when you continue typing new characters.

diff --git a/lisp/info.el b/lisp/info.el
index e32b6b3..3eb2021 100644
--- a/lisp/info.el
+++ b/lisp/info.el
@@ -2107,11 +2107,10 @@ (defun Info-isearch-search ()
 	   (cond
 	    (isearch-regexp-function
 	     ;; Lax version of word search
-	     (let ((lax (not (or isearch-nonincremental
-				 (eq (length string)
-				     (length (isearch--state-string
-					      (car isearch-cmds))))))))
-	       (if (functionp isearch-regexp-function)
+	     (let ((lax (isearch--lax-regexp-function-p string)))
+               (when lax
+                 (setq isearch-adjusted t))
+               (if (functionp isearch-regexp-function)
 		   (funcall isearch-regexp-function string lax)
 		 (word-search-regexp string lax))))
 	    (isearch-regexp string)
diff --git a/lisp/isearch.el b/lisp/isearch.el
index 5c48c30..856738e 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -2718,11 +2718,11 @@ (defun isearch-search-fun ()
 Can be changed via `isearch-search-fun-function' for special needs."
   (funcall (or isearch-search-fun-function 'isearch-search-fun-default)))
 
-(defun isearch--lax-regexp-function-p ()
+(defun isearch--lax-regexp-function-p (&optional string)
   "Non-nil if next regexp-function call should be lax."
   (not (or isearch-nonincremental
            (null (car isearch-cmds))
-           (eq (length isearch-string)
+           (eq (length (or string isearch-string))
                (length (isearch--state-string
                         (car isearch-cmds)))))))
 
@@ -2741,6 +2741,8 @@ (defun isearch-search-fun-default ()
            (if isearch-forward #'re-search-forward #'re-search-backward)
            (cond (isearch-regexp-function
                   (let ((lax (isearch--lax-regexp-function-p)))
+                    (when lax
+                      (setq isearch-adjusted t))
                     (if (functionp isearch-regexp-function)
                         (funcall isearch-regexp-function string lax)
                       (word-search-regexp string lax))))

diff --git a/doc/emacs/search.texi b/doc/emacs/search.texi
index b728258..1296b3b 100644
--- a/doc/emacs/search.texi
+++ b/doc/emacs/search.texi
@@ -609,6 +609,8 @@ Word Search
 so that the matching can proceed incrementally as you type.  This
 additional laxity does not apply to the lazy highlight
 (@pxref{Incremental Search}), which always matches whole words.
+While you are typing the search string, @samp{Pending} appears in the
+search prompt until you use a search repeating key like @kbd{C-s}.
 
   The word search commands don't perform character folding, and
 toggling lax whitespace matching (@pxref{Lax Search, lax space

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> “Pending” is not displayed in the prompt while deleting with backspace
> since this state in not stored in isearch-cmds.  But I see no problem
> because “pending” appears again when you continue typing new
> characters.

Indeed, it's alright, maybe I had tried with the normal (literal)
search, dunno, I can't reproduce what I remembered to have seen
yesterday.


Michael.

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> diff --git a/lisp/info.el b/lisp/info.el
> index e32b6b3..3eb2021 100644

Works ok for me, thanks.

I wonder however if we should similarly also update/improve the manual
page about symbol search.  In particular, this sentence seems to speak
about lax matching:

  "In incremental symbol search, only the beginning of the search string
  is required to match the beginning of a symbol."

but as it stands, the sentence is false - this is only true while still
adding characters to the input.


Thanks,

Michael.

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Fri, 03 Feb 2017 12:04:05 +0100
> Cc: 25562@debbugs.gnu.org, Antoine Levitt <antoine.levitt@gmail.com>
> 
>   "In incremental symbol search, only the beginning of the search string
>   is required to match the beginning of a symbol."
> 
> but as it stands, the sentence is false - this is only true while still
> adding characters to the input.

"While still adding characters" is not a useful qualification in
incremental search, because the user has no means to tell Emacs when
this phase is over.  I think you meant to say "until the next C-s".

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> "While still adding characters" is not a useful qualification in
> incremental search, because the user has no means to tell Emacs when
> this phase is over.  I think you meant to say "until the next C-s".

Sure.  I didn't suggest to add what I said literally that to the docs.
I rather just wanted to point to a deficiency.  Thanks for the
clarification anyway.


Michael.

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Juri Linkov]

>> "While still adding characters" is not a useful qualification in
>> incremental search, because the user has no means to tell Emacs when
>> this phase is over.  I think you meant to say "until the next C-s".
>
> Sure.  I didn't suggest to add what I said literally that to the docs.
> I rather just wanted to point to a deficiency.  Thanks for the
> clarification anyway.

Thanks for the suggestion.  What do you think about this?

diff --git a/doc/emacs/search.texi b/doc/emacs/search.texi
index fa69ba4..a76141e 100644
--- a/doc/emacs/search.texi
+++ b/doc/emacs/search.texi
@@ -609,6 +609,8 @@ Word Search
 so that the matching can proceed incrementally as you type.  This
 additional laxity does not apply to the lazy highlight
 (@pxref{Incremental Search}), which always matches whole words.
+While you are typing the search string, @samp{Pending} appears in the
+search prompt until you use a search repeating key like @kbd{C-s}.
 
   The word search commands don't perform character folding, and
 toggling lax whitespace matching (@pxref{Lax Search, lax space
@@ -662,7 +664,9 @@ Symbol Search
 direction of the search and the current search string; you can disable
 symbol search by typing @kbd{M-s _} again.  In incremental symbol
 search, only the beginning of the search string is required to match
-the beginning of a symbol.
+the beginning of a symbol while you are typing the search string,
+@samp{Pending} appears in the search prompt until you use a search
+repeating key like @kbd{C-s}.
 
   To begin a nonincremental symbol search, type @kbd{M-s _ @key{RET}}
 for a forward search, or @kbd{M-s _ C-r @key{RET}} or a backward

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Thanks for the suggestion.  What do you think about this?

Seems appropriate.

> -the beginning of a symbol.
> +the beginning of a symbol while you are typing the search string,
                                                                   ^
> +@samp{Pending} appears in the search prompt until you use a search
> +repeating key like @kbd{C-s}.

Should we maybe replace the comma with "and" to make clear that those
two parts (lax matching behavior and "Pending" in the prompt) refer
exactly to the same situation?


Michael.

bug#25562: 25.1; isearch-forward-word first matches a non-word

[Juri Linkov]

>> -the beginning of a symbol.
>> +the beginning of a symbol while you are typing the search string,
>                                                                    ^
>> +@samp{Pending} appears in the search prompt until you use a search
>> +repeating key like @kbd{C-s}.
>
> Should we maybe replace the comma with "and" to make clear that those
> two parts (lax matching behavior and "Pending" in the prompt) refer
> exactly to the same situation?

Thanks for the help, now installed and closed.