isearch region or thing at point.

isearch region or thing at point.

[Ergus]

Hi:

I am looking in the manual for two isearch functionalities that maybe
are already implemented, but I don't find them. Else maybe it is not
so complex to do in elisp (at least for my config) And you could suggest
a right way to implement it.

1) isearch-yank-thing-at-point, this should be similar to
isearch-yank-word, but if the cursor is in the middle of a word
it may insert the whole word not just the rest of the current word.

(swiper provides this with M-n)

2) In "transient-mark-mode" if the region is active before C-s, the
initial input could be the text in the region. Is it there a way to
enable that behavior?

An alternative for this is a command that yanks the region's text in the
minibuffer when isearch is active so we could bind it in the isearch-map
(for example to M-f).

Are some of these already implemented?

Very thanks in advance,
Ergus.

Re: isearch region or thing at point.

[Basil L. Contovounesios]

Ergus <spacibba@aol.com> writes:

> I am looking in the manual for two isearch functionalities that maybe
> are already implemented, but I don't find them. Else maybe it is not
> so complex to do in elisp (at least for my config) And you could suggest
> a right way to implement it.
>
> 1) isearch-yank-thing-at-point, this should be similar to
> isearch-yank-word, but if the cursor is in the middle of a word
> it may insert the whole word not just the rest of the current word.
>
> (swiper provides this with M-n)

The closest to this that I'm aware of is
isearch-forward-symbol-at-point, bound to 'M-s .' by default.

> 2) In "transient-mark-mode" if the region is active before C-s, the
> initial input could be the text in the region. Is it there a way to
> enable that behavior?
>
> An alternative for this is a command that yanks the region's text in the
> minibuffer when isearch is active so we could bind it in the isearch-map
> (for example to M-f).
>
> Are some of these already implemented?

I'm not familiar with any built-in versions of the rest of the
functionality you describe, but I'm no expert.  If it is indeed not
currently present, I for one would welcome such additions.

Thanks,

-- 
Basil

Re: isearch region or thing at point.

[Ergus]

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

On Sat, Apr 27, 2019 at 03:15:21AM +0100, Basil L. Contovounesios wrote:
>Ergus <spacibba@aol.com> writes:
>
>> I am looking in the manual for two isearch functionalities that maybe
>> are already implemented, but I don't find them. Else maybe it is not
>> so complex to do in elisp (at least for my config) And you could suggest
>> a right way to implement it.
>>
>> 1) isearch-yank-thing-at-point, this should be similar to
>> isearch-yank-word, but if the cursor is in the middle of a word
>> it may insert the whole word not just the rest of the current word.
>>
>> (swiper provides this with M-n)
>
>The closest to this that I'm aware of is
>isearch-forward-symbol-at-point, bound to 'M-s .' by default.
>
>> 2) In "transient-mark-mode" if the region is active before C-s, the
>> initial input could be the text in the region. Is it there a way to
>> enable that behavior?
>>
>> An alternative for this is a command that yanks the region's text in the
>> minibuffer when isearch is active so we could bind it in the isearch-map
>> (for example to M-f).
>>
>> Are some of these already implemented?
>
>I'm not familiar with any built-in versions of the rest of the
>functionality you describe, but I'm no expert.  If it is indeed not
>currently present, I for one would welcome such additions.
>
>Thanks,
>
>-- 
>Basil
>
Hi Basil:

I just made a small change in isearch.el to enable region text auto
insertion in transient-mark-mode. (patch attached)

I did it as simple as I could. So please if you (or any anyone) could
give a look and correct/improve/expose corner cases, or suggest a better
implementation will be very nice.

I don't have corner cases right now, but I just started testing it.

So any correction/suggestion/recommendation is very appreciated.

Thanks in advance,

Ergus


[-- Attachment #2: isearch-autoinsert.patch --]
[-- Type: text/plain, Size: 2185 bytes --]

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 6280afebdc..3de0493c8a 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -413,6 +413,17 @@ and doesn't remove full-buffer highlighting after a search."
   :group 'lazy-count
   :version "27.1")
 
+(defcustom isearch-autoinsert-region nil
+  "If non-nil, the text in the region will be auto-inserted for searching.
+This works only if the variable `transient-mark-mode' is enabled
+and the region is active."
+  :type 'boolean
+  :group 'isearch
+  :version "27.1")
+
+(defvar isearch-deactivated-mark nil
+  "If for some reason isearch removed the mark on start.")
+
 \f
 ;; Define isearch help map.
 
@@ -1205,7 +1216,8 @@ used to set the value of `isearch-regexp-function'."
 	;; Save the original value of `minibuffer-message-timeout', and
 	;; set it to nil so that isearch's messages don't get timed out.
 	isearch-original-minibuffer-message-timeout minibuffer-message-timeout
-	minibuffer-message-timeout nil)
+	minibuffer-message-timeout nil
+        isearch-deactivated-mark nil)
 
   (if (local-variable-p 'tool-bar-map)
       (setq isearch-tool-bar-old-map tool-bar-map))
@@ -1244,6 +1256,15 @@ used to set the value of `isearch-regexp-function'."
   ;; `isearch-push-state' to save mode-specific initial state.  (Bug#4994)
   (isearch-push-state)
 
+  (when (and isearch-autoinsert-region  ;; Check option
+             (use-region-p)
+             (not (region-noncontiguous-p))
+             (= (count-lines (region-beginning) (region-end)) 1))
+    (isearch-yank-string
+     (buffer-substring-no-properties (region-beginning) (region-end)))
+    (setq mark-active nil
+          isearch-deactivated-mark t))
+
   (isearch-update)
 
   (add-hook 'pre-command-hook 'isearch-pre-command-hook)
@@ -1782,6 +1803,9 @@ The following additional command keys are active while editing.
 	(isearch--set-state (car isearch-cmds)))
     (goto-char isearch-opoint))
   (isearch-done t)                      ; Exit isearch..
+  (when isearch-deactivated-mark
+    (setq isearch-deactivated-mark nil
+          activate-mark t)
   (isearch-clean-overlays)
   (signal 'quit nil))                   ; ..and pass on quit signal.
 

Re: isearch region or thing at point.

[Ergus]

Patch update:

Sorry, the last one was a wrong one. 

On Mon, Apr 29, 2019 at 02:41:35AM +0200, Ergus wrote:
>On Sat, Apr 27, 2019 at 03:15:21AM +0100, Basil L. Contovounesios wrote:
>>Ergus <spacibba@aol.com> writes:
>>
>>>I am looking in the manual for two isearch functionalities that maybe
>>>are already implemented, but I don't find them. Else maybe it is not
>>>so complex to do in elisp (at least for my config) And you could suggest
>>>a right way to implement it.
>>>
>>>1) isearch-yank-thing-at-point, this should be similar to
>>>isearch-yank-word, but if the cursor is in the middle of a word
>>>it may insert the whole word not just the rest of the current word.
>>>
>>>(swiper provides this with M-n)
>>
>>The closest to this that I'm aware of is
>>isearch-forward-symbol-at-point, bound to 'M-s .' by default.
>>
>>>2) In "transient-mark-mode" if the region is active before C-s, the
>>>initial input could be the text in the region. Is it there a way to
>>>enable that behavior?
>>>
>>>An alternative for this is a command that yanks the region's text in the
>>>minibuffer when isearch is active so we could bind it in the isearch-map
>>>(for example to M-f).
>>>
>>>Are some of these already implemented?
>>
>>I'm not familiar with any built-in versions of the rest of the
>>functionality you describe, but I'm no expert.  If it is indeed not
>>currently present, I for one would welcome such additions.
>>
>>Thanks,
>>
>>-- 
>>Basil
>>
>Hi Basil:
>
>I just made a small change in isearch.el to enable region text auto
>insertion in transient-mark-mode. (patch attached)
>
>I did it as simple as I could. So please if you (or any anyone) could
>give a look and correct/improve/expose corner cases, or suggest a better
>implementation will be very nice.
>
>I don't have corner cases right now, but I just started testing it.
>
>So any correction/suggestion/recommendation is very appreciated.
>
>Thanks in advance,
>
>Ergus
>

>diff --git a/lisp/isearch.el b/lisp/isearch.el
>index 6280afebdc..3de0493c8a 100644
>--- a/lisp/isearch.el
>+++ b/lisp/isearch.el
>@@ -413,6 +413,17 @@ and doesn't remove full-buffer highlighting after a search."
>   :group 'lazy-count
>   :version "27.1")
>
>+(defcustom isearch-autoinsert-region nil
>+  "If non-nil, the text in the region will be auto-inserted for searching.
>+This works only if the variable `transient-mark-mode' is enabled
>+and the region is active."
>+  :type 'boolean
>+  :group 'isearch
>+  :version "27.1")
>+
>+(defvar isearch-deactivated-mark nil
>+  "If for some reason isearch removed the mark on start.")
>+
> \f
> ;; Define isearch help map.
>
>@@ -1205,7 +1216,8 @@ used to set the value of `isearch-regexp-function'."
> 	;; Save the original value of `minibuffer-message-timeout', and
> 	;; set it to nil so that isearch's messages don't get timed out.
> 	isearch-original-minibuffer-message-timeout minibuffer-message-timeout
>-	minibuffer-message-timeout nil)
>+	minibuffer-message-timeout nil
>+        isearch-deactivated-mark nil)
>
>   (if (local-variable-p 'tool-bar-map)
>       (setq isearch-tool-bar-old-map tool-bar-map))
>@@ -1244,6 +1256,15 @@ used to set the value of `isearch-regexp-function'."
>   ;; `isearch-push-state' to save mode-specific initial state.  (Bug#4994)
>   (isearch-push-state)
>
>+  (when (and isearch-autoinsert-region  ;; Check option
>+             (use-region-p)
>+             (not (region-noncontiguous-p))
>+             (= (count-lines (region-beginning) (region-end)) 1))
>+    (isearch-yank-string
>+     (buffer-substring-no-properties (region-beginning) (region-end)))
>+    (setq mark-active nil
>+          isearch-deactivated-mark t))
>+
>   (isearch-update)
>
>   (add-hook 'pre-command-hook 'isearch-pre-command-hook)
>@@ -1782,6 +1803,9 @@ The following additional command keys are active while editing.
> 	(isearch--set-state (car isearch-cmds)))
>     (goto-char isearch-opoint))
>   (isearch-done t)                      ; Exit isearch..
>+  (when isearch-deactivated-mark
>+    (setq isearch-deactivated-mark nil
>+          activate-mark t)
>   (isearch-clean-overlays)
>   (signal 'quit nil))                   ; ..and pass on quit signal.
>

Re: isearch region or thing at point.

[Ergus]

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

On Mon, Apr 29, 2019 at 02:41:35AM +0200, Ergus wrote:
>On Sat, Apr 27, 2019 at 03:15:21AM +0100, Basil L. Contovounesios wrote:
>>Ergus <spacibba@aol.com> writes:
>>
>>>I am looking in the manual for two isearch functionalities that maybe
>>>are already implemented, but I don't find them. Else maybe it is not
>>>so complex to do in elisp (at least for my config) And you could suggest
>>>a right way to implement it.
>>>
>>>1) isearch-yank-thing-at-point, this should be similar to
>>>isearch-yank-word, but if the cursor is in the middle of a word
>>>it may insert the whole word not just the rest of the current word.
>>>
>>>(swiper provides this with M-n)
>>
>>The closest to this that I'm aware of is
>>isearch-forward-symbol-at-point, bound to 'M-s .' by default.
>>
>>>2) In "transient-mark-mode" if the region is active before C-s, the
>>>initial input could be the text in the region. Is it there a way to
>>>enable that behavior?
>>>
>>>An alternative for this is a command that yanks the region's text in the
>>>minibuffer when isearch is active so we could bind it in the isearch-map
>>>(for example to M-f).
>>>
>>>Are some of these already implemented?
>>
>>I'm not familiar with any built-in versions of the rest of the
>>functionality you describe, but I'm no expert.  If it is indeed not
>>currently present, I for one would welcome such additions.
>>
>>Thanks,
>>
>>-- 
>>Basil
>>
>Hi Basil:
>
>I just made a small change in isearch.el to enable region text auto
>insertion in transient-mark-mode. (patch attached)
>
>I did it as simple as I could. So please if you (or any anyone) could
>give a look and correct/improve/expose corner cases, or suggest a better
>implementation will be very nice.
>
>I don't have corner cases right now, but I just started testing it.
>
>So any correction/suggestion/recommendation is very appreciated.
>
>Thanks in advance,
>
>Ergus
>

