Let's make C-M-w in isearch yank symbol, not delete character

Let's make C-M-w in isearch yank symbol, not delete character

[Daniel Colascione]

Right now, C-w in search-mode yanks a word from the buffer and globs it 
onto the end of the search result. I usually want to search for symbols, 
not words, so I end up pressing C-w multiple times. C-M-w would be the 
natural keybinding for yanking a symbol instead of a word, but it's 
already taken by isearch-del-char. How about moving isearch-del-char 
somewhere else, like C-d, and making C-M-w yank a whole symbol?

Re: Let's make C-M-w in isearch yank symbol, not delete character

[John Wiegley]

>>>>> "DC" == Daniel Colascione <dancol@dancol.org> writes:

DC> Right now, C-w in search-mode yanks a word from the buffer and globs it
DC> onto the end of the search result. I usually want to search for symbols,
DC> not words, so I end up pressing C-w multiple times. C-M-w would be the
DC> natural keybinding for yanking a symbol instead of a word, but it's
DC> already taken by isearch-del-char. How about moving isearch-del-char
DC> somewhere else, like C-d, and making C-M-w yank a whole symbol?

This makes a lot more sense to me than have C-M-w delete a character...

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

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Juri Linkov]

> Right now, C-w in search-mode yanks a word from the buffer and globs it
> onto the end of the search result. I usually want to search for symbols,
> not words, so I end up pressing C-w multiple times. C-M-w would be the
> natural keybinding for yanking a symbol instead of a word, but it's already
> taken by isearch-del-char. How about moving isearch-del-char somewhere
> else, like C-d, and making C-M-w yank a whole symbol?

But isn't the prefix 'C-M-' usually reserved for keys that operate on
whole expressions, not just symbols?

Fortunately, it's easy to add support for yanking an expression:
in addition to the existing option 'edit' of 'search-exit-option'
we can also provide a new option 'move' that will sync the current
search string with the new position in the buffer after moving point
using all standard motion commands, e.g. `C-f' will add the next char
to the end of the search string, `C-M-f' will add the next expression,
`M-f' will add the next word, `C-b' will delete text from the end of
the search string, etc.  Here is the implementation:

diff --git a/lisp/isearch.el b/lisp/isearch.el
index a41adf0..4c3672e 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -2428,7 +2428,7 @@ isearch-pre-command-hook
       (read-event)
       (setq this-command 'isearch-edit-string))
      ;; Other characters terminate the search and are then executed normally.
-     (search-exit-option
+     ((not (eq search-exit-option 'move))
       (isearch-done)
       (isearch-clean-overlays))
      ;; If search-exit-option is nil, run the command without exiting Isearch.
@@ -2436,6 +2436,12 @@ isearch-pre-command-hook
       (isearch-process-search-string key key)))))
 
 (defun isearch-post-command-hook ()
+  (when (eq search-exit-option 'move)
+    (let ((string (buffer-substring-no-properties
+                   (or isearch-other-end isearch-opoint) (point))))
+      (setq isearch-string string
+            isearch-message string)
+      (isearch-search-and-update)))
   (when isearch-pre-scroll-point
     (let ((ab-bel (isearch-string-out-of-window isearch-pre-scroll-point)))
       (if ab-bel

Re: Let's make C-M-w in isearch yank symbol, not delete character

[H. Dieter Wilhelm]

Juri Linkov <juri@linkov.net> writes:

>> Right now, C-w in search-mode yanks a word from the buffer and globs it
>> onto the end of the search result. I usually want to search for symbols,
>> not words, so I end up pressing C-w multiple times. C-M-w would be the
>> natural keybinding for yanking a symbol instead of a word, but it's already
>> taken by isearch-del-char. How about moving isearch-del-char somewhere
>> else, like C-d, and making C-M-w yank a whole symbol?
>
> But isn't the prefix 'C-M-' usually reserved for keys that operate on
> whole expressions, not just symbols?
>
> Fortunately, it's easy to add support for yanking an expression:
> in addition to the existing option 'edit' of 'search-exit-option'
> we can also provide a new option 'move' that will sync the current
> search string with the new position in the buffer after moving point
> using all standard motion commands, e.g. `C-f' will add the next char
> to the end of the search string, `C-M-f' will add the next expression,
> `M-f' will add the next word, `C-b' will delete text from the end of
> the search string, etc.  Here is the implementation:

+1

thanks
-- 
Best wishes
H. Dieter Wilhelm
Kelkheim, Germany

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Daniel Colascione]

On 02/25/2018 12:55 PM, Juri Linkov wrote:
>> Right now, C-w in search-mode yanks a word from the buffer and globs it
>> onto the end of the search result. I usually want to search for symbols,
>> not words, so I end up pressing C-w multiple times. C-M-w would be the
>> natural keybinding for yanking a symbol instead of a word, but it's already
>> taken by isearch-del-char. How about moving isearch-del-char somewhere
>> else, like C-d, and making C-M-w yank a whole symbol?
> 
> But isn't the prefix 'C-M-' usually reserved for keys that operate on
> whole expressions, not just symbols?

Good point. I don't have a strong objection to using forward-sexp 
instead of forward-symbol. It'll still DWIM in the cases I care about.

> Fortunately, it's easy to add support for yanking an expression:
> in addition to the existing option 'edit' of 'search-exit-option'
> we can also provide a new option 'move' that will sync the current
> search string with the new position in the buffer after moving point
> using all standard motion commands, e.g. `C-f' will add the next char
> to the end of the search string, `C-M-f' will add the next expression,
> `M-f' will add the next word, `C-b' will delete text from the end of
> the search string, etc.  Here is the implementation:

Thanks. I'm looking for ways we can tweak the existing default 
interaction model, but I think we should take a broader look at how 
isearch works in the first place. IMHO, find-and-replace should be more 
closely integrated into isearch, we should have a unified history for 
regular and regex search, and case-sensitivity, symbol-granularity, 
regex mode, etc. should all be independently toggleable peer flags.

Isearch interaction model (was: Let's make C-M-w in isearch yank symbol, not delete character)

[Juri Linkov]

> Thanks. I'm looking for ways we can tweak the existing default interaction
> model, but I think we should take a broader look at how isearch works in
> the first place. IMHO, find-and-replace should be more closely integrated
> into isearch,

I believe we could arrive to this goal gradually by adding more isearch
features to query-replace, and query-replace features to isearch,
i.e. like digging a tunnel from both ends to meet in the middle.

As one of first simplest steps we could try to sync their keybindings
as much as possible, e.g. to add:

(define-key query-replace-map "\C-s" 'skip)
(define-key query-replace-map "\C-r" 'backup)
(define-key query-replace-map "\M-e" 'edit-replacement)
...

> we should have a unified history for regular and regex search,

Not sure about this, I thought more in the direction of adding separate
histories for word search, symbol search, to be able to repeat the last
search of the same type.  Why do you think histories should be shared?

> and case-sensitivity, symbol-granularity, regex mode, etc. should all
> be independently toggleable peer flags.

Do you mean customizing default search parameters, or keeping toggled
parameters in later searches?

Re: Isearch interaction model

[Daniel Colascione]

On 03/01/2018 02:39 PM, Juri Linkov wrote:
>> Thanks. I'm looking for ways we can tweak the existing default interaction
>> model, but I think we should take a broader look at how isearch works in
>> the first place. IMHO, find-and-replace should be more closely integrated
>> into isearch,
> 
> I believe we could arrive to this goal gradually by adding more isearch
> features to query-replace, and query-replace features to isearch,
> i.e. like digging a tunnel from both ends to meet in the middle.

Right. It should be easy to switch between isearch and query-replace.

> As one of first simplest steps we could try to sync their keybindings
> as much as possible, e.g. to add:
> 
> (define-key query-replace-map "\C-s" 'skip)
> (define-key query-replace-map "\C-r" 'backup)
> (define-key query-replace-map "\M-e" 'edit-replacement)

(y)

> ...
> 
>> we should have a unified history for regular and regex search,
> 
> Not sure about this, I thought more in the direction of adding separate
> histories for word search, symbol search, to be able to repeat the last
> search of the same type.  Why do you think histories should be shared?

"What" versus "how".

We have a search history because it's often the case that we want to 
repeat something we've recently done --- look up the same word, find the 
same function, and so on. It doesn't make sense to me that the exact 
mechanism we use to search for a particular thing should affect its 
recency or the way in which we recall it.

It's very easy already to casually switch between literal and regex 
isearch with M-r. Why should this distinction affect the way in which we 
recall that search?

>> and case-sensitivity, symbol-granularity, regex mode, etc. should all
>> be independently toggleable peer flags.
> 
> Do you mean customizing default search parameters, or keeping toggled
> parameters in later searches?

Both.

Re: Isearch interaction model

[Davis Herring]

> We have a search history because it's often the case that we want to 
> repeat something we've recently done --- look up the same word, find 
> the same function, and so on. It doesn't make sense to me that the 
> exact mechanism we use to search for a particular thing should
> affect its recency or the way in which we recall it.
But "repeating" a search for \_<foo\_> as a non-regexp search is useless.

> It's very easy already to casually switch between literal and regex 
> isearch with M-r. Why should this distinction affect the way in which
> we recall that search?
I think the answer is to have one history which records the mode used 
for each search, so that it is reused correctly.  (When it makes sense, 
the user can change the search mode after selecting the history element.)

>> keeping toggled parameters in later searches?

...Which fits nicely with the idea that the parameters are "sticky" 
(either to a history element or to the user's current state).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

Re: Isearch interaction model

[dancol]

>> We have a search history because it's often the case that we want to
>> repeat something we've recently done --- look up the same word, find
>> the same function, and so on. It doesn't make sense to me that the
>> exact mechanism we use to search for a particular thing should
>> affect its recency or the way in which we recall it.
> But "repeating" a search for \_<foo\_> as a non-regexp search is useless.

It is. That's why we'll store the search flags along with the history
entry. A long time ago (years and years), I posted a proof-of-concept of
this model to emacs-devel.

>
>> It's very easy already to casually switch between literal and regex
>> isearch with M-r. Why should this distinction affect the way in which
>> we recall that search?
> I think the answer is to have one history which records the mode used
> for each search, so that it is reused correctly.  (When it makes sense,
> the user can change the search mode after selecting the history element.)
>

Yep.

Re: Isearch interaction model

[Juri Linkov]

>>> We have a search history because it's often the case that we want to
>>> repeat something we've recently done --- look up the same word, find
>>> the same function, and so on. It doesn't make sense to me that the
>>> exact mechanism we use to search for a particular thing should
>>> affect its recency or the way in which we recall it.
>> But "repeating" a search for \_<foo\_> as a non-regexp search is useless.
>
> It is. That's why we'll store the search flags along with the history
> entry. A long time ago (years and years), I posted a proof-of-concept of
> this model to emacs-devel.
>
>>
>>> It's very easy already to casually switch between literal and regex
>>> isearch with M-r. Why should this distinction affect the way in which
>>> we recall that search?
>> I think the answer is to have one history which records the mode used
>> for each search, so that it is reused correctly.  (When it makes sense,
>> the user can change the search mode after selecting the history element.)
>>
>
> Yep.

One of the main questions to decide is how to attach search parameters
to the search string in the search history in a backward-compatible way.
We can't do this by adding text properties with search parameters
to the search string because text properties on strings can't be saved
in the desktop file or by other history saving libraries.

I see no way other than introducing a new incompatible history variable
that will keep previous searches with parameters in the same format
as is used currently by the search stack in isearch-cmds.

Re: Isearch interaction model

[Clément Pit-Claudel]

On 2018-03-03 17:50, Juri Linkov wrote:
> because text properties on strings can't be saved
> in the desktop file or by other history saving libraries.

Couldn't we change that instead?

Re: Isearch interaction model

[Juri Linkov]

>> because text properties on strings can't be saved
>> in the desktop file or by other history saving libraries.
>
> Couldn't we change that instead?

Text properties are problematic in other aspects besides serialization,
e.g. the result of coping/yanking the search string will depend on the
value of yank-excluded-properties, etc.

Re: Isearch interaction model

[Juri Linkov]

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

>> because text properties on strings can't be saved
>> in the desktop file or by other history saving libraries.
>
> Couldn't we change that instead?

It seems text properties is the least bad of all other alternatives
that are not backward compatible and don't allow adding support for
search parameters to query-replace such as requested in bug#22479,
so with text properties this seems to be a better way, and adding
support to desktop for text properties is not unachievable:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: isearch-text-properties.patch --]
[-- Type: text/x-diff, Size: 6812 bytes --]

diff --git a/lisp/desktop.el b/lisp/desktop.el
index 8bd4465..a7e549f 100644
--- a/lisp/desktop.el
+++ b/lisp/desktop.el
@@ -852,10 +852,7 @@ desktop--v2s
     ((or (numberp value) (null value) (eq t value) (keywordp value))
      (cons 'may value))
     ((stringp value)
-     (let ((copy (copy-sequence value)))
-       (set-text-properties 0 (length copy) nil copy)
-       ;; Get rid of text properties because we cannot read them.
-       (cons 'may copy)))
+     (cons 'may value))
     ((symbolp value)
      (cons 'must value))
     ((vectorp value)
diff --git a/lisp/isearch.el b/lisp/isearch.el
index 4f5f494..0699868 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -1119,7 +1119,9 @@ isearch-done
 
   (if (and (> (length isearch-string) 0) (not nopush))
       ;; Update the ring data.
-      (isearch-update-ring isearch-string isearch-regexp))
+      (isearch-update-ring isearch-string isearch-regexp
+                           `(regexp-function ,isearch-regexp-function
+                             case-fold-search ,isearch-case-fold-search)))
 
   (let ((isearch-mode-end-hook-quit (and nopush (not edit))))
     (run-hooks 'isearch-mode-end-hook))
@@ -1135,12 +1137,12 @@ isearch-done
 
   (and (not edit) isearch-recursive-edit (exit-recursive-edit)))
 
-(defun isearch-update-ring (string &optional regexp)
+(defun isearch-update-ring (string &optional regexp properties)
   "Add STRING to the beginning of the search ring.
 REGEXP if non-nil says use the regexp search ring."
   (add-to-history
    (if regexp 'regexp-search-ring 'search-ring)
-   string
+   (if properties (apply 'propertize string properties) string)
    (if regexp regexp-search-ring-max search-ring-max)))
 
 ;; Switching buffers should first terminate isearch-mode.
@@ -1850,7 +1852,11 @@ isearch-query-replace
 	;; `exit-recursive-edit' in `isearch-done' that terminates
 	;; the execution of this command when it is non-nil.
 	;; We call `exit-recursive-edit' explicitly at the end below.
-	(isearch-recursive-edit nil))
+	(isearch-recursive-edit nil)
+        (isearch-string-propertized
+         (propertize isearch-string
+		     'isearch-regexp-function isearch-regexp-function
+		     'isearch-case-fold-search isearch-case-fold-search)))
     (isearch-done nil t)
     (isearch-clean-overlays)
     (if (and isearch-other-end
@@ -1863,12 +1869,12 @@ isearch-query-replace
 			 (< (mark) (point))))))
         (goto-char isearch-other-end))
     (set query-replace-from-history-variable
-         (cons isearch-string
+         (cons isearch-string-propertized
                (symbol-value query-replace-from-history-variable)))
     (perform-replace
-     isearch-string
+     isearch-string-propertized
      (query-replace-read-to
-      isearch-string
+      isearch-string-propertized
       (concat "Query replace"
               (isearch--describe-regexp-mode (or delimited isearch-regexp-function) t)
 	      (if backward " backward" "")
@@ -2572,7 +2578,13 @@ isearch-ring-adjust1
 		      length)))
       (setq isearch-string (nth yank-pointer ring)
 	    isearch-message (mapconcat 'isearch-text-char-description
-				       isearch-string "")))))
+				       isearch-string ""))
+      (when (memq 'regexp-function (text-properties-at 0 isearch-string))
+        (setq isearch-regexp-function
+              (get-text-property 0 'regexp-function isearch-string)))
+      (when (memq 'case-fold-search (text-properties-at 0 isearch-string))
+        (setq isearch-case-fold-search
+              (get-text-property 0 'case-fold-search isearch-string))))))
 
 (defun isearch-ring-adjust (advance)
   ;; Helper for isearch-ring-advance and isearch-ring-retreat
@@ -2788,11 +2800,15 @@ isearch-search-fun
 
 (defun isearch--lax-regexp-function-p ()
   "Non-nil if next regexp-function call should be lax."
+  ;; FIXME: maybe simpler to use this:
+  ;; (or (memq this-command '(isearch-printing-char isearch-del-char)) isearch-yank-flag)
   (not (or isearch-nonincremental
            (null (car isearch-cmds))
            (eq (length isearch-string)
                (length (isearch--state-string
-                        (car isearch-cmds)))))))
+                        (car isearch-cmds))))
+           ;; Search string comes from the history with text properties
+           (memq 'regexp-function (text-properties-at 0 isearch-string)))))
 
 (defun isearch-search-fun-default ()
   "Return default functions to use for the search."
diff --git a/lisp/replace.el b/lisp/replace.el
index c28c9b3..ac37bd7 100644
--- a/lisp/replace.el
+++ b/lisp/replace.el
@@ -301,7 +301,9 @@ query-replace-read-args
 	 (to (if (consp from) (prog1 (cdr from) (setq from (car from)))
 	       (query-replace-read-to from prompt regexp-flag))))
     (list from to
-	  (and current-prefix-arg (not (eq current-prefix-arg '-)))
+	  (or (and current-prefix-arg (not (eq current-prefix-arg '-)))
+              (and (memq 'isearch-regexp-function (text-properties-at 0 from))
+                   (get-text-property 0 'isearch-regexp-function from)))
 	  (and current-prefix-arg (eq current-prefix-arg '-)))))
 
 (defun query-replace (from-string to-string &optional delimited start end backward region-noncontiguous-p)
@@ -2361,8 +2363,17 @@ perform-replace
          (message
           (if query-flag
               (apply 'propertize
-                     (substitute-command-keys
-                      "Query replacing %s with %s: (\\<query-replace-map>\\[help] for help) ")
+                     (concat "Query replacing "
+                             (if backward "backward " "")
+                             (if delimited-flag
+                                 (or (and (symbolp delimited-flag)
+                                          (get delimited-flag
+                                               'isearch-message-prefix))
+                                     "word ") "")
+                             (if regexp-flag "regexp " "")
+                             "%s with %s: "
+                             (substitute-command-keys
+                              "(\\<query-replace-map>\\[help] for help) "))
                      minibuffer-prompt-properties))))
 
     ;; Unless a single contiguous chunk is selected, operate on multiple chunks.
@@ -2580,13 +2591,13 @@ perform-replace
 			 (with-output-to-temp-buffer "*Help*"
 			   (princ
 			    (concat "Query replacing "
+				    (if backward "backward " "")
 				    (if delimited-flag
 					(or (and (symbolp delimited-flag)
 						 (get delimited-flag
                                                       'isearch-message-prefix))
 					    "word ") "")
 				    (if regexp-flag "regexp " "")
-				    (if backward "backward " "")
 				    from-string " with "
 				    next-replacement ".\n\n"
 				    (substitute-command-keys

Re: Isearch interaction model

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 04 Mar 2018 00:50:27 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> >> I think the answer is to have one history which records the mode used
> >> for each search, so that it is reused correctly.  (When it makes sense,
> >> the user can change the search mode after selecting the history element.)
> >>
> >
> > Yep.
> 
> One of the main questions to decide is how to attach search parameters
> to the search string in the search history in a backward-compatible way.
> We can't do this by adding text properties with search parameters
> to the search string because text properties on strings can't be saved
> in the desktop file or by other history saving libraries.
> 
> I see no way other than introducing a new incompatible history variable
> that will keep previous searches with parameters in the same format
> as is used currently by the search stack in isearch-cmds.

Aren't we over-engineering this stuff?  IMNSHO, separate histories
could be just fine, since it's easy enough to change the Isearch mode
after you have the previous search string in the minibuffer.  And if
you remember your previous searches, you most probably also remember
whether you searched for a string as a symbol or a word or whatever.

By contrast, breaking back-compatibility for this reason sounds gross
to me.

Re: Isearch interaction model

[Daniel Colascione]

On 03/04/2018 07:39 AM, Eli Zaretskii wrote:
>> From: Juri Linkov <juri@linkov.net>
>> Date: Sun, 04 Mar 2018 00:50:27 +0200
>> Cc: Emacs developers <emacs-devel@gnu.org>
>>
>>>> I think the answer is to have one history which records the mode used
>>>> for each search, so that it is reused correctly.  (When it makes sense,
>>>> the user can change the search mode after selecting the history element.)
>>>>
>>>
>>> Yep.
>>
>> One of the main questions to decide is how to attach search parameters
>> to the search string in the search history in a backward-compatible way.
>> We can't do this by adding text properties with search parameters
>> to the search string because text properties on strings can't be saved
>> in the desktop file or by other history saving libraries.
>>
>> I see no way other than introducing a new incompatible history variable
>> that will keep previous searches with parameters in the same format
>> as is used currently by the search stack in isearch-cmds.

So what? That's fine.

> Aren't we over-engineering this stuff?  

No. Exposing search-type-specific histories is what's gross, especially 
as you increase the number of search types beyond the traditional two.

Why does it *matter* whether you search for something as a regular 
expression or a symbol or a word? What matters is what you were trying 
to find, and LRU ordering is a good way to make it easy to find what you 
meant.

> IMNSHO, separate histories
> could be just fine, since it's easy enough to change the Isearch mode
> after you have the previous search string in the minibuffer.

Sure, and you can find ways to accept and work around spacebar heating 
too. The existence of workarounds is not excuse for poor UI.

> And if
> you remember your previous searches, you most probably also remember
> whether you searched for a string as a symbol or a word or whatever.

That's imposing an additional cognitive burden on humans for the sake of 
an isearch implementation detail.

> 
> By contrast, breaking back-compatibility for this reason sounds gross
> to me.

What backwards compatibility? The presence of individual history 
variables across major versions is not guaranteed.

Re: Isearch interaction model

[Clément Pit-Claudel]

On 2018-03-04 12:13, Daniel Colascione wrote:
> What backwards compatibility? The presence of individual history variables across major versions is not guaranteed.

Maybe, but it'd be a pain if moving to  newer release lost all history.

Re: Isearch interaction model

[Juri Linkov]

>> What backwards compatibility? The presence of individual history
>> variables across major versions is not guaranteed.
>
> Maybe, but it'd be a pain if moving to  newer release lost all history.

No pain since we can populate the new history variable from values
saved in old variables ‘search-ring’ and ‘regexp-search-ring’.

Re: Isearch interaction model

[Daniel Colascione]

On 03/04/2018 09:26 AM, Clément Pit-Claudel wrote:
> On 2018-03-04 12:13, Daniel Colascione wrote:
>> What backwards compatibility? The presence of individual history variables across major versions is not guaranteed.
> 
> Maybe, but it'd be a pain if moving to  newer release lost all history.

Of _isearch_? isearch history isn't something you care about keeping 
long-term. File history, sure. Not search.

Re: Isearch interaction model

[Eli Zaretskii]

> From: Daniel Colascione <dancol@dancol.org>
> Date: Sun, 4 Mar 2018 14:03:49 -0800
> 
> > it'd be a pain if moving to  newer release lost all history.
> 
> Of _isearch_? isearch history isn't something you care about keeping 
> long-term.

I do.  desktop.el saves and restores it, and for a good reason.

Re: Isearch interaction model

[Juri Linkov]

>>> What backwards compatibility? The presence of individual history
>>> variables across major versions is not guaranteed.
>>
>> Maybe, but it'd be a pain if moving to  newer release lost all history.
>
> Of _isearch_? isearch history isn't something you care about keeping
> long-term. File history, sure. Not search.

Not true.  I customized isearch not to save unnecessary search strings
to the search history on exiting isearch, and an additional key C-RET
defines whether to exit with keeping the current search in the history
or not.  This way I have only frequently used search strings in the
search history saved to the desktop file to be reused later.  Some are
quite complex regexps that would be a waste of time to retype again.

Re: Isearch interaction model

[Juri Linkov]

>> Aren't we over-engineering this stuff?
>
> No. Exposing search-type-specific histories is what's gross, especially as
> you increase the number of search types beyond the traditional two.

True, currently we have no special histories for word search, symbol search,
case-fold search, and adding separate histories for them would be what
can be called over-engineering.

Re: Isearch interaction model

[Juri Linkov]

> I think the answer is to have one history which records the mode used for
> each search, so that it is reused correctly.  (When it makes sense, the
> user can change the search mode after selecting the history element.)

I still don't see how this unified history should work.  Suppose we have
a history variable like

(setq isearch-history
  '(((search-string "word") (mode word))
    ((search-string "regexp") (mode regexp))))

Then after typing ‘C-M-s M-p’ (in regexp search mode) what should it do?
Possible variants:

1. Take a previous history item with the same search mode,
   i.e. the string "regexp", skipping the last used search "word".

2. Take the last history item "word" and toggle the current search mode
   from regexp mode to word mode.

3. Take the last history item and adapt it to the current search mode,
   so turn the search string "word" into the regexp "\<word\>".

4. Take the last history item and do nothing more.
   Then what to do when the last search string is a regexp
   and the current search mode is not regexp mode?

Re: Isearch interaction model

[dancol]

>> I think the answer is to have one history which records the mode used
>> for
>> each search, so that it is reused correctly.  (When it makes sense, the
>> user can change the search mode after selecting the history element.)
>
> I still don't see how this unified history should work.  Suppose we have
> a history variable like
>
> (setq isearch-history
>   '(((search-string "word") (mode word))
>     ((search-string "regexp") (mode regexp))))
>
> Then after typing ‘C-M-s M-p’ (in regexp search mode) what should it
> do?
> Possible variants:
>
> 1. Take a previous history item with the same search mode,
>    i.e. the string "regexp", skipping the last used search "word".
>
> 2. Take the last history item "word" and toggle the current search mode
>    from regexp mode to word mode.
>
> 3. Take the last history item and adapt it to the current search mode,
>    so turn the search string "word" into the regexp "\<word\>".
>
> 4. Take the last history item and do nothing more.
>    Then what to do when the last search string is a regexp
>    and the current search mode is not regexp mode?

The isearch mode should be attached to the history item. C-M-s M-p and C-s
M-p should have the same effect: the "mode" is only a default for a new
search. If the last search was a regex search, it'll put in you regex
search mode.

Re: Isearch interaction model

[Juri Linkov]

> The isearch mode should be attached to the history item. C-M-s M-p and C-s
> M-p should have the same effect: the "mode" is only a default for a new
> search. If the last search was a regex search, it'll put in you regex
> search mode.

But what about keeping current behavior where C-M-s M-p pulls only
regexps from the regexp history.  Should we break backward compatibility
in how it used to work?

Re: Isearch interaction model

[dancol]

>> The isearch mode should be attached to the history item. C-M-s M-p and
>> C-s
>> M-p should have the same effect: the "mode" is only a default for a new
>> search. If the last search was a regex search, it'll put in you regex
>> search mode.
>
> But what about keeping current behavior where C-M-s M-p pulls only
> regexps from the regexp history.  Should we break backward compatibility
> in how it used to work?

I think that behavior is an artifact of the current implementation, not
something desirable.

Re: Isearch interaction model

[Juri Linkov]

>>> The isearch mode should be attached to the history item. C-M-s M-p and
>>> C-s
>>> M-p should have the same effect: the "mode" is only a default for a new
>>> search. If the last search was a regex search, it'll put in you regex
>>> search mode.
>>
>> But what about keeping current behavior where C-M-s M-p pulls only
>> regexps from the regexp history.  Should we break backward compatibility
>> in how it used to work?
>
> I think that behavior is an artifact of the current implementation, not
> something desirable.

String and regexp searches are fundamentally different in nature.
Regexps are useless in string-based modes, whereas strings in isearch
are interpreted by different rules according to mode: word/case-fold/...
e.g. it makes sense to switch from case-fold mode to word mode, but
not from regexp mode to literal mode.

But it you want to share string and regexp histories, it's easy to implement
by another layer of indirection like for query-replace history variables:

(defcustom query-replace-from-history-variable 'query-replace-history
(defcustom query-replace-to-history-variable 'query-replace-history

Re: Isearch interaction model

[Daniel Colascione]

On 03/08/2018 02:41 PM, Juri Linkov wrote:
>>>> The isearch mode should be attached to the history item. C-M-s M-p and
>>>> C-s
>>>> M-p should have the same effect: the "mode" is only a default for a new
>>>> search. If the last search was a regex search, it'll put in you regex
>>>> search mode.
>>>
>>> But what about keeping current behavior where C-M-s M-p pulls only
>>> regexps from the regexp history.  Should we break backward compatibility
>>> in how it used to work?
>>
>> I think that behavior is an artifact of the current implementation, not
>> something desirable.
> 
> String and regexp searches are fundamentally different in nature.

Why? I use them as different ways of accomplishing the same goal: 
finding something in a buffer.

> Regexps are useless in string-based modes, whereas strings in isearch
> are interpreted by different rules according to mode: word/case-fold/...
> e.g. it makes sense to switch from case-fold mode to word mode, but
> not from regexp mode to literal mode.

But people _do_ switch from regex to literal mode and back. That's why 
M-r is a convenient isearch binding for doing exactly that, and on 
prevision occasions when this topic has come up for discussion, others 
have indicated that they use this M-r binding.

> But it you want to share string and regexp histories, it's easy to implement
> by another layer of indirection like for query-replace history variables:
> 
> (defcustom query-replace-from-history-variable 'query-replace-history
> (defcustom query-replace-to-history-variable 'query-replace-history

Sure. It's possible to make this behavior customizable.

Re: Isearch interaction model

[Juri Linkov]

> But people _do_ switch from regex to literal mode and back. That's why M-r
> is a convenient isearch binding for doing exactly that, and on prevision
> occasions when this topic has come up for discussion, others have indicated
> that they use this M-r binding.

I can't imagine the usefulness of switching from regex to literal mode
when the search string contains a complex regexp.

>> But it you want to share string and regexp histories, it's easy to implement
>> by another layer of indirection like for query-replace history variables:
>>
>> (defcustom query-replace-from-history-variable 'query-replace-history
>> (defcustom query-replace-to-history-variable 'query-replace-history
>
> Sure. It's possible to make this behavior customizable.

But then perhaps search-ring-yank-pointer and regexp-search-ring-yank-pointer
need similar indirection, or code could be smart enough to detect such
indirection and compute the right pointer depending on where such variables
point to.

Re: Isearch interaction model

[Daniel Colascione]

On 03/10/2018 01:20 PM, Juri Linkov wrote:
>> But people _do_ switch from regex to literal mode and back. That's why M-r
>> is a convenient isearch binding for doing exactly that, and on prevision
>> occasions when this topic has come up for discussion, others have indicated
>> that they use this M-r binding.
> 
> I can't imagine the usefulness of switching from regex to literal mode
> when the search string contains a complex regexp.
> 
>>> But it you want to share string and regexp histories, it's easy to implement
>>> by another layer of indirection like for query-replace history variables:
>>>
>>> (defcustom query-replace-from-history-variable 'query-replace-history
>>> (defcustom query-replace-to-history-variable 'query-replace-history
>>
>> Sure. It's possible to make this behavior customizable.
> 
> But then perhaps search-ring-yank-pointer and regexp-search-ring-yank-pointer
> need similar indirection, or code could be smart enough to detect such
> indirection and compute the right pointer depending on where such variables
> point to.

I really think you're over-thinking this problem. Let's just try a 
unified history and see whether it causes problems in practice. I 
suspect it'll feel perfectly natural, and we won't need complex 
indirection layers.

Re: Isearch interaction model

[Juri Linkov]

>>>> But it you want to share string and regexp histories, it's easy to implement
>>>> by another layer of indirection like for query-replace history variables:
>>>>
>>>> (defcustom query-replace-from-history-variable 'query-replace-history
>>>> (defcustom query-replace-to-history-variable 'query-replace-history
>>>
>>> Sure. It's possible to make this behavior customizable.
>>
>> But then perhaps search-ring-yank-pointer and regexp-search-ring-yank-pointer
>> need similar indirection, or code could be smart enough to detect such
>> indirection and compute the right pointer depending on where such variables
>> point to.
>
> I really think you're over-thinking this problem. Let's just try a unified
> history and see whether it causes problems in practice. I suspect it'll
> feel perfectly natural, and we won't need complex indirection layers.

So far we have seen only two opinions: you prefer sharing histories, and
I keep the list of frequently used regexp searches in the separate regexp
history saved in the desktop file.

Re: Isearch interaction model

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 11 Mar 2018 23:58:03 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > I really think you're over-thinking this problem. Let's just try a unified
> > history and see whether it causes problems in practice. I suspect it'll
> > feel perfectly natural, and we won't need complex indirection layers.
> 
> So far we have seen only two opinions: you prefer sharing histories, and
> I keep the list of frequently used regexp searches in the separate regexp
> history saved in the desktop file.

You've also seen mine.  I think separate histories are just fine.

Re: Isearch interaction model

[Daniel Colascione]

On 03/11/2018 02:58 PM, Juri Linkov wrote:
>>>>> But it you want to share string and regexp histories, it's easy to implement
>>>>> by another layer of indirection like for query-replace history variables:
>>>>>
>>>>> (defcustom query-replace-from-history-variable 'query-replace-history
>>>>> (defcustom query-replace-to-history-variable 'query-replace-history
>>>>
>>>> Sure. It's possible to make this behavior customizable.
>>>
>>> But then perhaps search-ring-yank-pointer and regexp-search-ring-yank-pointer
>>> need similar indirection, or code could be smart enough to detect such
>>> indirection and compute the right pointer depending on where such variables
>>> point to.
>>
>> I really think you're over-thinking this problem. Let's just try a unified
>> history and see whether it causes problems in practice. I suspect it'll
>> feel perfectly natural, and we won't need complex indirection layers.
> 
> So far we have seen only two opinions: you prefer sharing histories, and
> I keep the list of frequently used regexp searches in the separate regexp
> history saved in the desktop file.

Hrm. I'm still confused about what makes the regex search case so 
different though. Are you using the regexp-ness of a search as a proxy 
for a search being interesting enough to be worth saving? What if we 
could explicitly mark interesting searches for saving --- or even easily 
name them and bind them, like a keyboard macro?

Re: Isearch interaction model

[Yuri Khan]

On Mon, Mar 12, 2018 at 3:23 PM, Daniel Colascione <dancol@dancol.org> wrote:

> Are you using the regexp-ness of a search as a proxy for a search
> being interesting enough to be worth saving?

I think this is very close. A literal search is memorable because it
represents itself; if you need to reuse it, you can mostly just
re-type it. A regexp is not memorable because of unpronounceable
punctuation around the literal parts. So, when you need to reuse a
regexp, you have to either reconstruct it again (spending time), or
lift it from history.

> What if we could explicitly
> mark interesting searches for saving --- or even easily name them and bind
> them, like a keyboard macro?

Being able to name searches (and possibly search/replace pairs, too)
is an interesting idea. See success story: Thunderbird (where search
criteria on messages can be saved as a virtual folder).

Re: Isearch interaction model (was: Let's make C-M-w in isearch yank symbol, not delete character)

[Richard Stallman]

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

  > I believe we could arrive to this goal gradually by adding more isearch
  > features to query-replace, and query-replace features to isearch,
  > i.e. like digging a tunnel from both ends to meet in the middle.

I don't think we should try to go in that direction.
Query Replace and search are fundamentally different ideas
and trying to make them converge would make them incoherent.

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

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 25 Feb 2018 22:55:40 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Fortunately, it's easy to add support for yanking an expression:
> in addition to the existing option 'edit' of 'search-exit-option'
> we can also provide a new option 'move' that will sync the current
> search string with the new position in the buffer after moving point
> using all standard motion commands, e.g. `C-f' will add the next char
> to the end of the search string, `C-M-f' will add the next expression,
> `M-f' will add the next word, `C-b' will delete text from the end of
> the search string, etc.  Here is the implementation:

Thanks.  I think this needs a documentation update as well.

Also, this comment:

>       ;; Other characters terminate the search and are then executed normally.
> -     (search-exit-option
> +     ((not (eq search-exit-option 'move))

is now not entirely accurate, right?

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Juri Linkov]

>> Fortunately, it's easy to add support for yanking an expression:
>> in addition to the existing option 'edit' of 'search-exit-option'
>> we can also provide a new option 'move' that will sync the current
>> search string with the new position in the buffer after moving point
>> using all standard motion commands, e.g. `C-f' will add the next char
>> to the end of the search string, `C-M-f' will add the next expression,
>> `M-f' will add the next word, `C-b' will delete text from the end of
>> the search string, etc.  Here is the implementation:
>
> Thanks.  I think this needs a documentation update as well.

I updated the documentation in the docstring of search-exit-option below.

> Also, this comment:
>
>>       ;; Other characters terminate the search and are then executed normally.
>> -     (search-exit-option
>> +     ((not (eq search-exit-option 'move))
>
> is now not entirely accurate, right?

Actually it was better to add a new condition, so this comment
remains accurate with this patch:

diff --git a/lisp/isearch.el b/lisp/isearch.el
index a41adf0..6b6570d 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -66,9 +66,17 @@ isearch
   :group 'matching)
 
 
-(defcustom search-exit-option t
-  "Non-nil means random control characters terminate incremental search."
-  :type 'boolean)
+(defcustom search-exit-option 'move
+  "Defines what control characters do in incremental search.
+If t, random control and meta characters terminate the search
+and are then executed normally.
+If `edit', edit the search string instead of exiting.
+If `move', use motion commands to extend the search string.
+If nil, run the command without exiting Isearch."
+  :type '(choice (const :tag "Terminate incremental search" t)
+		 (const :tag "Edit the search string" edit)
+		 (const :tag "Extend the search string by motion commands" move)
+		 (const :tag "Don't terminate incremental search" nil)))
 
 (defcustom search-slow-window-lines 1
   "Number of lines in slow search display windows.
@@ -2391,6 +2414,7 @@ isearch-back-into-window
   (goto-char isearch-point))
 
 (defvar isearch-pre-scroll-point nil)
+(defvar isearch-pre-move-point nil)
 
 (defun isearch-pre-command-hook ()
   "Decide whether to exit Isearch mode before executing the command.
@@ -2427,6 +2451,11 @@ isearch-pre-command-hook
       ;; Swallow the up-event.
       (read-event)
       (setq this-command 'isearch-edit-string))
+     ;; Don't terminate the search for some motion commands.
+     ((and (eq search-exit-option 'move)
+           (symbolp this-command)
+           (eq (get this-command 'isearch-move) t))
+      (setq isearch-pre-move-point (point)))
      ;; Other characters terminate the search and are then executed normally.
      (search-exit-option
       (isearch-done)
@@ -2436,13 +2465,23 @@ isearch-pre-command-hook
       (isearch-process-search-string key key)))))
 
 (defun isearch-post-command-hook ()
-  (when isearch-pre-scroll-point
+  (cond
+   (isearch-pre-scroll-point
     (let ((ab-bel (isearch-string-out-of-window isearch-pre-scroll-point)))
       (if ab-bel
 	  (isearch-back-into-window (eq ab-bel 'above) isearch-pre-scroll-point)
 	(goto-char isearch-pre-scroll-point)))
     (setq isearch-pre-scroll-point nil)
-    (isearch-update)))
+    (isearch-update))
+   ((eq search-exit-option 'move)
+    (when (and isearch-pre-move-point
+               (not (eq isearch-pre-move-point (point))))
+      (let ((string (buffer-substring-no-properties
+                     (or isearch-other-end isearch-opoint) (point))))
+        (setq isearch-string string
+              isearch-message string)
+        (isearch-update)))
+    (setq isearch-pre-move-point nil))))
 
 (defun isearch-quote-char (&optional count)
   "Quote special characters for incremental search.

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: dancol@dancol.org,  emacs-devel@gnu.org
> Date: Tue, 27 Feb 2018 23:28:41 +0200
> 
> >> Fortunately, it's easy to add support for yanking an expression:
> >> in addition to the existing option 'edit' of 'search-exit-option'
> >> we can also provide a new option 'move' that will sync the current
> >> search string with the new position in the buffer after moving point
> >> using all standard motion commands, e.g. `C-f' will add the next char
> >> to the end of the search string, `C-M-f' will add the next expression,
> >> `M-f' will add the next word, `C-b' will delete text from the end of
> >> the search string, etc.  Here is the implementation:
> >
> > Thanks.  I think this needs a documentation update as well.
> 
> I updated the documentation in the docstring of search-exit-option below.

This should be in NEWS as well.  What about the manual?

> +(defcustom search-exit-option 'move
> +  "Defines what control characters do in incremental search.
> +If t, random control and meta characters terminate the search
> +and are then executed normally.
> +If `edit', edit the search string instead of exiting.
> +If `move', use motion commands to extend the search string.
> +If nil, run the command without exiting Isearch."
> +  :type '(choice (const :tag "Terminate incremental search" t)
> +		 (const :tag "Edit the search string" edit)
> +		 (const :tag "Extend the search string by motion commands" move)
> +		 (const :tag "Don't terminate incremental search" nil)))

Please add a :version tag to this defcustom.

Thanks.

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Juri Linkov]

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

>> I updated the documentation in the docstring of search-exit-option below.
>
> This should be in NEWS as well.  What about the manual?

Here is a new patch with the NEWS entry.  Regarding the documentation,
I'm pretty sure this is not the final implementation as there will be
more changes in that feature before it's ready to be documented in
(info "(emacs) Not Exiting Isearch") or in (info "(emacs) Isearch Yank").


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: search-exit-option.patch --]
[-- Type: text/x-diff, Size: 4896 bytes --]

diff --git a/etc/NEWS b/etc/NEWS
index 596adf8..0d43913 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -180,6 +180,14 @@ created by 'edit-last-kbd-macro', and to save the macro by 'C-c C-c'.
 ---
 *** New filter ibuffer-filter-by-process; bound to '/E'.
 
+** Search and Replace
+
+*** 'search-exit-option' provides new options 'move' and 'shift-move'
+to extend the search string by yanking text that ends at the new
+position after moving point in the current buffer.  `shift-move'
+extends the search string by motion commands while holding down
+the shift key.
+
 ** Edebug
 
 +++
diff --git a/lisp/isearch.el b/lisp/isearch.el
index a41adf0..524137a 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -67,8 +67,23 @@ isearch
 
 
 (defcustom search-exit-option t
-  "Non-nil means random control characters terminate incremental search."
-  :type 'boolean)
+  "Defines what control characters do in incremental search.
+If t, random control and meta characters terminate the search
+and are then executed normally.
+If `edit', edit the search string instead of exiting.
+If `move', extend the search string by motion commands
+that have the `isearch-move' property on their symbols.
+If `shift-move', extend the search string by motion commands
+while holding down the shift key.
+Both `move' and `shift-move' extend the search string by yanking text
+that ends at the new position after moving point in the current buffer.
+If nil, run the command without exiting Isearch."
+  :type '(choice (const :tag "Terminate incremental search" t)
+                 (const :tag "Edit the search string" edit)
+                 (const :tag "Extend the search string by motion commands" move)
+                 (const :tag "Extend the search string by shifted motion keys" shift-move)
+                 (const :tag "Don't terminate incremental search" nil))
+  :version "27.1")
 
 (defcustom search-slow-window-lines 1
   "Number of lines in slow search display windows.
@@ -2391,6 +2423,7 @@ isearch-back-into-window
   (goto-char isearch-point))
 
 (defvar isearch-pre-scroll-point nil)
+(defvar isearch-pre-move-point nil)
 
 (defun isearch-pre-command-hook ()
   "Decide whether to exit Isearch mode before executing the command.
@@ -2398,8 +2431,9 @@ isearch-pre-command-hook
 is bound in `isearch-mode-map', or if the invoked command is
 a prefix argument command (when `isearch-allow-prefix' is non-nil),
 or it is a scrolling command (when `isearch-allow-scroll' is non-nil).
-Otherwise, exit Isearch (when `search-exit-option' is non-nil)
-before the command is executed globally with terminated Isearch."
+Otherwise, exit Isearch (when `search-exit-option' is t)
+before the command is executed globally with terminated Isearch.
+See more for options in `search-exit-option'."
   (let* ((key (this-single-command-keys))
 	 (main-event (aref key 0)))
     (cond
@@ -2427,6 +2461,14 @@ isearch-pre-command-hook
       ;; Swallow the up-event.
       (read-event)
       (setq this-command 'isearch-edit-string))
+     ;; Don't terminate the search for motion commands.
+     ((or (and (eq search-exit-option 'move)
+               (symbolp this-command)
+               (eq (get this-command 'isearch-move) t))
+          (and (eq search-exit-option 'shift-move)
+               this-command-keys-shift-translated))
+      (setq this-command-keys-shift-translated nil)
+      (setq isearch-pre-move-point (point)))
      ;; Other characters terminate the search and are then executed normally.
      (search-exit-option
       (isearch-done)
@@ -2436,13 +2478,28 @@ isearch-pre-command-hook
       (isearch-process-search-string key key)))))
 
 (defun isearch-post-command-hook ()
-  (when isearch-pre-scroll-point
+  (cond
+   (isearch-pre-scroll-point
     (let ((ab-bel (isearch-string-out-of-window isearch-pre-scroll-point)))
       (if ab-bel
 	  (isearch-back-into-window (eq ab-bel 'above) isearch-pre-scroll-point)
 	(goto-char isearch-pre-scroll-point)))
     (setq isearch-pre-scroll-point nil)
-    (isearch-update)))
+    (isearch-update))
+   ((memq search-exit-option '(move shift-move))
+    (when (and isearch-pre-move-point
+               (not (eq isearch-pre-move-point (point))))
+      (let ((string (buffer-substring-no-properties
+                     (or isearch-other-end isearch-opoint) (point))))
+        (if isearch-regexp (setq string (regexp-quote string)))
+        (setq isearch-string string)
+        (setq isearch-message (mapconcat 'isearch-text-char-description
+                                         string ""))
+        (setq isearch-yank-flag t)
+        (setq isearch-forward (<= (or isearch-other-end isearch-opoint) (point)))
+        (goto-char isearch-pre-move-point)
+        (isearch-search-and-update)))
+    (setq isearch-pre-move-point nil))))
 
 (defun isearch-quote-char (&optional count)
   "Quote special characters for incremental search.

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: dancol@dancol.org,  emacs-devel@gnu.org
> Date: Fri, 02 Mar 2018 00:32:55 +0200
> 
> > This should be in NEWS as well.  What about the manual?
> 
> Here is a new patch with the NEWS entry.  Regarding the documentation,
> I'm pretty sure this is not the final implementation as there will be
> more changes in that feature before it's ready to be documented in
> (info "(emacs) Not Exiting Isearch") or in (info "(emacs) Isearch Yank").

If this feature is good enough to be installed, it should be
documented.  If there are later changes, the documentation should be
amended to reflect that.  If nothing else, this makes sure we don't
forget to document it.  Also, there are people who track the master
branch, and they will certainly benefit from having this documented.

> +** Search and Replace
> +
> +*** 'search-exit-option' provides new options 'move' and 'shift-move'
> +to extend the search string by yanking text that ends at the new
> +position after moving point in the current buffer.  `shift-move'
> +extends the search string by motion commands while holding down
> +the shift key.

Please use a consistent quoting stile 'like this'.

Thanks.

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Juri Linkov]

>> Here is a new patch with the NEWS entry.  Regarding the documentation,
>> I'm pretty sure this is not the final implementation as there will be
>> more changes in that feature before it's ready to be documented in
>> (info "(emacs) Not Exiting Isearch") or in (info "(emacs) Isearch Yank").
>
> If this feature is good enough to be installed, it should be
> documented.  If there are later changes, the documentation should be
> amended to reflect that.  If nothing else, this makes sure we don't
> forget to document it.  Also, there are people who track the master
> branch, and they will certainly benefit from having this documented.

Done with documentation updates in the manual.  Also I noticed that the
value nil of search-exit-option is quite broken: it doesn't do anything
useful.  The manual says:

  "However, if you customize the variable ‘search-exit-option’ to ‘nil’,
  the characters which you type that are not interpreted by the
  incremental search are simply appended to the search string.  This is
  so you could include in the search string control characters, such as
  ‘C-a’, that would normally exit the search and invoke the command
  bound to them on the buffer."

But the comment in isearch-pre-command-hook says:

  ;; If search-exit-option is nil, run the command without exiting Isearch.

So it's not clear what it should do for e.g. motion commands:
just move point without exiting Isearch or append control characters
of motion keys to the search string?

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: dancol@dancol.org,  emacs-devel@gnu.org
> Date: Sun, 04 Mar 2018 00:34:27 +0200
> 
> Done with documentation updates in the manual.

Thanks, but I guess you forgot to attach the patch?

> Also I noticed that the
> value nil of search-exit-option is quite broken: it doesn't do anything
> useful.  The manual says:
> 
>   "However, if you customize the variable ‘search-exit-option’ to ‘nil’,
>   the characters which you type that are not interpreted by the
>   incremental search are simply appended to the search string.  This is
>   so you could include in the search string control characters, such as
>   ‘C-a’, that would normally exit the search and invoke the command
>   bound to them on the buffer."
> 
> But the comment in isearch-pre-command-hook says:
> 
>   ;; If search-exit-option is nil, run the command without exiting Isearch.
> 
> So it's not clear what it should do for e.g. motion commands:
> just move point without exiting Isearch or append control characters
> of motion keys to the search string?

Typing "C-s foo C-a" produces "foo^A" in the search string here, so I
think the manual is accurate, whereas the comment is wrong.  Are you
saying that you don't see control characters being appended literally,
under this option?

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Juri Linkov]

>>   "However, if you customize the variable ‘search-exit-option’ to ‘nil’,
>>   the characters which you type that are not interpreted by the
>>   incremental search are simply appended to the search string.  This is
>>   so you could include in the search string control characters, such as
>>   ‘C-a’, that would normally exit the search and invoke the command
>>   bound to them on the buffer."
>>
>> But the comment in isearch-pre-command-hook says:
>>
>>   ;; If search-exit-option is nil, run the command without exiting Isearch.
>>
>> So it's not clear what it should do for e.g. motion commands:
>> just move point without exiting Isearch or append control characters
>> of motion keys to the search string?
>
> Typing "C-s foo C-a" produces "foo^A" in the search string here, so I
> think the manual is accurate, whereas the comment is wrong.  Are you
> saying that you don't see control characters being appended literally,
> under this option?

But point jumps to the beginning of the line, so the comment is correct
as well: it runs the command without exiting Isearch, indeed.
So actually it does both: appends control characters and runs the
command, and doing both makes no sense.  Then maybe we should create two
separate options for search-exit-option: one to run the command
and another to append control characters.  But still it's unclear
how to append control characters from such commands as e.g. <right>
bound to ‘right-char’, or ‘M-f’ bound to ‘forward-word’.  When typing them
with search-exit-option customized to nil, I see such errors in *Messages*

  Error in pre-command-hook (isearch-pre-command-hook):
  (wrong-type-argument characterp right)

  Error in pre-command-hook (isearch-pre-command-hook):
  (wrong-type-argument characterp 134217830)

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Sun, 04 Mar 2018 23:36:33 +0200
> 
> > Typing "C-s foo C-a" produces "foo^A" in the search string here, so I
> > think the manual is accurate, whereas the comment is wrong.  Are you
> > saying that you don't see control characters being appended literally,
> > under this option?
> 
> But point jumps to the beginning of the line

Not here, it doesn't.  If it jumps for you, there's something we do
differently.

> So actually it does both: appends control characters and runs the
> command, and doing both makes no sense.  Then maybe we should create two
> separate options for search-exit-option: one to run the command
> and another to append control characters.

Why does it make sense to run the command?

> When typing them with search-exit-option customized to nil, I see
> such errors in *Messages*
> 
>   Error in pre-command-hook (isearch-pre-command-hook):
>   (wrong-type-argument characterp right)
> 
>   Error in pre-command-hook (isearch-pre-command-hook):
>   (wrong-type-argument characterp 134217830)

That's a bug that needs to be fixed, I think.

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Eli Zaretskii]

> Date: Mon, 05 Mar 2018 05:31:11 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > But point jumps to the beginning of the line
> 
> Not here, it doesn't.

Actually, it does.  (I thought you were talking about the line in the
minibuffer, so I didn't look elsewhere.)

> > So actually it does both: appends control characters and runs the
> > command, and doing both makes no sense.  Then maybe we should create two
> > separate options for search-exit-option: one to run the command
> > and another to append control characters.

Probably.  Although I think that the latter is much more important, so
I'd be okay with having only it.

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Juri Linkov]

>> > So actually it does both: appends control characters and runs the
>> > command, and doing both makes no sense.  Then maybe we should create two
>> > separate options for search-exit-option: one to run the command
>> > and another to append control characters.
>
> Probably.  Although I think that the latter is much more important, so
> I'd be okay with having only it.

It makes sense to run the command to move point to other place without
exiting Isearch.  For example, after moving point typing ‘C-s’ works
fine and finds a new match after the new position.

>> When typing them with search-exit-option customized to nil, I see
>> such errors in *Messages*
>> 
>>   Error in pre-command-hook (isearch-pre-command-hook):
>>   (wrong-type-argument characterp right)
>> 
>>   Error in pre-command-hook (isearch-pre-command-hook):
>>   (wrong-type-argument characterp 134217830)
>
> That's a bug that needs to be fixed, I think.

Unfortunately, I have no idea what characters to append to the
search string in such cases.

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Mon, 05 Mar 2018 23:25:38 +0200
> 
> >>   Error in pre-command-hook (isearch-pre-command-hook):
> >>   (wrong-type-argument characterp right)
> >> 
> >>   Error in pre-command-hook (isearch-pre-command-hook):
> >>   (wrong-type-argument characterp 134217830)
> >
> > That's a bug that needs to be fixed, I think.
> 
> Unfortunately, I have no idea what characters to append to the
> search string in such cases.

How about nothing?

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Juri Linkov]

>> >>   Error in pre-command-hook (isearch-pre-command-hook):
>> >>   (wrong-type-argument characterp right)
>> >> 
>> >>   Error in pre-command-hook (isearch-pre-command-hook):
>> >>   (wrong-type-argument characterp 134217830)
>> >
>> > That's a bug that needs to be fixed, I think.
>> 
>> Unfortunately, I have no idea what characters to append to the
>> search string in such cases.
>
> How about nothing?

This reduces the usefulness of this feature.
But OK, here is a new option for it:

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 96faa27..b22a775 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -82,6 +82,7 @@ search-exit-option
                  (const :tag "Edit the search string" edit)
                  (const :tag "Extend the search string by motion commands" move)
                  (const :tag "Extend the search string by shifted motion keys" shift-move)
+                 (const :tag "Append control characters to the search string" append)
                  (const :tag "Don't terminate incremental search" nil))
   :version "27.1")
 
@@ -2452,13 +2453,18 @@ isearch-pre-command-hook
                this-command-keys-shift-translated))
       (setq this-command-keys-shift-translated nil)
       (setq isearch-pre-move-point (point)))
+     ;; Append control characters to the search string
+     ((eq search-exit-option 'append)
+      (when (cl-every #'characterp key)
+        (isearch-process-search-string key key))
+      (setq this-command 'ignore))
      ;; Other characters terminate the search and are then executed normally.
      (search-exit-option
       (isearch-done)
       (isearch-clean-overlays))
      ;; If search-exit-option is nil, run the command without exiting Isearch.
      (t
-      (isearch-process-search-string key key)))))
+      ))))
 
 (defun isearch-post-command-hook ()
   (cond

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Wed, 07 Mar 2018 00:07:46 +0200
> 
> >> >>   Error in pre-command-hook (isearch-pre-command-hook):
> >> >>   (wrong-type-argument characterp right)
> >> >> 
> >> >>   Error in pre-command-hook (isearch-pre-command-hook):
> >> >>   (wrong-type-argument characterp 134217830)
> >> >
> >> > That's a bug that needs to be fixed, I think.
> >> 
> >> Unfortunately, I have no idea what characters to append to the
> >> search string in such cases.
> >
> > How about nothing?
> 
> This reduces the usefulness of this feature.
> But OK, here is a new option for it:

LGTM, thanks.

Re: Let's make C-M-w in isearch yank symbol, not delete character

[John Shahid]

Does it make sense to set the `isearch-move' property on some common
forward commands, e.g. `forward-char', `forward-symbol' &
`forward-word'. I just compiled and tried the latest master to test this
feature and it wasn't immediately obvious that I had to set the property
for those commands. I was confused because I expected the built-in
functions to work out of the box with this new feature.

cheers,

-js

Juri Linkov <juri@linkov.net> writes:

>>> >>   Error in pre-command-hook (isearch-pre-command-hook):
>>> >>   (wrong-type-argument characterp right)
>>> >>
>>> >>   Error in pre-command-hook (isearch-pre-command-hook):
>>> >>   (wrong-type-argument characterp 134217830)
>>> >
>>> > That's a bug that needs to be fixed, I think.
>>>
>>> Unfortunately, I have no idea what characters to append to the
>>> search string in such cases.
>>
>> How about nothing?
>
> This reduces the usefulness of this feature.
> But OK, here is a new option for it:
>
> diff --git a/lisp/isearch.el b/lisp/isearch.el
> index 96faa27..b22a775 100644
> --- a/lisp/isearch.el
> +++ b/lisp/isearch.el
> @@ -82,6 +82,7 @@ search-exit-option
>                   (const :tag "Edit the search string" edit)
>                   (const :tag "Extend the search string by motion commands" move)
>                   (const :tag "Extend the search string by shifted motion keys" shift-move)
> +                 (const :tag "Append control characters to the search string" append)
>                   (const :tag "Don't terminate incremental search" nil))
>    :version "27.1")
>
> @@ -2452,13 +2453,18 @@ isearch-pre-command-hook
>                 this-command-keys-shift-translated))
>        (setq this-command-keys-shift-translated nil)
>        (setq isearch-pre-move-point (point)))
> +     ;; Append control characters to the search string
> +     ((eq search-exit-option 'append)
> +      (when (cl-every #'characterp key)
> +        (isearch-process-search-string key key))
> +      (setq this-command 'ignore))
>       ;; Other characters terminate the search and are then executed normally.
>       (search-exit-option
>        (isearch-done)
>        (isearch-clean-overlays))
>       ;; If search-exit-option is nil, run the command without exiting Isearch.
>       (t
> -      (isearch-process-search-string key key)))))
> +      ))))
>
>  (defun isearch-post-command-hook ()
>    (cond

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Juri Linkov]

> Does it make sense to set the `isearch-move' property on some common
> forward commands, e.g. `forward-char', `forward-symbol' &
> `forward-word'. I just compiled and tried the latest master to test this
> feature and it wasn't immediately obvious that I had to set the property
> for those commands. I was confused because I expected the built-in
> functions to work out of the box with this new feature.

Maybe better to put the `isearch-move' property on the common commands
only when you customize `search-exit-option' to `move' like in this patch:

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 4f5f494..c0f9025 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -86,6 +86,14 @@ search-exit-option
                  (const :tag "Extend the search string by shifted motion keys" shift-move)
                  (const :tag "Append control characters to the search string" append)
                  (const :tag "Don't terminate incremental search" nil))
+  :set #'(lambda (sym val)
+           (when (eq val 'move)
+             (dolist (sym '(right-char right-word forward-char forward-word
+                            forward-symbol forward-sexp next-line move-end-of-line
+                            left-char left-word backward-char backward-word
+                            backward-symbol backward-sexp previous-line))
+               (put sym 'isearch-move t)))
+           (set-default sym val))
   :version "27.1")
 
 (defcustom search-slow-window-lines 1

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Stefan Monnier]

> +  :set #'(lambda (sym val)
> +           (when (eq val 'move)
> +             (dolist (sym '(right-char right-word forward-char forward-word
> +                            forward-symbol forward-sexp next-line move-end-of-line
> +                            left-char left-word backward-char backward-word
> +                            backward-symbol backward-sexp previous-line))
> +               (put sym 'isearch-move t)))
> +           (set-default sym val))

Why only set those properties in the :setter rather tan just do it at
top-level?  Also, would it be possible to avoid having to list those
commands and instead treat as `isearch-move` any command which uses the
handle-shift-selection?


        Stefan

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Juri Linkov]

> Why only set those properties in the :setter rather tan just do it at
> top-level?  Also, would it be possible to avoid having to list those
> commands and instead treat as `isearch-move` any command which uses the
> handle-shift-selection?

Supporting only commands which use the handle-shift-selection
makes the most sense.  I tested this to confirm it works as expected:

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 84b121a..245bf8a 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -2433,8 +2448,8 @@ isearch-pre-command-hook
       (setq this-command 'isearch-edit-string))
      ;; Don't terminate the search for motion commands.
      ((or (and (eq search-exit-option 'move)
-               (symbolp this-command)
-               (eq (get this-command 'isearch-move) t))
+               (stringp (nth 1 (interactive-form this-command)))
+               (string-match-p "^^" (nth 1 (interactive-form this-command))))
           (and (eq search-exit-option 'shift-move)
                this-command-keys-shift-translated))
       (setq this-command-keys-shift-translated nil)

Re: Let's make C-M-w in isearch yank symbol, not delete character

[John Shahid]

+1

Juri Linkov <juri@linkov.net> writes:

>> Why only set those properties in the :setter rather tan just do it at
>> top-level?  Also, would it be possible to avoid having to list those
>> commands and instead treat as `isearch-move` any command which uses the
>> handle-shift-selection?
>
> Supporting only commands which use the handle-shift-selection
> makes the most sense.  I tested this to confirm it works as expected:
>
> diff --git a/lisp/isearch.el b/lisp/isearch.el
> index 84b121a..245bf8a 100644
> --- a/lisp/isearch.el
> +++ b/lisp/isearch.el
> @@ -2433,8 +2448,8 @@ isearch-pre-command-hook
>        (setq this-command 'isearch-edit-string))
>       ;; Don't terminate the search for motion commands.
>       ((or (and (eq search-exit-option 'move)
> -               (symbolp this-command)
> -               (eq (get this-command 'isearch-move) t))
> +               (stringp (nth 1 (interactive-form this-command)))
> +               (string-match-p "^^" (nth 1 (interactive-form this-command))))
>            (and (eq search-exit-option 'shift-move)
>                 this-command-keys-shift-translated))
>        (setq this-command-keys-shift-translated nil)

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Alan Mackenzie]

Hello, Juri.

On Sun, Mar 11, 2018 at 23:52:58 +0200, Juri Linkov wrote:
> > Why only set those properties in the :setter rather tan just do it at
> > top-level?  Also, would it be possible to avoid having to list those
> > commands and instead treat as `isearch-move` any command which uses the
> > handle-shift-selection?

> Supporting only commands which use the handle-shift-selection
> makes the most sense.  I tested this to confirm it works as expected:

> diff --git a/lisp/isearch.el b/lisp/isearch.el
> index 84b121a..245bf8a 100644
> --- a/lisp/isearch.el
> +++ b/lisp/isearch.el
> @@ -2433,8 +2448,8 @@ isearch-pre-command-hook
>        (setq this-command 'isearch-edit-string))
>       ;; Don't terminate the search for motion commands.
>       ((or (and (eq search-exit-option 'move)
> -               (symbolp this-command)
> -               (eq (get this-command 'isearch-move) t))
> +               (stringp (nth 1 (interactive-form this-command)))
> +               (string-match-p "^^" (nth 1 (interactive-form this-command))))
>            (and (eq search-exit-option 'shift-move)
>                 this-command-keys-shift-translated))
>        (setq this-command-keys-shift-translated nil)

Please don't do this.  handle-shift-selection (whatever that might be)
is a different feature from the isearch extension, and users should be
able to customize them independently from each other.  Correction: MUST
be able to customize them independently.

Although I haven't been following this thread all that closely, I'm a
little perturbed that in the space of little over a week, a small
definite proposal which makes a lot of sense has swollen into a
significant redesign of isearch, and an incompatible one at that.

Disclosure: I've had an isearch-yank-symbol bound to C-S-w in my
isearch-mode-map for several years.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Juri Linkov]

>> > Why only set those properties in the :setter rather tan just do it at
>> > top-level?  Also, would it be possible to avoid having to list those
>> > commands and instead treat as `isearch-move` any command which uses the
>> > handle-shift-selection?
>
>> Supporting only commands which use the handle-shift-selection
>> makes the most sense.  I tested this to confirm it works as expected:
>
>> diff --git a/lisp/isearch.el b/lisp/isearch.el
>> index 84b121a..245bf8a 100644
>> --- a/lisp/isearch.el
>> +++ b/lisp/isearch.el
>> @@ -2433,8 +2448,8 @@ isearch-pre-command-hook
>>        (setq this-command 'isearch-edit-string))
>>       ;; Don't terminate the search for motion commands.
>>       ((or (and (eq search-exit-option 'move)
>> -               (symbolp this-command)
>> -               (eq (get this-command 'isearch-move) t))
>> +               (stringp (nth 1 (interactive-form this-command)))
>> +               (string-match-p "^^" (nth 1 (interactive-form this-command))))
>>            (and (eq search-exit-option 'shift-move)
>>                 this-command-keys-shift-translated))
>>        (setq this-command-keys-shift-translated nil)
>
> Please don't do this.  handle-shift-selection (whatever that might be)
> is a different feature from the isearch extension, and users should be
> able to customize them independently from each other.  Correction: MUST
> be able to customize them independently.

This solution avoids the flaws of the isearch-allow-scroll feature 
that causes "customization hell" by requiring maintaining a long list of
(put 'command 'isearch-scroll t) minutiae, and requiring adding the same
for every new command.  The feature should be smart enough to deduce
a reasonable default set of supported commands, and adjustable enough
to allow adding/deleting commands to/from the default set.

> Although I haven't been following this thread all that closely, I'm a
> little perturbed that in the space of little over a week, a small
> definite proposal which makes a lot of sense has swollen into a
> significant redesign of isearch, and an incompatible one at that.

The main sub-thread was renamed to the subject "Isearch interaction model"
where we are discussing significant changes such as merging regex and
regular histories into a unified history, integrating find-and-replace
into isearch, keeping toggleable parameters between searches, etc.

> Disclosure: I've had an isearch-yank-symbol bound to C-S-w in my
> isearch-mode-map for several years.

Now isearch-yank-symbol is bound to C-M-w, so you can use the default key.

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Juri Linkov]

>>> > Why only set those properties in the :setter rather tan just do it at
>>> > top-level?  Also, would it be possible to avoid having to list those
>>> > commands and instead treat as `isearch-move` any command which uses the
>>> > handle-shift-selection?
>>
>>> Supporting only commands which use the handle-shift-selection
>>> makes the most sense.  I tested this to confirm it works as expected:
>>
>>> diff --git a/lisp/isearch.el b/lisp/isearch.el
>>> index 84b121a..245bf8a 100644
>>> --- a/lisp/isearch.el
>>> +++ b/lisp/isearch.el
>>> @@ -2433,8 +2448,8 @@ isearch-pre-command-hook
>>>        (setq this-command 'isearch-edit-string))
>>>       ;; Don't terminate the search for motion commands.
>>>       ((or (and (eq search-exit-option 'move)
>>> -               (symbolp this-command)
>>> -               (eq (get this-command 'isearch-move) t))
>>> +               (stringp (nth 1 (interactive-form this-command)))
>>> +               (string-match-p "^^" (nth 1 (interactive-form this-command))))
>>>            (and (eq search-exit-option 'shift-move)
>>>                 this-command-keys-shift-translated))
>>>        (setq this-command-keys-shift-translated nil)
>>
>> Please don't do this.  handle-shift-selection (whatever that might be)
>> is a different feature from the isearch extension, and users should be
>> able to customize them independently from each other.  Correction: MUST
>> be able to customize them independently.
>
> This solution avoids the flaws of the isearch-allow-scroll feature 
> that causes "customization hell" by requiring maintaining a long list of
> (put 'command 'isearch-scroll t) minutiae, and requiring adding the same
> for every new command.  The feature should be smart enough to deduce
> a reasonable default set of supported commands, and adjustable enough
> to allow adding/deleting commands to/from the default set.

This patch clarifies the idea:

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 84b121a..56a44d8 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -2434,7 +2449,10 @@ isearch-pre-command-hook
      ;; Don't terminate the search for motion commands.
      ((or (and (eq search-exit-option 'move)
                (symbolp this-command)
-               (eq (get this-command 'isearch-move) t))
+               (or (eq (get this-command 'isearch-move) 'enabled)
+                   (and (not (eq (get this-command 'isearch-move) 'disabled))
+                        (stringp (nth 1 (interactive-form this-command)))
+                        (string-match-p "^^" (nth 1 (interactive-form this-command))))))
           (and (eq search-exit-option 'shift-move)
                this-command-keys-shift-translated))
       (setq this-command-keys-shift-translated nil)

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 10 Mar 2018 23:15:19 +0200
> 
> > Does it make sense to set the `isearch-move' property on some common
> > forward commands, e.g. `forward-char', `forward-symbol' &
> > `forward-word'. I just compiled and tried the latest master to test this
> > feature and it wasn't immediately obvious that I had to set the property
> > for those commands. I was confused because I expected the built-in
> > functions to work out of the box with this new feature.
> 
> Maybe better to put the `isearch-move' property on the common commands
> only when you customize `search-exit-option' to `move' like in this patch:

If this eventually is committed with the setter function, the doc
string should warn users that just setting the variable directly does
not do what they expect.  For the same reason, the setter should be a
function with a name, so it could be called from Lisp.

Thanks.

Re: Let's make C-M-w in isearch yank symbol, not delete character

[Herring, Davis]

> Maybe better to put the `isearch-move' property on the common commands
> only when you customize `search-exit-option' to `move' like in this patch:

Not sure why you'd want to do this...

> +           (when (eq val 'move)

...but if so, you'd have to remove the properties if the option got changed again.

Davis