>diff --git a/lisp/isearch.el b/lisp/isearch.el
>index 6280afebdc..3de0493c8a 100644
>--- a/lisp/isearch.el
>+++ b/lisp/isearch.el
>@@ -413,6 +413,17 @@ and doesn't remove full-buffer highlighting after a search."
>   :group 'lazy-count
>   :version "27.1")
>
>+(defcustom isearch-autoinsert-region nil
>+  "If non-nil, the text in the region will be auto-inserted for searching.
>+This works only if the variable `transient-mark-mode' is enabled
>+and the region is active."
>+  :type 'boolean
>+  :group 'isearch
>+  :version "27.1")
>+
>+(defvar isearch-deactivated-mark nil
>+  "If for some reason isearch removed the mark on start.")
>+
> \f
> ;; Define isearch help map.
>
>@@ -1205,7 +1216,8 @@ used to set the value of `isearch-regexp-function'."
> 	;; Save the original value of `minibuffer-message-timeout', and
> 	;; set it to nil so that isearch's messages don't get timed out.
> 	isearch-original-minibuffer-message-timeout minibuffer-message-timeout
>-	minibuffer-message-timeout nil)
>+	minibuffer-message-timeout nil
>+        isearch-deactivated-mark nil)
>
>   (if (local-variable-p 'tool-bar-map)
>       (setq isearch-tool-bar-old-map tool-bar-map))
>@@ -1244,6 +1256,15 @@ used to set the value of `isearch-regexp-function'."
>   ;; `isearch-push-state' to save mode-specific initial state.  (Bug#4994)
>   (isearch-push-state)
>
>+  (when (and isearch-autoinsert-region  ;; Check option
>+             (use-region-p)
>+             (not (region-noncontiguous-p))
>+             (= (count-lines (region-beginning) (region-end)) 1))
>+    (isearch-yank-string
>+     (buffer-substring-no-properties (region-beginning) (region-end)))
>+    (setq mark-active nil
>+          isearch-deactivated-mark t))
>+
>   (isearch-update)
>
>   (add-hook 'pre-command-hook 'isearch-pre-command-hook)
>@@ -1782,6 +1803,9 @@ The following additional command keys are active while editing.
> 	(isearch--set-state (car isearch-cmds)))
>     (goto-char isearch-opoint))
>   (isearch-done t)                      ; Exit isearch..
>+  (when isearch-deactivated-mark
>+    (setq isearch-deactivated-mark nil
>+          activate-mark t)
>   (isearch-clean-overlays)
>   (signal 'quit nil))                   ; ..and pass on quit signal.
>


[-- Attachment #2: isearch-autoinsert.patch --]
[-- Type: text/plain, Size: 2407 bytes --]

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 6280afebdc..d5cfceb57c 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -413,6 +413,17 @@ and doesn't remove full-buffer highlighting after a search."
   :group 'lazy-count
   :version "27.1")
 
+(defcustom isearch-autoinsert-region nil
+  "If non-nil, the text in the region will be auto-inserted for searching.
+This works only if the variable `transient-mark-mode' is enabled
+and the region is active."
+  :type 'boolean
+  :group 'isearch
+  :version "27.1")
+
+(defvar isearch-deactivated-mark nil
+  "If for some reason isearch removed the mark on start.")
+
 \f
 ;; Define isearch help map.
 
@@ -1205,7 +1216,8 @@ used to set the value of `isearch-regexp-function'."
 	;; Save the original value of `minibuffer-message-timeout', and
 	;; set it to nil so that isearch's messages don't get timed out.
 	isearch-original-minibuffer-message-timeout minibuffer-message-timeout
-	minibuffer-message-timeout nil)
+	minibuffer-message-timeout nil
+        isearch-deactivated-mark nil)
 
   (if (local-variable-p 'tool-bar-map)
       (setq isearch-tool-bar-old-map tool-bar-map))
@@ -1244,6 +1256,22 @@ used to set the value of `isearch-regexp-function'."
   ;; `isearch-push-state' to save mode-specific initial state.  (Bug#4994)
   (isearch-push-state)
 
+  (when (and isearch-autoinsert-region  ;; Check option
+             (use-region-p)
+             (not (region-noncontiguous-p))
+             (= (count-lines (region-beginning) (region-end)) 1)
+             (string-empty-p isearch-string))
+
+    (let ((region-string (buffer-substring-no-properties
+                         (region-beginning) (region-end))))
+      (if isearch-forward
+          (goto-char (region-beginning))
+        (goto-char (region-end)))
+      (isearch-yank-string region-string)
+
+      (setq mark-active nil
+            isearch-deactivated-mark t)))
+
   (isearch-update)
 
   (add-hook 'pre-command-hook 'isearch-pre-command-hook)
@@ -1782,6 +1810,9 @@ The following additional command keys are active while editing.
 	(isearch--set-state (car isearch-cmds)))
     (goto-char isearch-opoint))
   (isearch-done t)                      ; Exit isearch..
+  (when isearch-deactivated-mark
+    (setq isearch-deactivated-mark nil
+          mark-active t))
   (isearch-clean-overlays)
   (signal 'quit nil))                   ; ..and pass on quit signal.
 

Re: isearch region or thing at point.

[Juri Linkov]

>>The closest to this that I'm aware of is
>>isearch-forward-symbol-at-point, bound to 'M-s .' by default.
>>
> I just made a small change in isearch.el to enable region text auto
> insertion in transient-mark-mode. (patch attached)
>
> I did it as simple as I could. So please if you (or any anyone) could
> give a look and correct/improve/expose corner cases, or suggest a better
> implementation will be very nice.
>
> I don't have corner cases right now, but I just started testing it.
>
> So any correction/suggestion/recommendation is very appreciated.

Thanks, such addition is welcome.  Currently searching the
active region requires invocation of several commands: M-w C-s M-y
with a bad side-effect of leaving the region in the kill-ring.

However, adding a new option is not a satisfactory solution
because often isearch is used to extend the boundaries of the
active region, e.g. by setting the region's beginning with C-SPC,
then searching the region's end and exiting isearch there.

Fortunately, like Basil mentioned the command isearch-forward-symbol-at-point
bound to 'M-s .' you could create a similar command bound to e.g. 'M-s r'
that would start isearch with the text from the active region.

Re: isearch region or thing at point.

[Ergus]

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

Hi Juri:

Thanks for replying. I will try a different implementation like the one you suggested.

 But any way, in the previous patch could be easier just add more conditions to filter and keep backward compatibility with the current behaviour. (For example looking if the command just started, or providing the actual region as a hint, look if the command was called interactively, add the extra code in the search-forward function only when the region in not empty and so on. I would prefer such solutions to avoid forcing the user to learn new bindings.

In fact C-spc + isearch is something I use constantly and I haven't have any issue today.

But I understand that there should be corner cases I don't know. And usually add features that potentially changes any detail in Emacs always finish in strong discussions in this mailing list.

So I prefer to avoid that.

Very thanks for your reply.


On April 29, 2019 9:41:28 PM GMT+02:00, Juri Linkov <juri@linkov.net> wrote:
>>>The closest to this that I'm aware of is
>>>isearch-forward-symbol-at-point, bound to 'M-s .' by default.
>>>
>> I just made a small change in isearch.el to enable region text auto
>> insertion in transient-mark-mode. (patch attached)
>>
>> I did it as simple as I could. So please if you (or any anyone) could
>> give a look and correct/improve/expose corner cases, or suggest a
>better
>> implementation will be very nice.
>>
>> I don't have corner cases right now, but I just started testing it.
>>
>> So any correction/suggestion/recommendation is very appreciated.
>
>Thanks, such addition is welcome.  Currently searching the
>active region requires invocation of several commands: M-w C-s M-y
>with a bad side-effect of leaving the region in the kill-ring.
>
>However, adding a new option is not a satisfactory solution
>because often isearch is used to extend the boundaries of the
>active region, e.g. by setting the region's beginning with C-SPC,
>then searching the region's end and exiting isearch there.
>
>Fortunately, like Basil mentioned the command
>isearch-forward-symbol-at-point
>bound to 'M-s .' you could create a similar command bound to e.g. 'M-s
>r'
>that would start isearch with the text from the active region.

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

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

RE: isearch region or thing at point.

[Drew Adams]

> Thanks, such addition is welcome.  Currently searching the
> active region requires invocation of several commands: M-w C-s M-y
> with a bad side-effect of leaving the region in the kill-ring.
> 
> However, adding a new option is not a satisfactory solution
> because often isearch is used to extend the boundaries of the
> active region, e.g. by setting the region's beginning with C-SPC,
> then searching the region's end and exiting isearch there.
> 
> Fortunately, like Basil mentioned the command isearch-forward-symbol-at-point
> bound to 'M-s .' you could create a similar command bound to e.g. 'M-s r'
> that would start isearch with the text from the active region.

My own take on this:

1. A user option is helpful (only) for users who really
   want this behavior all the time.  Unless, that is,
   Emacs decides to let users toggle the option with a
   (search-map) key.  Vanilla Emacs doesn't like to do
   that, opting instead for using a non-option variable
   (letting you toggle that).

2. It's already simple to search for the region text, as
   Juri points out: `M-w C-s M-y'.  And as he says, you
   can easily define a command that does that from the
   outset.

   FWIW, as one user, I don't have a problem with `M-w'
   adding the region text to the kill-ring.  I don't see
   that as a "bad side-effect" but rather as something
   often useful.  But sure, you can make searching for
   selected text be independent from adding that text to
   the kill-ring.

   If you set option `mouse-drag-copy-region' to non-nil
   then text selected with the mouse is automatically
   added to the kill-ring, so you can just use `M-y'
   during search to yank it.

3. There are several different ways the active region
   can be useful for Isearch.  Juri mentioned one:
   extend the region end to a searched position.  Each
   way to use the region should be optional, and
   sometimes some of them can be combined.  Whatever you
   provide, please make it optional.

   By way of example, here are some ways the region can
   be used for Isearch that are offered by library
   Isearch+ as optional behaviors:

   a. Search only within the active region: option
      `isearchp-restrict-to-region-flag' - toggle with
      `C-x n' while searching.

   b. Show match numbers only for search hits within
      the region (has an effect only when search is
      limited to the region): option
      `isearchp-limit-match-numbers-to-region-flag' -
      toggle with `M-s %' while searching.

   c. Deactivate the region for Isearch: option
      `isearchp-deactivate-region-flag' - toggle with
      `C-SPC C-SPC' while searching.

   d. Select the last search or query-replace target,
      that is, make it the active region.  Do this
      either per option `isearchp-set-region-flag'
      (toggle with `M-s M-SPC' while searching) or on
      demand: `isearchp-set-region-around-search-target'.

   e. Create a noncontiguous region from the
      lazy-highlighted text (search hits): `M-s z r'
      while searching.

   f. Add/remove a text property to/from the region.
      Search only areas that have that property with
      particular values.  Works also for overlays.

   g. Search outside the area that would normally be
      searched (e.g. the region or a set of zones).
      That is, complement the search space.  Toggle
      with `M-= ~' while searching.

   There are no doubt other ways the region can be
   used for Isearch.  We should not assume that
   there's only one thing users might want to do
   with it.  Keep their, and our, options open.

[https://www.emacswiki.org/emacs/IsearchPlus]

Re: isearch region or thing at point.

[Ergus]

On Tue, Apr 30, 2019 at 08:39:56AM -0700, Drew Adams wrote:
>> Thanks, such addition is welcome.  Currently searching the
>> active region requires invocation of several commands: M-w C-s M-y
>> with a bad side-effect of leaving the region in the kill-ring.
>>
>> However, adding a new option is not a satisfactory solution
>> because often isearch is used to extend the boundaries of the
>> active region, e.g. by setting the region's beginning with C-SPC,
>> then searching the region's end and exiting isearch there.
>>
>> Fortunately, like Basil mentioned the command isearch-forward-symbol-at-point
>> bound to 'M-s .' you could create a similar command bound to e.g. 'M-s r'
>> that would start isearch with the text from the active region.
>

Hi Drew, very thanks for replying:

>My own take on this:
>
>1. A user option is helpful (only) for users who really
>   want this behavior all the time.  Unless, that is,
>   Emacs decides to let users toggle the option with a
>   (search-map) key.  Vanilla Emacs doesn't like to do
>   that, opting instead for using a non-option variable
>   (letting you toggle that).
>
Ok, got it

>2. It's already simple to search for the region text, as
>   Juri points out: `M-w C-s M-y'.  And as he says, you
>   can easily define a command that does that from the
>   outset.
>
Of course the user could write anything, but this is a simple basic
functionality available in gedit, geany, vim, qtcreator... but also in
firefox, chromium, and so on... So, there is not any reason why emacs
will provide no "easy" way to enable/access it somehow.

Specially for the detail that we don't disable the region after the
search was canceled. That's a more intuitive behavior.

(Is a problem of simplicity and effort for the user)
>
>   FWIW, as one user, I don't have a problem with `M-w'
>   adding the region text to the kill-ring.  I don't see
>   that as a "bad side-effect" but rather as something
>   often useful.  But sure, you can make searching for
>   selected text be independent from adding that text to
>   the kill-ring.
>
Touching the kill-ring for a simple search is unnatural, but also the
command is extremely long (and sparse in the keyboard) for something
that any programmed needs every 5 minutes.
>   If you set option `mouse-drag-copy-region' to non-nil
>   then text selected with the mouse is automatically
>   added to the kill-ring, so you can just use `M-y'
>   during search to yank it.
>
In my opinion Emacs should be equally functional with and without the
mouse. There are people (like me) that still use emacs only in terminal
mode.
>3. There are several different ways the active region
>   can be useful for Isearch.  Juri mentioned one:
>   extend the region end to a searched position.  Each
>   way to use the region should be optional, and
>   sometimes some of them can be combined.  Whatever you
>   provide, please make it optional.
>
>   By way of example, here are some ways the region can
>   be used for Isearch that are offered by library
>   Isearch+ as optional behaviors:
>
>   a. Search only within the active region: option
>      `isearchp-restrict-to-region-flag' - toggle with
>      `C-x n' while searching.
>
>   b. Show match numbers only for search hits within
>      the region (has an effect only when search is
>      limited to the region): option
>      `isearchp-limit-match-numbers-to-region-flag' -
>      toggle with `M-s %' while searching.
>
>   c. Deactivate the region for Isearch: option
>      `isearchp-deactivate-region-flag' - toggle with
>      `C-SPC C-SPC' while searching.
>
>   d. Select the last search or query-replace target,
>      that is, make it the active region.  Do this
>      either per option `isearchp-set-region-flag'
>      (toggle with `M-s M-SPC' while searching) or on
>      demand: `isearchp-set-region-around-search-target'.
>
>   e. Create a noncontiguous region from the
>      lazy-highlighted text (search hits): `M-s z r'
>      while searching.
>
>   f. Add/remove a text property to/from the region.
>      Search only areas that have that property with
>      particular values.  Works also for overlays.
>
>   g. Search outside the area that would normally be
>      searched (e.g. the region or a set of zones).
>      That is, complement the search space.  Toggle
>      with `M-= ~' while searching.
>
>   There are no doubt other ways the region can be
>   used for Isearch.  We should not assume that
>   there's only one thing users might want to do
>   with it.  Keep their, and our, options open.
>
>[https://www.emacswiki.org/emacs/IsearchPlus]
>
Actually I am only considering the option of adding a new function and
bind it to M-s r.

Or add a C-something like isearch-yank-word-or-char.

(because I know that core option changes is complicated to agree in the
list, and I don't like to spend hours on that.)

Re: isearch region or thing at point.

[Juri Linkov]

>>> But any way, in the previous patch could be easier just add more
>>> conditions to filter and keep backward compatibility with the current
>>> behaviour. (For example looking if the command just started, or providing
>>> the actual region as a hint, look if the command was called interactively,
>>> add the extra code in the search-forward function only when the region in
>>> not empty and so on. I would prefer such solutions to avoid forcing the
>>> user to learn new bindings.

I can't come up with a heuristic rule that would guess the user's intention
to use the text from the active region as the search string.

>>2. It's already simple to search for the region text, as
>>   Juri points out: `M-w C-s M-y'.  And as he says, you
>>   can easily define a command that does that from the
>>   outset.
>
> Of course the user could write anything, but this is a simple basic
> functionality available in gedit, geany, vim, qtcreator... but also in
> firefox, chromium, and so on... So, there is not any reason why emacs
> will provide no "easy" way to enable/access it somehow.
>
> Specially for the detail that we don't disable the region after the
> search was canceled. That's a more intuitive behavior.

Firefox and gedit start the search with the selection text,
but also they move the selection to the next search hit
(I doubt the usefulness of the latter feature).

> Actually I am only considering the option of adding a new function and
> bind it to M-s r.

We already have a similar key 'M-s M-w' to search the text from the
active region in the web browser.  So maybe a better mnemonic key for
your proposed feature would be 'M-s M-y'.

> Or add a C-something like isearch-yank-word-or-char.

This is another possibility indeed, with a new command e.g.
isearch-yank-region.

Re: isearch region or thing at point.

[Ergus]

Hi:

I wrote this code today to do a search auto-insert text from region like
behavior.

===============================================

(defun isearch-forward-region (&optional arg)
  "Do incremental search forward for text in active region.
Like ordinary incremental search except that the text in the active
region is added to the search string initially if variable
`transient-mark-mode' is non nil.  See the command
`isearch-forward-symbol' for more information.	With a prefix
argument, search for ARGth symbol forward if ARG is positive, or
search for ARGth symbol backward if ARG is negative."
  (interactive "P")
  (isearch-forward nil 1)
  (if-let* ((bounds (and (use-region-p) ;; Region and transient non-nil
			 (string-empty-p isearch-string)
			 (region-bounds)))
	    (contiguous (= (length bounds) 1)) ;; Region is contiguous
	    (region-beg (car (car bounds)))
	    (region-end (cdr (car bounds)))
	    (region-string (and (= (count-lines region-beg region-end) 1)
				(buffer-substring-no-properties
				 region-beg region-end)))
	    (noempty (not (string-blank-p region-string))))
      (progn
	(goto-char region-beg)
	(setq mark-active nil
	      isearch--deactivated-mark t)
	(isearch-yank-string region-string)

	(when-let (count (and arg (prefix-numeric-value arg)))
	  (isearch-repeat-forward count)))

    (setq isearch-error "Invalid region for isearch")
    (isearch-push-state)
    (isearch-update)))

================================================

The problem is that when I C-x C-e, it works fine, but when
I compile it I get an error with message:

```
funcall-interactively: Symbol???s value as variable is void: bounds
```

I am pretty new using lisp, but I don't understand this behavior, Any
help, please.

The backtrace only says:

==================================================
Debugger entered--Lisp error: (void-variable bounds)
  isearch-forward-region(nil)
  funcall-interactively(isearch-forward-region nil)
  call-interactively(isearch-forward-region nil nil)
  command-execute(isearch-forward-region)
==================================================

Do I am using wrong the if-let* statement? 

Thanks in advance,
Ergus.

On Mon, Apr 29, 2019 at 10:41:28PM +0300, Juri Linkov wrote:
>>>The closest to this that I'm aware of is
>>>isearch-forward-symbol-at-point, bound to 'M-s .' by default.
>>>
>> I just made a small change in isearch.el to enable region text auto
>> insertion in transient-mark-mode. (patch attached)
>>
>> I did it as simple as I could. So please if you (or any anyone) could
>> give a look and correct/improve/expose corner cases, or suggest a better
>> implementation will be very nice.
>>
>> I don't have corner cases right now, but I just started testing it.
>>
>> So any correction/suggestion/recommendation is very appreciated.
>
>Thanks, such addition is welcome.  Currently searching the
>active region requires invocation of several commands: M-w C-s M-y
>with a bad side-effect of leaving the region in the kill-ring.
>
>However, adding a new option is not a satisfactory solution
>because often isearch is used to extend the boundaries of the
>active region, e.g. by setting the region's beginning with C-SPC,
>then searching the region's end and exiting isearch there.
>
>Fortunately, like Basil mentioned the command isearch-forward-symbol-at-point
>bound to 'M-s .' you could create a similar command bound to e.g. 'M-s r'
>that would start isearch with the text from the active region.
>

Re: isearch region or thing at point.

[Noam Postavsky]

On Tue, 30 Apr 2019 at 12:31, Ergus <spacibba@aol.com> wrote:

> I am pretty new using lisp, but I don't understand this behavior, Any
> help, please.
>
> The backtrace only says:
>
> ==================================================
> Debugger entered--Lisp error: (void-variable bounds)
>   isearch-forward-region(nil)
>   funcall-interactively(isearch-forward-region nil)
>   call-interactively(isearch-forward-region nil nil)
>   command-execute(isearch-forward-region)
> ==================================================
>
> Do I am using wrong the if-let* statement?

You need to put at the top

(eval-when-compile (require 'subr-x))

Otherwise the if-let* macro isn't loaded so it gets interpreted as a
normal function call. It works when you use C-x C-e just because you
happened to load subr-x already. If you carefully start from 'emacs
-Q' you should be able to get the same error that way too.

Re: isearch region or thing at point.

[Ergus]

Hi Noam:

Very very thanks.

Sorry for the dumb question, but where is the if-let part in the
documentation?

Thanks, again,
Ergus

On Tue, Apr 30, 2019 at 02:49:52PM -0400, Noam Postavsky wrote:
>On Tue, 30 Apr 2019 at 12:31, Ergus <spacibba@aol.com> wrote:
>
>> I am pretty new using lisp, but I don't understand this behavior, Any
>> help, please.
>>
>> The backtrace only says:
>>
>> ==================================================
>> Debugger entered--Lisp error: (void-variable bounds)
>>   isearch-forward-region(nil)
>>   funcall-interactively(isearch-forward-region nil)
>>   call-interactively(isearch-forward-region nil nil)
>>   command-execute(isearch-forward-region)
>> ==================================================
>>
>> Do I am using wrong the if-let* statement?
>
>You need to put at the top
>
>(eval-when-compile (require 'subr-x))
>
>Otherwise the if-let* macro isn't loaded so it gets interpreted as a
>normal function call. It works when you use C-x C-e just because you
>happened to load subr-x already. If you carefully start from 'emacs
>-Q' you should be able to get the same error that way too.

Re: isearch region or thing at point.

[Noam Postavsky]

On Tue, 30 Apr 2019 at 15:03, Ergus <spacibba@aol.com> wrote:
> where is the if-let part in the documentation?

I don't quite understand what you're asking, what is "the documentation"?

If you meant the elisp manual, I seem to remember there was a decision
to leave subr-x functions out of the manual (can't find the message in
the archives right now though).

Re: isearch region or thing at point.

[Ergus]

On Tue, Apr 30, 2019 at 03:24:11PM -0400, Noam Postavsky wrote:
>On Tue, 30 Apr 2019 at 15:03, Ergus <spacibba@aol.com> wrote:
>> where is the if-let part in the documentation?
>
>I don't quite understand what you're asking, what is "the documentation"?
>
>If you meant the elisp manual, I seem to remember there was a decision
>to leave subr-x functions out of the manual (can't find the message in
>the archives right now though).
>
Ohh sorry. I didn't know that. I haven't read the header of the subr-x.el
file. (there is also the eval-when-compile indication) Sorry again.

So I may ask then if it is fine to use these if-let in a function I want
to add to isearch.el or if these functions are expected to become
obsolete or are problematic in any sense; so I must use alternative
implementations??

Best Regards,
Ergus.

Re: isearch region or thing at point.

[Noam Postavsky]

On Tue, 30 Apr 2019 at 16:05, Ergus <spacibba@aol.com> wrote:

> >If you meant the elisp manual, I seem to remember there was a decision
> >to leave subr-x functions out of the manual (can't find the message in
> >the archives right now though).
> >
> Ohh sorry. I didn't know that. I haven't read the header of the subr-x.el
> file. (there is also the eval-when-compile indication) Sorry again.

Oh, I didn't read it either: there is the link to the message I was looking for.

> So I may ask then if it is fine to use these if-let in a function I want
> to add to isearch.el or if these functions are expected to become
> obsolete or are problematic in any sense; so I must use alternative
> implementations??

I can't tell the future, but there's no reason to avoid them at the
moment. Perhaps you are over-using them a bit though. For example,

    (when-let (count (and arg (prefix-numeric-value arg)))
      (isearch-repeat-forward count))

can be simply

    (when arg
      (isearch-repeat-forward (prefix-numeric-value arg)))

Re: isearch region or thing at point.

[Basil L. Contovounesios]

Ergus <spacibba@aol.com> writes:

> I wrote this code today to do a search auto-insert text from region like
> behavior.

Thanks, I have some questions and minor comments:

> (defun isearch-forward-region (&optional arg)
>  "Do incremental search forward for text in active region.
> Like ordinary incremental search except that the text in the active
> region is added to the search string initially if variable
> `transient-mark-mode' is non nil.

Perhaps "if `transient-mark-mode' is enabled" instead.

>  See the command `isearch-forward-symbol' for more information.

Which information is that?  Why not refer to isearch-forward instead?

> With a prefix argument, search for ARGth symbol forward if ARG is
> positive, or search for ARGth symbol backward if ARG is negative."

I don't think this should mention symbols.

>  (interactive "P")
>  (isearch-forward nil 1)
>  (if-let* ((bounds (and (use-region-p) ;; Region and transient non-nil

RHS comments usually start with a single semicolon;
see (info "(elisp) Comment Tips").

> 			 (string-empty-p isearch-string)

Why must this be empty?

> 			 (region-bounds)))
> 	    (contiguous (= (length bounds) 1)) ;; Region is contiguous

Better to use the function region-noncontiguous-p.

Also, you shouldn't leave bound symbols unused.  The most common way to
short-circuit conditionals is via the special forms 'and' and 'or'.
In the case of if-let et al., you can also use the following syntax:

  (if-let* ((len (length foo))
            ((zerop len)))
      'empty
    'nonempty)

> 	    (region-beg (car (car bounds)))
> 	    (region-end (cdr (car bounds)))

Nitpick: caar/cdar, also not important.

> 	    (region-string (and (= (count-lines region-beg region-end) 1)
> 				(buffer-substring-no-properties
> 				 region-beg region-end)))

Why can't the region span multiple lines?  Better to use
region-extract-function for this, as it is more flexible.

> 	    (noempty (not (string-blank-p region-string))))

Why can't the search string be blank?

>      (progn
> 	(goto-char region-beg)
> 	(setq mark-active nil
> 	      isearch--deactivated-mark t)

Where is isearch--deactivated-mark defined?  What does it do?
Shouldn't this set/call deactivate-mark or similar instead?

> 	(isearch-yank-string region-string)
>
> 	(when-let (count (and arg (prefix-numeric-value arg)))
> 	  (isearch-repeat-forward count)))

This can be simplified as per Noam's suggestion.

>    (setq isearch-error "Invalid region for isearch")
>    (isearch-push-state)
>    (isearch-update)))

Here's a suggestion which addresses some of my comments:

(defun isearch-forward-region (&optional arg)
  "Do incremental search forward for text in active region.
Like ordinary incremental search except that the text in the
active region is added to the search string initially
if`transient-mark-mode' is enabled.  See the command
`isearch-forward' for more information.
With a prefix argument, search for ARGth occurrence forward if
ARG is positive, or ARGth occurrence backward if ARG is
negative."
  (interactive "P")
  (isearch-forward nil 1)
  (let ((region (and (use-region-p)
                     (string-empty-p isearch-string)
                     (funcall region-extract-function nil))))
    (cond ((and (stringp region)
                (not (string-empty-p region)))
           (goto-char (region-beginning))
           (deactivate-mark)
           (isearch-yank-string region)
           (when arg
             (isearch-repeat-forward (prefix-numeric-value arg))))
          (t
           (setq isearch-error "Invalid region")
           (isearch-push-state)
           (isearch-update)))))

Feel free to adapt it as you please.

Thanks,

-- 
Basil

Re: isearch region or thing at point.

[Ergus]

On Tue, Apr 30, 2019 at 11:39:11PM +0100, Basil L. Contovounesios wrote:
>Ergus <spacibba@aol.com> writes:
>
>
>Thanks, I have some questions and minor comments:
>
>> (defun isearch-forward-region (&optional arg)
>>  "Do incremental search forward for text in active region.
>> Like ordinary incremental search except that the text in the active
>> region is added to the search string initially if variable
>> `transient-mark-mode' is non nil.
>
>Perhaps "if `transient-mark-mode' is enabled" instead.
>
>>  See the command `isearch-forward-symbol' for more information.
>
>Which information is that?  Why not refer to isearch-forward instead?
>
Yes, The docstring was not finished actually, I was just trying the code
functionality..
>
>>  (interactive "P")
>>  (isearch-forward nil 1)
>>  (if-let* ((bounds (and (use-region-p) ;; Region and transient non-nil
>
>RHS comments usually start with a single semicolon;
>see (info "(elisp) Comment Tips").

I will delete those comments
>
>> 			 (string-empty-p isearch-string)
>
>Why must this be empty?
>
This is a condition I will change. The idea is that if the search-string
is empty in this moment we need to goto the region-beginning, That's a
latter change I will make.

>> 			 (region-bounds)))
>> 	    (contiguous (= (length bounds) 1)) ;; Region is contiguous
>
>Better to use the function region-noncontiguous-p.
>
I already had the bounds.. I didn't want to do the funcall again... but
I know it is probably not important.. I am just an obsessed.
>
>Also, you shouldn't leave bound symbols unused.  The most common way to
>short-circuit conditionals is via the special forms 'and' and 'or'.
>In the case of if-let et al., you can also use the following syntax:
>
>  (if-let* ((len (length foo))
>            ((zerop len)))
>      'empty
>    'nonempty)
>
>> 	    (region-beg (car (car bounds)))
>> 	    (region-end (cdr (car bounds)))
>
>Nitpick: caar/cdar, also not important.
>
>> 	    (region-string (and (= (count-lines region-beg region-end) 1)
>> 				(buffer-substring-no-properties
>> 				 region-beg region-end)))
>
>Why can't the region span multiple lines?  Better to use
>region-extract-function for this, as it is more flexible.
>
I don't thing that searching multiple lines will be very useful in
practice and could potentially produce some corner cases. But I
will think about that a bit more.

>> 	    (noempty (not (string-blank-p region-string))))
>
>Why can't the search string be blank?
>
>>      (progn
>> 	(goto-char region-beg)
>> 	(setq mark-active nil
>> 	      isearch--deactivated-mark t)
>
>Where is isearch--deactivated-mark defined?  What does it do?
>Shouldn't this set/call deactivate-mark or similar instead?
>
This is somewhere else, but I did't included it here because is was not
related with the issue I had
>> 	(isearch-yank-string region-string)
>>
>> 	(when-let (count (and arg (prefix-numeric-value arg)))
>> 	  (isearch-repeat-forward count)))
>
>This can be simplified as per Noam's suggestion.
Yes, sorry, I was concerned if somehow the prefix could be non-nil, but
(prefix-numeric-value arg) could return nil... I don't really know the
fancy valued that prefix could potentially have. But probably there is
not any danger there.
>
>>    (setq isearch-error "Invalid region for isearch")
>>    (isearch-push-state)
>>    (isearch-update)))
>
>Here's a suggestion which addresses some of my comments:
>
>(defun isearch-forward-region (&optional arg)
>  "Do incremental search forward for text in active region.
>Like ordinary incremental search except that the text in the
>active region is added to the search string initially
>if`transient-mark-mode' is enabled.  See the command
>`isearch-forward' for more information.
>With a prefix argument, search for ARGth occurrence forward if
>ARG is positive, or ARGth occurrence backward if ARG is
>negative."
>  (interactive "P")
>  (isearch-forward nil 1)
>  (let ((region (and (use-region-p)
>                     (string-empty-p isearch-string)
>                     (funcall region-extract-function nil))))
>    (cond ((and (stringp region)
>                (not (string-empty-p region)))
>           (goto-char (region-beginning))
>           (deactivate-mark)
>           (isearch-yank-string region)
>           (when arg
>             (isearch-repeat-forward (prefix-numeric-value arg))))
>          (t
>           (setq isearch-error "Invalid region")
>           (isearch-push-state)
>           (isearch-update)))))
>
>Feel free to adapt it as you please.
>
>Thanks,
>
>-- 
>Basil

Re: isearch region or thing at point.

[Basil L. Contovounesios]

Ergus <spacibba@aol.com> writes:

> On Tue, Apr 30, 2019 at 11:39:11PM +0100, Basil L. Contovounesios wrote:
>>Ergus <spacibba@aol.com> writes:
>>
>>> 			 (region-bounds)))
>>> 	    (contiguous (= (length bounds) 1)) ;; Region is contiguous
>>
>>Better to use the function region-noncontiguous-p.
>>
> I already had the bounds.. I didn't want to do the funcall again... but
> I know it is probably not important.. I am just an obsessed.

The higher-level and more flexible region-extract-function will handle
this for you in any case.

>>> 	    (region-string (and (= (count-lines region-beg region-end) 1)
>>> 				(buffer-substring-no-properties
>>> 				 region-beg region-end)))
>>
>>Why can't the region span multiple lines?  Better to use
>>region-extract-function for this, as it is more flexible.
>>
> I don't thing that searching multiple lines will be very useful in
> practice and could potentially produce some corner cases. But I
> will think about that a bit more.

AFAIK, isearch is designed to work perfectly fine with multiple lines,
and I use this feature a lot, especially in the context of lax
whitespace matches in Info manuals, for example.

Providing a dedicated region isearch command which is limited to a
single line sounds hardly better than using isearch-yank-word-or-char or
similar.

>>> 	(isearch-yank-string region-string)
>>>
>>> 	(when-let (count (and arg (prefix-numeric-value arg)))
>>> 	  (isearch-repeat-forward count)))
>>
>>This can be simplified as per Noam's suggestion.
> Yes, sorry, I was concerned if somehow the prefix could be non-nil, but
> (prefix-numeric-value arg) could return nil... I don't really know the
> fancy valued that prefix could potentially have. But probably there is
> not any danger there.

All potential prefix values are listed under (info "(elisp) Prefix
Command Arguments"), and prefix-numeric-value is guaranteed to return an
integer.

Thanks,

-- 
Basil

Re: isearch region or thing at point.

[Ergus]

Hi all!:

I have 3 questions before sending all the changes I propose:

1) I provided both cases, a function isearch-forward-region and
isearch-yank-region. One can be bind to M-s something and the other to
M-something once in isearch-mode-map. So the user will be not forced to
move to exit isearch if he is already there.

But on the other hand with the yank one the other does not offer any
real advantage as C-s M-w is not shorter than M-s M-w, bust a bit
easier to type, but not to remember.

I would like M-s M-(y?w) for the first and M-(y?w) for the second... but
I still find those a bit inconsistent (and long). What do you suggest?

2) A more theoretical:

Why the region-extract-function is not a normal function?

Why {when|if|and|...}-let macros are in such a special file and most of
the code don't use them? What's the problem with them?

3) What do you think is the right behavior in case isearch-string is not
empty?

Suppose you marked a region and then type: C-s letter, the cursor will
move to letter, but the actual active region will be from mark->letter.

Because in that case the point has already moved from it's initial
position, so the region is not the same than when it started.

1) Should the command do nothing in that case?

2) Or it must yank what used to be the initial region??

3) Something else?

Best,
Ergus.




On Wed, May 01, 2019 at 12:33:12AM +0100, Basil L. Contovounesios wrote:
>Ergus <spacibba@aol.com> writes:
>
>> On Tue, Apr 30, 2019 at 11:39:11PM +0100, Basil L. Contovounesios wrote:
>>>Ergus <spacibba@aol.com> writes:
>>>
>>>> 			 (region-bounds)))
>>>> 	    (contiguous (= (length bounds) 1)) ;; Region is contiguous
>>>
>>>Better to use the function region-noncontiguous-p.
>>>
>> I already had the bounds.. I didn't want to do the funcall again... but
>> I know it is probably not important.. I am just an obsessed.
>
>The higher-level and more flexible region-extract-function will handle
>this for you in any case.
>
>>>> 	    (region-string (and (= (count-lines region-beg region-end) 1)
>>>> 				(buffer-substring-no-properties
>>>> 				 region-beg region-end)))
>>>
>>>Why can't the region span multiple lines?  Better to use
>>>region-extract-function for this, as it is more flexible.
>>>
>> I don't thing that searching multiple lines will be very useful in
>> practice and could potentially produce some corner cases. But I
>> will think about that a bit more.
>
>AFAIK, isearch is designed to work perfectly fine with multiple lines,
>and I use this feature a lot, especially in the context of lax
>whitespace matches in Info manuals, for example.
>
>Providing a dedicated region isearch command which is limited to a
>single line sounds hardly better than using isearch-yank-word-or-char or
>similar.
>
>>>> 	(isearch-yank-string region-string)
>>>>
>>>> 	(when-let (count (and arg (prefix-numeric-value arg)))
>>>> 	  (isearch-repeat-forward count)))
>>>
>>>This can be simplified as per Noam's suggestion.
>> Yes, sorry, I was concerned if somehow the prefix could be non-nil, but
>> (prefix-numeric-value arg) could return nil... I don't really know the
>> fancy valued that prefix could potentially have. But probably there is
>> not any danger there.
>
>All potential prefix values are listed under (info "(elisp) Prefix
>Command Arguments"), and prefix-numeric-value is guaranteed to return an
>integer.
>
>Thanks,
>
>-- 
>Basil
>

Re: isearch region or thing at point.

[Juri Linkov]

> 3) What do you think is the right behavior in case isearch-string is not
> empty?
>
> Suppose you marked a region and then type: C-s letter, the cursor will
> move to letter, but the actual active region will be from mark->letter.
>
> Because in that case the point has already moved from it's initial
> position, so the region is not the same than when it started.
>
> 1) Should the command do nothing in that case?
>
> 2) Or it must yank what used to be the initial region??
>
> 3) Something else?

This is an interesting question.  Perhaps it should replace the current
search string with the text from the region.

Re: isearch region or thing at point.

[Basil L. Contovounesios]

Ergus <spacibba@aol.com> writes:

> Why the region-extract-function is not a normal function?

AIUI, so that it can be set by different modes, etc., similarly to
e.g. indent-line-function.

> Why {when|if|and|...}-let macros are in such a special file and most of
> the code don't use them? What's the problem with them?

Apart from some instability in their API across the last couple of Emacs
releases, there's no problem with them.  They are relatively recent
additions to Emacs, and were added to subr-x as "experimental" utilities
that needn't be preloaded.  Existing code definitely shouldn't be
changed purely for the sake of using them (this is a general convention
not specific to subr-x), and new code can often be written without them.
It's mostly a matter of taste, etc.  Note, however, that the usual macro
caveats also apply to these utilities, e.g. w.r.t. stale
macroexpansions that need recompilation.

Thanks,

-- 
Basil

Re: isearch region or thing at point.

[Ergus]

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

Hi all:

Here is attached a patch with all my proposed changes to isearch. I
added documentation in the manual for one of the two functions, but for
the other I don't find the right place.

There is still a pending agreement about the questions I made in the
last email, but, meanwhile you can check the rest of the patch and make
all the corrections you think are needed.

Thanks in advance for your comments,
Ergus

On Wed, May 01, 2019 at 12:33:12AM +0100, Basil L. Contovounesios wrote:
>Ergus <spacibba@aol.com> writes:
>
>> On Tue, Apr 30, 2019 at 11:39:11PM +0100, Basil L. Contovounesios wrote:
>>>Ergus <spacibba@aol.com> writes:
>>>
>>>> 			 (region-bounds)))
>>>> 	    (contiguous (= (length bounds) 1)) ;; Region is contiguous
>>>
>>>Better to use the function region-noncontiguous-p.
>>>
>> I already had the bounds.. I didn't want to do the funcall again... but
>> I know it is probably not important.. I am just an obsessed.
>
>The higher-level and more flexible region-extract-function will handle
>this for you in any case.
>
>>>> 	    (region-string (and (= (count-lines region-beg region-end) 1)
>>>> 				(buffer-substring-no-properties
>>>> 				 region-beg region-end)))
>>>
>>>Why can't the region span multiple lines?  Better to use
>>>region-extract-function for this, as it is more flexible.
>>>
>> I don't thing that searching multiple lines will be very useful in
>> practice and could potentially produce some corner cases. But I
>> will think about that a bit more.
>
>AFAIK, isearch is designed to work perfectly fine with multiple lines,
>and I use this feature a lot, especially in the context of lax
>whitespace matches in Info manuals, for example.
>
>Providing a dedicated region isearch command which is limited to a
>single line sounds hardly better than using isearch-yank-word-or-char or
>similar.
>
>>>> 	(isearch-yank-string region-string)
>>>>
>>>> 	(when-let (count (and arg (prefix-numeric-value arg)))
>>>> 	  (isearch-repeat-forward count)))
>>>
>>>This can be simplified as per Noam's suggestion.
>> Yes, sorry, I was concerned if somehow the prefix could be non-nil, but
>> (prefix-numeric-value arg) could return nil... I don't really know the
>> fancy valued that prefix could potentially have. But probably there is
>> not any danger there.
>
>All potential prefix values are listed under (info "(elisp) Prefix
>Command Arguments"), and prefix-numeric-value is guaranteed to return an
>integer.
>
>Thanks,
>
>-- 
>Basil
>

[-- Attachment #2: isearch_yank_region.patch --]
[-- Type: text/plain, Size: 5342 bytes --]

diff --git a/doc/emacs/search.texi b/doc/emacs/search.texi
index a1c987c125..93c26f5c97 100644
--- a/doc/emacs/search.texi
+++ b/doc/emacs/search.texi
@@ -267,6 +267,14 @@ of the current line to the search string.  If point is already at the
 end of a line, it appends the next line.  With a prefix argument
 @var{n}, it appends the next @var{n} lines.
 
+@kindex M-w @r{(Incremental search)}
+@findex isearch-yank-region
+  @kbd{M-w} (@code{isearch-yank-region}) appends the text in the
+active region if @code{transient-mark-mode} is @code{non-nil}. This is
+an easy way to insert the text in the region without needing to exit
+@code{isearch-mode}. The region is deactivated during the search, but
+it is reactivated if the @code{isearch-cancel} is called.
+
 @kindex C-y @r{(Incremental search)}
 @kindex M-y @r{(Incremental search)}
 @kindex mouse-2 @r{in the minibuffer (Incremental search)}
diff --git a/lisp/isearch.el b/lisp/isearch.el
index 6280afebdc..78414dbfcd 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -53,7 +53,9 @@
 
 ;;; Code:
 
-(eval-when-compile (require 'cl-lib))
+(eval-when-compile
+  (require 'cl-lib)
+  (require 'subr-x))
 (declare-function tmm-menubar-keymap "tmm.el")
 \f
 ;; Some additional options and constants.
@@ -701,6 +703,7 @@ This is like `describe-bindings', but displays only Isearch keys."
     (define-key map "\M-\C-y" 'isearch-yank-char)
     (define-key map    "\C-y" 'isearch-yank-kill)
     (define-key map "\M-s\C-e" 'isearch-yank-line)
+    (define-key map     "\M-w" 'isearch-yank-region)
 
     (define-key map "\M-s\M-<" 'isearch-beginning-of-buffer)
     (define-key map "\M-s\M->" 'isearch-end-of-buffer)
@@ -937,6 +940,8 @@ Each element is an `isearch--state' struct where the slots are
 
 (defvar isearch--saved-overriding-local-map nil)
 
+(defvar isearch--deactivated-mark nil)
+
 ;; Minor-mode-alist changes - kind of redundant with the
 ;; echo area, but if isearching in multiple windows, it can be useful.
 ;; Also, clicking the mode-line indicator pops up
@@ -961,6 +966,8 @@ Each element is an `isearch--state' struct where the slots are
 (define-key search-map "w" 'isearch-forward-word)
 (define-key search-map "_" 'isearch-forward-symbol)
 (define-key search-map "." 'isearch-forward-symbol-at-point)
+(define-key search-map "\M-w" 'isearch-forward-region)
+
 
 ;; Entry points to isearch-mode.
 
@@ -1133,6 +1140,22 @@ positive, or search for ARGth symbol backward if ARG is negative."
       (isearch-push-state)
       (isearch-update)))))
 
+(defun isearch-forward-region (&optional arg)
+  "Do incremental search forward for text in active region.
+Like ordinary incremental search except that the text in the
+active region is added to the search string initially
+if`transient-mark-mode' is enabled.  See the command
+`isearch-forward' for more information.
+With a prefix argument, search for ARGth occurrence forward if
+ARG is positive, or ARGth occurrence backward if ARG is
+negative."
+  (interactive "P")
+  (isearch-forward nil 1)
+  (isearch-yank-region)
+  (when (and isearch--deactivated-mark
+             arg)
+    (isearch-repeat-forward (prefix-numeric-value arg))))
+
 \f
 ;; isearch-mode only sets up incremental search for the minor mode.
 ;; All the work is done by the isearch-mode commands.
@@ -1203,9 +1226,10 @@ used to set the value of `isearch-regexp-function'."
 	isearch-pre-move-point nil
 
 	;; Save the original value of `minibuffer-message-timeout', and
-	;; set it to nil so that isearch's messages don't get timed out.
-	isearch-original-minibuffer-message-timeout minibuffer-message-timeout
-	minibuffer-message-timeout nil)
+       ;; set it to nil so that isearch's messages don't get timed out.
+       isearch-original-minibuffer-message-timeout minibuffer-message-timeout
+       minibuffer-message-timeout nil
+       isearch--deactivated-mark nil)
 
   (if (local-variable-p 'tool-bar-map)
       (setq isearch-tool-bar-old-map tool-bar-map))
@@ -1783,6 +1807,9 @@ The following additional command keys are active while editing.
     (goto-char isearch-opoint))
   (isearch-done t)                      ; Exit isearch..
   (isearch-clean-overlays)
+  (when isearch--deactivated-mark
+    (setq isearch--deactivated-mark nil
+          mark-active t))
   (signal 'quit nil))                   ; ..and pass on quit signal.
 
 (defun isearch-abort ()
@@ -2446,6 +2473,27 @@ If search string is empty, just beep."
   ;; then it "used" the mark which we should hence deactivate.
   (when select-active-regions (deactivate-mark)))
 
+(defun isearch-yank-region ()
+  "Pull current active region text into search string.
+The text in the active region is added to the search string if
+variable `transient-mark-mode' is non nil."
+  (interactive)
+  (let ((region (and (use-region-p)
+                     (funcall region-extract-function nil))))
+    (if (and (stringp region)
+             (not (string-empty-p region)))
+        (progn
+          (when (string-empty-p isearch-string)
+            (goto-char (region-beginning)))
+
+          (setq isearch--deactivated-mark t)
+          (deactivate-mark)
+          (isearch-yank-string region))
+
+      (setq isearch-error "Invalid region")
+      (isearch-push-state)
+      (isearch-update))))
+
 
 (defun isearch-mouse-2 (click)
   "Handle mouse-2 in Isearch mode.

RE: isearch region or thing at point.

[Drew Adams]

I'm sorry to say that I'm not in favor of `M-w'
being bound in `isearch-mode-map' for this behavior.

I'm not opposed to some key being bound for it,
though I'd prefer that we just define the command
and leave it unbound (letting users bind it if they
find it handier than just using `M-w' before `C-s').

In Isearch+ I bind `M-w' to `isearchp-kill-ring-save',
which I feel is more useful than your command, which
is a short cut for the usual Emacs keys.

`isearchp-kill-ring-save' copies the current search
string to the kill ring.

I've bound it to `M-w' in the search map since 2013,
when we moved `isearch-toggle-word' from `M-w' to
`M-s w'.

How about just adding your command and not binding
it by default?

Re: isearch region or thing at point.

[Ergus]

Hi Drew:

I would prefer a keybind for it, even a different one, but otherwise
nobody will use the command and the people will continue using
workarounds like now. I didn't take M-y or C-y because they were already
taken and M-w was not colliding with anything in my emacs -Q.

Many people just find the emacs commands while using emacs (thanks to
which-key or counsel-completion or Helm they discover the keybinds) and
commands without a keybind are VERY less visible/accessible unless they
explicitly know and configure a bind for them. The users find them only
after reading a lot of documentation in the manual (which no many people
do). But which-key simplifies the life a lot. Specially for new users.

In fact the "right" to do (IN MY OPINION) is to define a keybind for all
the commands like this. (which insert text from active-region into
minibuffer once in the minibuffer, that could help for
replace-regex/find-file/flyspell/and many others) that will solve a lot
of collisions and will simplify the user experience a lot. (memorization)

We have a lot of package that already proposes patches for this issue
trying to figure out somehow when to insert text from region (or near to
point) to the minibuffer (all the thing-at-point-like packages in elpa
&& melpa are workarounds for this general issue).

BTW: The isearch+ package isn't in elpa||melpa?? I can't find it in the
packages-list, so probably that's why I didn't check it before (I try to
avoid this kind of issues as much as possible before proposing
changes). Is there any reason why it is not in elpa||melpa? Because I
don't know anyone who uses it; for sure because they don't know it.

Let's wait for Eli, Basil and the others... Maybe they will propose a
genial solution (as usual).



On Wed, May 01, 2019 at 07:33:27AM -0700, Drew Adams wrote:
>I'm sorry to say that I'm not in favor of `M-w'
>being bound in `isearch-mode-map' for this behavior.
>
>I'm not opposed to some key being bound for it,
>though I'd prefer that we just define the command
>and leave it unbound (letting users bind it if they
>find it handier than just using `M-w' before `C-s').
>
>In Isearch+ I bind `M-w' to `isearchp-kill-ring-save',
>which I feel is more useful than your command, which
>is a short cut for the usual Emacs keys.
>
>`isearchp-kill-ring-save' copies the current search
>string to the kill ring.
>
>I've bound it to `M-w' in the search map since 2013,
>when we moved `isearch-toggle-word' from `M-w' to
>`M-s w'.
>
>How about just adding your command and not binding
>it by default?

RE: isearch region or thing at point.

[Drew Adams]

It's not about Isearch+.  It's about `M-w' in Isearch.

This is all there is to `isearchp-kill-ring-save'.  I think this (or similar) is what vanilla Isearch should bind to `M-w' (renaming to `isearch-kill-ring-save', for example).

(defun isearchp-kill-ring-save ()
  "Copy the current search string to the kill ring."
  (interactive)
  (kill-new isearch-string)
  (let ((message-log-max  nil))
    (message "Copied search string as kill"))
  (sit-for 1)
  (isearch-update))

Re: isearch region or thing at point.

[Basil L. Contovounesios]

Ergus <spacibba@aol.com> writes:

> I would prefer a keybind for it, even a different one, but otherwise
> nobody will use the command and the people will continue using
> workarounds like now. I didn't take M-y or C-y because they were already
> taken and M-w was not colliding with anything in my emacs -Q.
>
> Many people just find the emacs commands while using emacs (thanks to
> which-key or counsel-completion or Helm they discover the keybinds) and
> commands without a keybind are VERY less visible/accessible unless they
> explicitly know and configure a bind for them. The users find them only
> after reading a lot of documentation in the manual (which no many people
> do). But which-key simplifies the life a lot. Specially for new users.

FWIW, docstrings of mode functions, etc. can always include a synoptic
list of useful commands and/or bindings.  It's not always necessary to
resort to reading the code or manual, and shouldn't be.

> In fact the "right" to do (IN MY OPINION) is to define a keybind for all
> the commands like this. (which insert text from active-region into
> minibuffer once in the minibuffer, that could help for
> replace-regex/find-file/flyspell/and many others) that will solve a lot
> of collisions and will simplify the user experience a lot. (memorization)
>
> We have a lot of package that already proposes patches for this issue
> trying to figure out somehow when to insert text from region (or near to
> point) to the minibuffer (all the thing-at-point-like packages in elpa
> && melpa are workarounds for this general issue).

I doubt all of them are "workarounds" per se, so much as customisations,
extensions, etc.

> BTW: The isearch+ package isn't in elpa||melpa?? I can't find it in the
> packages-list, so probably that's why I didn't check it before (I try to
> avoid this kind of issues as much as possible before proposing
> changes). Is there any reason why it is not in elpa||melpa? Because I
> don't know anyone who uses it; for sure because they don't know it.

See https://emacs.stackexchange.com/q/38553/15748.

> Let's wait for Eli, Basil and the others... Maybe they will propose a
> genial solution (as usual).

Sorry, I don't usually take a stance on things like default key bindings
and the like, because everyone has different preferences and I know I
can (almost) always adapt them to my liking.  Besides, I'm no authority
around here.

How well/prominently a mode advertises/documents its usage is a
different matter.

Thanks,

-- 
Basil

Re: isearch region or thing at point.

[Eli Zaretskii]

> Date: Wed, 1 May 2019 18:03:44 +0200
> From: Ergus <spacibba@aol.com>
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, emacs-devel@gnu.org,
> 	Juri Linkov <juri@linkov.net>
> 
> Let's wait for Eli, Basil and the others... Maybe they will propose a
> genial solution (as usual).

I see no problem with using M-w for this purpose.  It isn't a reserved
key.

Re: isearch region or thing at point.

[Basil L. Contovounesios]

Ergus <spacibba@aol.com> writes:

> Here is attached a patch with all my proposed changes to isearch.

Thanks, just some minor comments from me:

> @@ -267,6 +267,14 @@ of the current line to the search string.  If point is already at the
>  end of a line, it appends the next line.  With a prefix argument
>  @var{n}, it appends the next @var{n} lines.
>  
> +@kindex M-w @r{(Incremental search)}
> +@findex isearch-yank-region
> +  @kbd{M-w} (@code{isearch-yank-region}) appends the text in the
> +active region if @code{transient-mark-mode} is @code{non-nil}. This is

I think it is more common to talk about transient-mark-mode the mode,
not the variable. 

Emacs convention is to end all sentences with two spaces, see the
sentence-end-double-space setting in the repository's dir-locals-file.

> +an easy way to insert the text in the region without needing to exit
> +@code{isearch-mode}. The region is deactivated during the search, but
> +it is reactivated if the @code{isearch-cancel} is called.
> +
>  @kindex C-y @r{(Incremental search)}
>  @kindex M-y @r{(Incremental search)}
>  @kindex mouse-2 @r{in the minibuffer (Incremental search)}
> diff --git a/lisp/isearch.el b/lisp/isearch.el
> index 6280afebdc..78414dbfcd 100644
> --- a/lisp/isearch.el
> +++ b/lisp/isearch.el
> @@ -937,6 +940,8 @@ Each element is an `isearch--state' struct where the slots are
>  
>  (defvar isearch--saved-overriding-local-map nil)
>  
> +(defvar isearch--deactivated-mark nil)
> +

It's always nice to have docstrings.

>  ;; Minor-mode-alist changes - kind of redundant with the
>  ;; echo area, but if isearching in multiple windows, it can be useful.
>  ;; Also, clicking the mode-line indicator pops up
> @@ -1133,6 +1140,22 @@ positive, or search for ARGth symbol backward if ARG is negative."
>        (isearch-push-state)
>        (isearch-update)))))
>  
> +(defun isearch-forward-region (&optional arg)
> +  "Do incremental search forward for text in active region.
> +Like ordinary incremental search except that the text in the
> +active region is added to the search string initially
> +if`transient-mark-mode' is enabled.  See the command
    ^^^

Missing space.

> +`isearch-forward' for more information.
> +With a prefix argument, search for ARGth occurrence forward if
> +ARG is positive, or ARGth occurrence backward if ARG is
> +negative."
> +  (interactive "P")
> +  (isearch-forward nil 1)
> +  (isearch-yank-region)
> +  (when (and isearch--deactivated-mark
> +             arg)
> +    (isearch-repeat-forward (prefix-numeric-value arg))))
> +
>  \f
>  ;; isearch-mode only sets up incremental search for the minor mode.
>  ;; All the work is done by the isearch-mode commands.
> @@ -2446,6 +2473,27 @@ If search string is empty, just beep."
>    ;; then it "used" the mark which we should hence deactivate.
>    (when select-active-regions (deactivate-mark)))
>  
> +(defun isearch-yank-region ()
> +  "Pull current active region text into search string.
> +The text in the active region is added to the search string if
> +variable `transient-mark-mode' is non nil."

Ditto re: transient-mark-mode the mode, not variable.

Thanks,

-- 
Basil

Re: isearch region or thing at point.

[Eli Zaretskii]

> Date: Wed, 1 May 2019 13:20:25 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Juri Linkov <juri@linkov.net>, emacs-devel@gnu.org
> 
> +@kindex M-w @r{(Incremental search)}
> +@findex isearch-yank-region
> +  @kbd{M-w} (@code{isearch-yank-region}) appends the text in the
> +active region if @code{transient-mark-mode} is @code{non-nil}. This is
> +an easy way to insert the text in the region without needing to exit
> +@code{isearch-mode}. The region is deactivated during the search, but
> +it is reactivated if the @code{isearch-cancel} is called.

Please leave 2 spaces between sentences in all documentation and
comments.

> +       ;; set it to nil so that isearch's messages don't get timed out.

Comments should start with a capital letter.

Thanks.

Re: isearch region or thing at point.

[Ergus]

Hi Eli:

This patch has changed a lot because some others made suggestions I
considered useful. I will attach the new patch in another mail.

On the other hand it makes sense that M-w should be used in case the
user wants to add the text in the minibuffer to the kill-ring.
(Something like isearchp-kill-ring-save)

So maybe M-r (region) or M-i (insert) must be used for what I propose
and Drew may add the isearch-kill-ring-save function he wrote and bind
it to M-w. That way there will be all the copy functionalities in place.

But then we must recommend bind M-r or M-i (or whatever) for similar
functionalities. And if possible correct other modes to be consistent
with that (if that does not start a religious war here please).

I will try to do the same for replace-like commands.

On Sat, May 04, 2019 at 12:26:56PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 1 May 2019 13:20:25 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: Juri Linkov <juri@linkov.net>, emacs-devel@gnu.org
>>
>> +@kindex M-w @r{(Incremental search)}
>> +@findex isearch-yank-region
>> +  @kbd{M-w} (@code{isearch-yank-region}) appends the text in the
>> +active region if @code{transient-mark-mode} is @code{non-nil}. This is
>> +an easy way to insert the text in the region without needing to exit
>> +@code{isearch-mode}. The region is deactivated during the search, but
>> +it is reactivated if the @code{isearch-cancel} is called.
>
>Please leave 2 spaces between sentences in all documentation and
>comments.
>
>> +       ;; set it to nil so that isearch's messages don't get timed out.
>
>Comments should start with a capital letter.
>
>Thanks.

RE: isearch region or thing at point.

[Drew Adams]

> This patch has changed a lot because some others made suggestions I
> considered useful. I will attach the new patch in another mail.
> 
> On the other hand it makes sense that M-w should be used in case the
> user wants to add the text in the minibuffer to the kill-ring.
> (Something like isearchp-kill-ring-save)
> 
> So maybe M-r (region) or M-i (insert) must be used for what I propose
> and Drew may add the isearch-kill-ring-save function he wrote and bind
> it to M-w. That way there will be all the copy functionalities in place.

I would prefer that, yes.  `M-w' to copy to the
kill-ring (as usual).

Do you need an actual patch to include the command
I sent, or can you please just include it (renaming
prefix `isearchp-' to `isearch-')?

> But then we must recommend bind M-r or M-i (or whatever) for similar
> functionalities. And if possible correct other modes to be consistent
> with that (if that does not start a religious war here please).

Sorry, I don't know what you mean, there.  `M-r' is
(and has long been) `isearch-toggle-regexp'.

> I will try to do the same for replace-like commands.

(Not sure what you mean by that, either.)

Re: isearch region or thing at point.

[Ergus]

On Sat, May 04, 2019 at 07:17:50AM -0700, Drew Adams wrote:
>> This patch has changed a lot because some others made suggestions I
>> considered useful. I will attach the new patch in another mail.
>>
>> On the other hand it makes sense that M-w should be used in case the
>> user wants to add the text in the minibuffer to the kill-ring.
>> (Something like isearchp-kill-ring-save)
>>
>> So maybe M-r (region) or M-i (insert) must be used for what I propose
>> and Drew may add the isearch-kill-ring-save function he wrote and bind
>> it to M-w. That way there will be all the copy functionalities in place.
>
>I would prefer that, yes.  `M-w' to copy to the
>kill-ring (as usual).
>
>Do you need an actual patch to include the command
>I sent, or can you please just include it (renaming
>prefix `isearchp-' to `isearch-')?
>

>> But then we must recommend bind M-r or M-i (or whatever) for similar
>> functionalities. And if possible correct other modes to be consistent
>> with that (if that does not start a religious war here please).
>
There are similar modes with commands to copy text from region into
minibuffer and all them use different bindings. I just propose to unify
that somehow when possible.
>
>Sorry, I don't know what you mean, there.  `M-r' is
>(and has long been) `isearch-toggle-regexp'.
>
Sorry, I forgot that, So the only alternative is M-i.

>> I will try to do the same for replace-like commands.
>
>(Not sure what you mean by that, either.)

When region is active; replace-string (and related) limits the replaces
to the active region. But alternatively we could provide a simple hint
that inserts the region text into minibuffer and deactivate it, so
instead of limiting the replace to the region, the region can be used as
the string to replace.

M-w M-% C-y RET => M-% M-i

Or similar.

RE: isearch region or thing at point.

[Drew Adams]

> >> This patch has changed a lot because some others made suggestions I
> >> considered useful. I will attach the new patch in another mail.
> >>
> >> On the other hand it makes sense that M-w should be used in case the
> >> user wants to add the text in the minibuffer to the kill-ring.
> >> (Something like isearchp-kill-ring-save)
> >>
> >> So maybe M-r (region) or M-i (insert) must be used for what I propose
> >> and Drew may add the isearch-kill-ring-save function he wrote and bind
> >> it to M-w. That way there will be all the copy functionalities in place.
> >
> >I would prefer that, yes.  `M-w' to copy to the
> >kill-ring (as usual).
> >
> >Do you need an actual patch to include the command
> >I sent, or can you please just include it (renaming
> >prefix `isearchp-' to `isearch-')?
> 
> >> But then we must recommend bind M-r or M-i (or whatever) for similar
> >> functionalities. And if possible correct other modes to be consistent
> >> with that (if that does not start a religious war here please).
>
> There are similar modes with commands to copy text from region into
> minibuffer and all them use different bindings. I just propose to unify
> that somehow when possible.
>
> >Sorry, I don't know what you mean, there.  `M-r' is
> >(and has long been) `isearch-toggle-regexp'.
>
> Sorry, I forgot that, So the only alternative is M-i.

There are other alternatives, too (but I'm not saying
they are necessarily better).  We have prefix `M-s',
for example.

But aside from a few, I prefer that we use it for
toggle commands.  Vanilla Emacs uses it for these:

M-s C-e	isearch-yank-line
M-s SPC	isearch-toggle-lax-whitespace
M-s '		isearch-toggle-char-fold
M-s _		isearch-toggle-symbol
M-s c		isearch-toggle-case-fold
M-s e		isearch-edit-string
M-s h r	isearch-highlight-regexp
M-s i		isearch-toggle-invisible
M-s o		isearch-occur
M-s r		isearch-toggle-regexp
M-s w		isearch-toggle-word

(Note that we already give 2 bindings to
`isearch-toggle-case-fold', which we need not do.)

And Isearch+ uses `M-s' additionally for these:

M-s M-SPC       isearchp-toggle-set-region
M-s M-k         isearchp-toggle-repeat-search-if-fail
M-s #           isearchp-toggle-showing-match-number
M-s %           isearchp-toggle-limit-match-numbers-to-region
M-s h L         isearchp-toggle-lazy-highlighting
M-s h R         isearchp-toggle-highlighting-regexp-groups
M-s h b         isearchp-toggle-lazy-highlight-full-buffer
M-s h d         isearchp-toggle-dimming-filter-failures
M-s h f         isearchp-highlight-matches-other-face
M-s h h         hlt-highlight-isearch-matches
M-s h l         isearchp-toggle-lazy-highlight-cleanup
M-s h u         hlt-unhighlight-isearch-matches
M-s u f         isearchp-unhighlight-last-face
M-s v           isearchp-toggle-option-toggle

> >> I will try to do the same for replace-like commands.
> >
> >(Not sure what you mean by that, either.)
> 
> When region is active; replace-string (and related) limits the replaces
> to the active region. But alternatively we could provide a simple hint
> that inserts the region text into minibuffer and deactivate it, so
> instead of limiting the replace to the region, the region can be used as
> the string to replace.
> 
> M-w M-% C-y RET => M-% M-i
> 
> Or similar.

Got it.  I agree that for Isearch and other things,
such as replacement, there are at least those two
very different ways to use the active region:

1. Copy its content to the kill ring (or the secondary
   selection or a register or...).

2. Limit the action to the region (e.g., limit search
   or replacement to the region).

That was in fact one of the points underlying my
message, though I didn't state it explicitly.

Replacement commands already let you limit the action
to the active region, even in vanilla Emacs.

Isearch+ (but not yet vanilla Isearch) also lets you
limit the search to the active region.

And in general when the region is active, the typical
change in behavior a command makes is to act on the
region instead of the whole buffer or the part of it
following point.

I agree that it might be good to have key bindings
that consistently reflect this difference - these
two different ways to use the active region.

There are additional ways in which a command can
make use of the active region, of course.  But these
two stand out as fairly general possibilities.

It would be good to "standardize" bindings - say
reserve `M-w' (e.g. on a prefix key) for the
"copy-region" (or similar) action, and find another
key (e.g. on a prefix key) for the "limit-to-region"
action.

Re: isearch region or thing at point.

[Juri Linkov]

> There are other alternatives, too (but I'm not saying
> they are necessarily better).  We have prefix `M-s',
> for example.
>
> But aside from a few, I prefer that we use it for
> toggle commands.  Vanilla Emacs uses it for these:
>
> M-s '		isearch-toggle-char-fold
> M-s c		isearch-toggle-case-fold
>
> (Note that we already give 2 bindings to
> `isearch-toggle-case-fold', which we need not do.)

The other is isearch-toggle-char-fold.

> It would be good to "standardize" bindings - say
> reserve `M-w' (e.g. on a prefix key) for the
> "copy-region" (or similar) action

I remember you had a key to grab the region into the minibuffer.
This is what Ergus wants.

RE: isearch region or thing at point.

[Drew Adams]

> > (Note that we already give 2 bindings to
> > `isearch-toggle-case-fold', which we need not do.)
> 
> The other is isearch-toggle-char-fold.

Oops - my bad.  Eye-scanned too quickly.

> > It would be good to "standardize" bindings - say
> > reserve `M-w' (e.g. on a prefix key) for the
> > "copy-region" (or similar) action
> 
> I remember you had a key to grab the region into the minibuffer.
> This is what Ergus wants.

I don't think this thread is about grabbing the region
text into the minibuffer.  Ergus grabs it into Isearch
as the search string.

And I don't think I have a command that grabs the
region into the minibuffer.

What I have is a command that copies the current
search string to the kill ring.  See previous posts
in this thread.

I posted the code for the command, suggesting that
we add it to vanilla Emacs and bind it (as I do) to
`M-w'.  Here it is again (just rename prefix
`isearchp-' to `isearch-'):

(defun isearchp-kill-ring-save ()
  "Copy the current search string to the kill ring."
  (interactive)
  (kill-new isearch-string)
  (let ((message-log-max  nil))
    (message "Copied search string as kill"))
  (sit-for 1)
  (isearch-update))

Re: isearch region or thing at point.

[Juri Linkov]

>> > It would be good to "standardize" bindings - say
>> > reserve `M-w' (e.g. on a prefix key) for the
>> > "copy-region" (or similar) action
>> 
>> I remember you had a key to grab the region into the minibuffer.
>> This is what Ergus wants.
>
> I don't think this thread is about grabbing the region
> text into the minibuffer.  Ergus grabs it into Isearch
> as the search string.
>
> And I don't think I have a command that grabs the
> region into the minibuffer.

Maybe the same key, e.g. 'M-.' could be used to grab
the region into the search string, into the query-replace
prompt, or into the minibuffer?

RE: isearch region or thing at point.

[Drew Adams]

> >> > It would be good to "standardize" bindings - say
> >> > reserve `M-w' (e.g. on a prefix key) for the
> >> > "copy-region" (or similar) action
> >>
> >> I remember you had a key to grab the region into the minibuffer.
> >> This is what Ergus wants.
> >
> > I don't think this thread is about grabbing the region
> > text into the minibuffer.  Ergus grabs it into Isearch
> > as the search string.
> >
> > And I don't think I have a command that grabs the
> > region into the minibuffer.
> 
> Maybe the same key, e.g. 'M-.' could be used to grab
> the region into the search string, into the query-replace
> prompt, or into the minibuffer?

Maybe.

If you meant `M-.' then maybe you were thinking of my
binding of `M-.' in Icicles.  It does pull buffer text
into the minibuffer (appends it there, so you can use it
to insert multiple things into the same minibuffer).

It really has nothing to do with completion (hence with
most of the rest of Icicles) - you can use it with any
minibuffer, whether reading with or without completion.

My `M-.' does not pick up the text of the active region,
however (it could be made to, but it doesn't do that now).

Instead, it picks up existing buffer text starting at
point (either or both directions).  You can pick up
multiple consecutive occurrences of a given kind of
thing, or you can pick up a given kind of thing,
choosing the kind by cycling among THING choices.

The doc is here:

https://www.emacswiki.org/emacs/Icicles_-_Inserting_Text_from_Cursor

Perhaps it can serve as food for thought.  It would be
simple to integrate the possibility of picking up the
region text when the region is active, as an alternative.

RE: isearch region or thing at point.

[Ergus]

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

Hi again.

I have been thinking about an alternative. If we redefine isearch thing at point as region or thing at point. Meaning that if a region is active use it, else then try thing/symbol around point... and we reuse the key bindings. Is it a bad idea that conflicts with something?

On May 7, 2019 4:56:47 AM GMT+02:00, Drew Adams <drew.adams@oracle.com> wrote:
>> >> > It would be good to "standardize" bindings - say
>> >> > reserve `M-w' (e.g. on a prefix key) for the
>> >> > "copy-region" (or similar) action
>> >>
>> >> I remember you had a key to grab the region into the minibuffer.
>> >> This is what Ergus wants.
>> >
>> > I don't think this thread is about grabbing the region
>> > text into the minibuffer.  Ergus grabs it into Isearch
>> > as the search string.
>> >
>> > And I don't think I have a command that grabs the
>> > region into the minibuffer.
>> 
>> Maybe the same key, e.g. 'M-.' could be used to grab
>> the region into the search string, into the query-replace
>> prompt, or into the minibuffer?
>
>Maybe.
>
>If you meant `M-.' then maybe you were thinking of my
>binding of `M-.' in Icicles.  It does pull buffer text
>into the minibuffer (appends it there, so you can use it
>to insert multiple things into the same minibuffer).
>
>It really has nothing to do with completion (hence with
>most of the rest of Icicles) - you can use it with any
>minibuffer, whether reading with or without completion.
>
>My `M-.' does not pick up the text of the active region,
>however (it could be made to, but it doesn't do that now).
>
>Instead, it picks up existing buffer text starting at
>point (either or both directions).  You can pick up
>multiple consecutive occurrences of a given kind of
>thing, or you can pick up a given kind of thing,
>choosing the kind by cycling among THING choices.
>
>The doc is here:
>
>https://www.emacswiki.org/emacs/Icicles_-_Inserting_Text_from_Cursor
>
>Perhaps it can serve as food for thought.  It would be
>simple to integrate the possibility of picking up the
>region text when the region is active, as an alternative.

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

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