[PATCH] Expose isearch and suffix regions to widgets.

[PATCH] Expose isearch and suffix regions to widgets.

[m0viefreak]

This does the same as
  36445: Expose yankb, yanke, ZLE_YANK to widgets.
did, but for isearch and suffix regions.
---
 Doc/Zsh/zle.yo       | 26 +++++++++++++++++++++++
 Src/Zle/zle_params.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+)

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 414c8dd..161cef7 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -835,6 +835,19 @@ which always gives the number of the history line being added to the main
 shell's history.  tt(HISTNO) refers to the line being retrieved within
 zle.
 )
+vindex(ISEARCH_ACTIVE)
+vindex(ISEARCH_START)
+vindex(ISEARCH_END)
+xitem(tt(ISEARCH_ACTIVE) (integer))
+xitem(tt(ISEARCH_START) (integer))
+item(tt(ISEARCH_END) (integer))(
+tt(ISEARCH_ACTIVE) indicates whether an incremental search minibuffer
+is active. tt(ISEARCH_START) and tt(ISEARCH_END) give the location of
+the matched pattern and are in the same units as tt(CURSOR). They are
+only valid for reading when tt(ISEARCH_ACTIVE) is non-zero.
+
+All parameters are read-only.
+)
 vindex(KEYMAP)
 item(tt(KEYMAP) (scalar))(
 The name of the currently selected keymap; read-only.
@@ -977,6 +990,19 @@ and tt(zle_highlight); see
 ifzman(the section CHARACTER HIGHLIGHTING below)\
 ifnzman(noderef(Character Highlighting)) for details.
 )
+vindex(SUFFIX_ACTIVE)
+vindex(SUFFIX_START)
+vindex(SUFFIX_END)
+xitem(tt(SUFFIX_ACTIVE) (integer))
+xitem(tt(SUFFIX_START) (integer))
+item(tt(SUFFIX_END) (integer))(
+tt(SUFFIX_ACTIVE) indicates whether an auto-removable completion suffix
+is currently active. tt(SUFFIX_START) and tt(SUFFIX_END) give the
+location of the suffix and are in the same units as tt(CURSOR). They are
+only valid for reading when tt(SUFFIX_ACTIVE) is non-zero.
+
+All parameters are read-only.
+)
 vindex(UNDO_CHANGE_NO)
 item(tt(UNDO_CHANGE_NO) (integer))(
 A number representing the state of the undo history.  The only use
diff --git a/Src/Zle/zle_params.c b/Src/Zle/zle_params.c
index b5bb288..7cbb3df 100644
--- a/Src/Zle/zle_params.c
+++ b/Src/Zle/zle_params.c
@@ -103,6 +103,18 @@ static const struct gsu_integer yankend_gsu =
 { get_yankend, set_yankend, zleunsetfn };
 static const struct gsu_integer yankactive_gsu =
 { get_yankactive, NULL, zleunsetfn };
+static const struct gsu_integer isearchstart_gsu =
+{ get_isearchstart, NULL, zleunsetfn };
+static const struct gsu_integer isearchend_gsu =
+{ get_isearchend, NULL, zleunsetfn };
+static const struct gsu_integer isearchactive_gsu =
+{ get_isearchactive, NULL, zleunsetfn };
+static const struct gsu_integer suffixstart_gsu =
+{ get_suffixstart, NULL, zleunsetfn };
+static const struct gsu_integer suffixend_gsu =
+{ get_suffixend, NULL, zleunsetfn };
+static const struct gsu_integer suffixactive_gsu =
+{ get_suffixactive, NULL, zleunsetfn };
 
 static const struct gsu_array killring_gsu =
 { get_killring, set_killring, unset_killring };
@@ -152,6 +164,12 @@ static struct zleparam {
     { "YANK_START", PM_INTEGER, GSU(yankstart_gsu), NULL },
     { "YANK_END", PM_INTEGER, GSU(yankend_gsu), NULL },
     { "YANK_ACTIVE", PM_INTEGER | PM_READONLY, GSU(yankactive_gsu), NULL },
+    { "ISEARCH_START", PM_INTEGER, GSU(isearchstart_gsu), NULL },
+    { "ISEARCH_END", PM_INTEGER, GSU(isearchend_gsu), NULL },
+    { "ISEARCH_ACTIVE", PM_INTEGER | PM_READONLY, GSU(isearchactive_gsu), NULL },
+    { "SUFFIX_START", PM_INTEGER, GSU(suffixstart_gsu), NULL },
+    { "SUFFIX_END", PM_INTEGER, GSU(suffixend_gsu), NULL },
+    { "SUFFIX_ACTIVE", PM_INTEGER | PM_READONLY, GSU(suffixactive_gsu), NULL },
     { "ZLE_STATE", PM_SCALAR | PM_READONLY, GSU(zle_state_gsu), NULL },
     { NULL, 0, NULL, NULL }
 };
@@ -521,6 +539,48 @@ set_yankend(UNUSED(Param pm), zlong i)
 }
 
 /**/
+static zlong
+get_isearchstart(UNUSED(Param pm))
+{
+    return isearch_startpos;
+}
+
+/**/
+static zlong
+get_isearchend(UNUSED(Param pm))
+{
+    return isearch_endpos;
+}
+
+/**/
+static zlong
+get_isearchactive(UNUSED(Param pm))
+{
+    return isearch_active;
+}
+
+/**/
+static zlong
+get_suffixstart(UNUSED(Param pm))
+{
+    return zlecs - suffixlen;
+}
+
+/**/
+static zlong
+get_suffixend(UNUSED(Param pm))
+{
+    return zlecs;
+}
+
+/**/
+static zlong
+get_suffixactive(UNUSED(Param pm))
+{
+    return suffixlen;
+}
+
+/**/
 static char *
 get_cutbuffer(UNUSED(Param pm))
 {
-- 
2.5.0.234.gefc8a62

Re: [PATCH] Expose isearch and suffix regions to widgets.

[Peter Stephenson]

On Sun, 13 Mar 2016 22:51:11 +0100
m0viefreak <m0viefreak.cm@googlemail.com> wrote:
> This does the same as
>   36445: Expose yankb, yanke, ZLE_YANK to widgets.
> did, but for isearch and suffix regions.

I committed this --- shouldn't be much to go wrong as the parameters are
integers and the completion versions are readonly.

pws

Re: [PATCH] Expose isearch and suffix regions to widgets.

[Daniel Shahaf]

Peter Stephenson wrote on Mon, Mar 21, 2016 at 09:47:00 +0000:
> On Sun, 13 Mar 2016 22:51:11 +0100
> m0viefreak <m0viefreak.cm@googlemail.com> wrote:
> > This does the same as
> >   36445: Expose yankb, yanke, ZLE_YANK to widgets.
> > did, but for isearch and suffix regions.
> 
> I committed this --- shouldn't be much to go wrong as the parameters are
> integers and the completion versions are readonly.

You accidentally(?) included Src/vincent.zsh in that commit.

Re: [PATCH] Expose isearch and suffix regions to widgets.

[Bart Schaefer]

On Sun, Mar 13, 2016 at 2:51 PM, m0viefreak
<m0viefreak.cm@googlemail.com> wrote:
> This does the same as
>   36445: Expose yankb, yanke, ZLE_YANK to widgets.
> did, but for isearch and suffix regions.

Sorry for the belated reply to this, but could you provide an example
in which the ISEARCH_* variables are useful?

User-defined widgets aren't executed from the isearch local keymap and
using any main-keymap widget exits the isearch, so when would
examining these mean anything?

Re: [PATCH] Expose isearch and suffix regions to widgets.

[Bart Schaefer]

On Sat, Apr 9, 2016 at 10:26 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> Sorry for the belated reply to this, but could you provide an example
> in which the ISEARCH_* variables are useful?

And if the answer is going to be "during zle-isearch-update" then
won't ISEARCH_ACTIVE always be true?

Re: [PATCH] Expose isearch and suffix regions to widgets.

[m0viefreak]

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

On 10.04.2016 07:35, Bart Schaefer wrote:
>> Sorry for the belated reply to this, but could you provide an example
>> in which the ISEARCH_* variables are useful?

Like the patch 36445 for yank, this is used by the
zsh-syntax-highlighting script. With this change, the matched part of
BUFFER can be queried in zle-isearch-update (and something like the
zle_highlight array can be re-created on top of other highlighting,
which was impossible before).

> And if the answer is going to be "during zle-isearch-update" then
> won't ISEARCH_ACTIVE always be true?

No, I actually made a mistake in the docs for the original patch.

ISEARCH_ACTIVE does not describe the fact that the minibuffer is active,
but the fact that a pattern that was typed in there does actually
matches the BUFFER. If the search pattern does not match ("failing
bck-i-search:") nothing is being underlined, and ISEARCH_ACTIVE will be 0.

I attached a small patch to improve the wording in the docs.

[-- Attachment #2: 0001-Improve-wording-of-the-ISEARCH_ACTIVE-parameter.patch --]
[-- Type: text/plain, Size: 1203 bytes --]

From 87aaf78284752d04873aff4ece710ccc3279c563 Mon Sep 17 00:00:00 2001
From: m0viefreak <m0viefreak.cm@googlemail.com>
Date: Sun, 10 Apr 2016 14:57:51 +0200
Subject: [PATCH] Improve wording of the ISEARCH_ACTIVE parameter.

---
 Doc/Zsh/zle.yo | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 161cef7..c482a46 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -841,10 +841,11 @@ vindex(ISEARCH_END)
 xitem(tt(ISEARCH_ACTIVE) (integer))
 xitem(tt(ISEARCH_START) (integer))
 item(tt(ISEARCH_END) (integer))(
-tt(ISEARCH_ACTIVE) indicates whether an incremental search minibuffer
-is active. tt(ISEARCH_START) and tt(ISEARCH_END) give the location of
-the matched pattern and are in the same units as tt(CURSOR). They are
-only valid for reading when tt(ISEARCH_ACTIVE) is non-zero.
+tt(ISEARCH_ACTIVE) indicates whether a part of the tt(BUFFER) is
+currently matched by an incremental search pattern. tt(ISEARCH_START)
+and tt(ISEARCH_END) give the location of the matched part and are
+in the same units as tt(CURSOR). They are only valid for reading
+when tt(ISEARCH_ACTIVE) is non-zero.
 
 All parameters are read-only.
 )
-- 
2.7.4

Re: [PATCH] Expose isearch and suffix regions to widgets.

[Daniel Shahaf]

m0viefreak wrote on Sun, Apr 10, 2016 at 15:10:39 +0200:
> On 10.04.2016 07:35, Bart Schaefer wrote:
> > And if the answer is going to be "during zle-isearch-update" then
> > won't ISEARCH_ACTIVE always be true?
> 
> No, I actually made a mistake in the docs for the original patch.
> 
> ISEARCH_ACTIVE does not describe the fact that the minibuffer is active,
> but the fact that a pattern that was typed in there does actually
> matches the BUFFER. If the search pattern does not match ("failing
> bck-i-search:") nothing is being underlined, and ISEARCH_ACTIVE will be 0.
> 
> I attached a small patch to improve the wording in the docs.

Rename the shell parameter, then?  I know the C variable is called
'isearch_active', but the shell parameter's name is an interface, and
I'd rather have the interface be named properly than have it accurately
represent an implementation detail.

(In z-sy-h I'll just track the rename, and pretend the ISEARCH_ACTIVE
name never existed.)

Cheers,

Daniel

P.S. I usually review patches such as the one below by converting them
to wdiff format by piping them through 'wdiff -d'.  It's a useful
command but not too well known, I think...

> From 87aaf78284752d04873aff4ece710ccc3279c563 Mon Sep 17 00:00:00 2001
> From: m0viefreak <m0viefreak.cm@googlemail.com>
> Date: Sun, 10 Apr 2016 14:57:51 +0200
> Subject: [PATCH] Improve wording of the ISEARCH_ACTIVE parameter.
> 
> ---
>  Doc/Zsh/zle.yo | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
> index 161cef7..c482a46 100644
> --- a/Doc/Zsh/zle.yo
> +++ b/Doc/Zsh/zle.yo
> @@ -841,10 +841,11 @@ vindex(ISEARCH_END)
>  xitem(tt(ISEARCH_ACTIVE) (integer))
>  xitem(tt(ISEARCH_START) (integer))
>  item(tt(ISEARCH_END) (integer))(
> -tt(ISEARCH_ACTIVE) indicates whether an incremental search minibuffer
> -is active. tt(ISEARCH_START) and tt(ISEARCH_END) give the location of
> -the matched pattern and are in the same units as tt(CURSOR). They are
> -only valid for reading when tt(ISEARCH_ACTIVE) is non-zero.
> +tt(ISEARCH_ACTIVE) indicates whether a part of the tt(BUFFER) is
> +currently matched by an incremental search pattern. tt(ISEARCH_START)
> +and tt(ISEARCH_END) give the location of the matched part and are
> +in the same units as tt(CURSOR). They are only valid for reading
> +when tt(ISEARCH_ACTIVE) is non-zero.
>  
>  All parameters are read-only.
>  )
> -- 
> 2.7.4
> 

Re: [PATCH] Expose isearch and suffix regions to widgets.

[Bart Schaefer]

On Apr 11,  6:16am, Daniel Shahaf wrote:
} Subject: Re: [PATCH] Expose isearch and suffix regions to widgets.
}
} m0viefreak wrote on Sun, Apr 10, 2016 at 15:10:39 +0200:
} > ISEARCH_ACTIVE does not describe the fact that the minibuffer is active,
} > but the fact that a pattern that was typed in there does actually
} > matches the BUFFER.
} 
} Rename the shell parameter, then?

ISEARCH_MATCH ?  (I wonder if, like $MATCH, it could contain the actual
matched string, instead of merely being a boolean.)

Re: [PATCH] Expose isearch and suffix regions to widgets.

[m0viefreak]

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



On 11.04.2016 16:25, Bart Schaefer wrote:
> On Apr 11,  6:16am, Daniel Shahaf wrote:
> } Subject: Re: [PATCH] Expose isearch and suffix regions to widgets.
> }
> } m0viefreak wrote on Sun, Apr 10, 2016 at 15:10:39 +0200:
> } > ISEARCH_ACTIVE does not describe the fact that the minibuffer is active,
> } > but the fact that a pattern that was typed in there does actually
> } > matches the BUFFER.
> } 
> } Rename the shell parameter, then?
> 
> ISEARCH_MATCH ?  (I wonder if, like $MATCH, it could contain the actual
> matched string, instead of merely being a boolean.)


I think ISEARCH_MATCH would be the ideal name, if the matched string was
exposed, but I haven't found a simple way to do that.

On the other hand, I would also like to keep the _ACTIVE part at the
end, to keep all four of those special parameters named similarly:

{YANK,SUFFIX,REGION,ISEARCH}_ACTIVE

What do you think of ISEARCHMATCH_{ACTIVE,START,END}?

That would still reflect that it's merely a boolean flag, while still
keeping the semantic that it describes the match.


[-- Attachment #2: 0001-Change-names-of-ISEARCH_-parameters-to-ISEARCHMATCH_.patch --]
[-- Type: text/plain, Size: 4140 bytes --]

>From 94705d5f45981552bdf3241dc4b2aaa59a560d94 Mon Sep 17 00:00:00 2001
From: m0viefreak <m0viefreak.cm@googlemail.com>
Date: Sun, 10 Apr 2016 14:57:51 +0200
Subject: [PATCH] Change names of ISEARCH_* parameters to ISEARCHMATCH_*

---
 Doc/Zsh/zle.yo       | 21 +++++++++++----------
 Src/Zle/zle_params.c | 24 ++++++++++++------------
 2 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 161cef7..80d3f39 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -835,16 +835,17 @@ which always gives the number of the history line being added to the main
 shell's history.  tt(HISTNO) refers to the line being retrieved within
 zle.
 )
-vindex(ISEARCH_ACTIVE)
-vindex(ISEARCH_START)
-vindex(ISEARCH_END)
-xitem(tt(ISEARCH_ACTIVE) (integer))
-xitem(tt(ISEARCH_START) (integer))
-item(tt(ISEARCH_END) (integer))(
-tt(ISEARCH_ACTIVE) indicates whether an incremental search minibuffer
-is active. tt(ISEARCH_START) and tt(ISEARCH_END) give the location of
-the matched pattern and are in the same units as tt(CURSOR). They are
-only valid for reading when tt(ISEARCH_ACTIVE) is non-zero.
+vindex(ISEARCHMATCH_ACTIVE)
+vindex(ISEARCHMATCH_START)
+vindex(ISEARCHMATCH_END)
+xitem(tt(ISEARCHMATCH_ACTIVE) (integer))
+xitem(tt(ISEARCHMATCH_START) (integer))
+item(tt(ISEARCHMATCH_END) (integer))(
+tt(ISEARCHMATCH_ACTIVE) indicates whether a part of the tt(BUFFER) is
+currently matched by an incremental search pattern. tt(ISEARCHMATCH_START)
+and tt(ISEARCHMATCH_END) give the location of the matched part and are
+in the same units as tt(CURSOR). They are only valid for reading
+when tt(ISEARCHMATCH_ACTIVE) is non-zero.
 
 All parameters are read-only.
 )
diff --git a/Src/Zle/zle_params.c b/Src/Zle/zle_params.c
index 7cbb3df..c6387bf 100644
--- a/Src/Zle/zle_params.c
+++ b/Src/Zle/zle_params.c
@@ -103,12 +103,12 @@ static const struct gsu_integer yankend_gsu =
 { get_yankend, set_yankend, zleunsetfn };
 static const struct gsu_integer yankactive_gsu =
 { get_yankactive, NULL, zleunsetfn };
-static const struct gsu_integer isearchstart_gsu =
-{ get_isearchstart, NULL, zleunsetfn };
-static const struct gsu_integer isearchend_gsu =
-{ get_isearchend, NULL, zleunsetfn };
-static const struct gsu_integer isearchactive_gsu =
-{ get_isearchactive, NULL, zleunsetfn };
+static const struct gsu_integer isearchmatchstart_gsu =
+{ get_isearchmatchstart, NULL, zleunsetfn };
+static const struct gsu_integer isearchmatchend_gsu =
+{ get_isearchmatchend, NULL, zleunsetfn };
+static const struct gsu_integer isearchmatchactive_gsu =
+{ get_isearchmatchactive, NULL, zleunsetfn };
 static const struct gsu_integer suffixstart_gsu =
 { get_suffixstart, NULL, zleunsetfn };
 static const struct gsu_integer suffixend_gsu =
@@ -164,9 +164,9 @@ static struct zleparam {
     { "YANK_START", PM_INTEGER, GSU(yankstart_gsu), NULL },
     { "YANK_END", PM_INTEGER, GSU(yankend_gsu), NULL },
     { "YANK_ACTIVE", PM_INTEGER | PM_READONLY, GSU(yankactive_gsu), NULL },
-    { "ISEARCH_START", PM_INTEGER, GSU(isearchstart_gsu), NULL },
-    { "ISEARCH_END", PM_INTEGER, GSU(isearchend_gsu), NULL },
-    { "ISEARCH_ACTIVE", PM_INTEGER | PM_READONLY, GSU(isearchactive_gsu), NULL },
+    { "ISEARCHMATCH_START", PM_INTEGER, GSU(isearchmatchstart_gsu), NULL },
+    { "ISEARCHMATCH_END", PM_INTEGER, GSU(isearchmatchend_gsu), NULL },
+    { "ISEARCHMATCH_ACTIVE", PM_INTEGER | PM_READONLY, GSU(isearchmatchactive_gsu), NULL },
     { "SUFFIX_START", PM_INTEGER, GSU(suffixstart_gsu), NULL },
     { "SUFFIX_END", PM_INTEGER, GSU(suffixend_gsu), NULL },
     { "SUFFIX_ACTIVE", PM_INTEGER | PM_READONLY, GSU(suffixactive_gsu), NULL },
@@ -540,21 +540,21 @@ set_yankend(UNUSED(Param pm), zlong i)
 
 /**/
 static zlong
-get_isearchstart(UNUSED(Param pm))
+get_isearchmatchstart(UNUSED(Param pm))
 {
     return isearch_startpos;
 }
 
 /**/
 static zlong
-get_isearchend(UNUSED(Param pm))
+get_isearchmatchend(UNUSED(Param pm))
 {
     return isearch_endpos;
 }
 
 /**/
 static zlong
-get_isearchactive(UNUSED(Param pm))
+get_isearchmatchactive(UNUSED(Param pm))
 {
     return isearch_active;
 }
-- 
2.8.0

Re: [PATCH] Expose isearch and suffix regions to widgets.

[Daniel Shahaf]

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

m0viefreak wrote on Sat, Apr 16, 2016 at 18:17:40 +0200:
> 
> 
> On 11.04.2016 16:25, Bart Schaefer wrote:
> > On Apr 11,  6:16am, Daniel Shahaf wrote:
> > } Subject: Re: [PATCH] Expose isearch and suffix regions to widgets.
> > }
> > } m0viefreak wrote on Sun, Apr 10, 2016 at 15:10:39 +0200:
> > } > ISEARCH_ACTIVE does not describe the fact that the minibuffer is active,
> > } > but the fact that a pattern that was typed in there does actually
> > } > matches the BUFFER.
> > } 
> > } Rename the shell parameter, then?
> > 
> > ISEARCH_MATCH ?  (I wonder if, like $MATCH, it could contain the actual
> > matched string, instead of merely being a boolean.)
> 
> 
> I think ISEARCH_MATCH would be the ideal name, if the matched string was
> exposed, but I haven't found a simple way to do that.
> 

Something like the attached, perhaps?  Do you think something like this
should be added?  (Myself, I'm not sure, since the value would be
derivable from the three ISEARCHMATCH_* parameters' values.)

> On the other hand, I would also like to keep the _ACTIVE part at the
> end, to keep all four of those special parameters named similarly:
> 
> {YANK,SUFFIX,REGION,ISEARCH}_ACTIVE
> 
> What do you think of ISEARCHMATCH_{ACTIVE,START,END}?
> 
> That would still reflect that it's merely a boolean flag, while still
> keeping the semantic that it describes the match.

I've (rebased and) applied this.  We can tweak it further if needed.

Cheers,

Daniel

[-- Attachment #2: isearch_match-PoC-v1.diff --]
[-- Type: text/x-diff, Size: 2273 bytes --]

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 80d3f39..7c3e46b 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -835,6 +835,10 @@ which always gives the number of the history line being added to the main
 shell's history.  tt(HISTNO) refers to the line being retrieved within
 zle.
 )
+vindex(ISEARCH_MATCH)
+item(tt(ISEARCH_MATCH) (scalar))(
+TODO: TBW
+)
 vindex(ISEARCHMATCH_ACTIVE)
 vindex(ISEARCHMATCH_START)
 vindex(ISEARCHMATCH_END)
diff --git a/Src/Zle/zle_params.c b/Src/Zle/zle_params.c
index c6387bf..4f66be1 100644
--- a/Src/Zle/zle_params.c
+++ b/Src/Zle/zle_params.c
@@ -78,6 +78,8 @@ static const struct gsu_scalar widgetstyle_gsu =
 { get_widgetstyle, nullstrsetfn, zleunsetfn };
 static const struct gsu_scalar zle_state_gsu =
 { get_zle_state, nullstrsetfn, zleunsetfn };
+static const struct gsu_scalar isearchmatch_gsu =
+{ get_isearchmatch, NULL, zleunsetfn };
 
 static const struct gsu_integer bufferlines_gsu =
 { get_bufferlines, NULL, zleunsetfn };
@@ -167,6 +169,7 @@ static struct zleparam {
     { "ISEARCHMATCH_START", PM_INTEGER, GSU(isearchmatchstart_gsu), NULL },
     { "ISEARCHMATCH_END", PM_INTEGER, GSU(isearchmatchend_gsu), NULL },
     { "ISEARCHMATCH_ACTIVE", PM_INTEGER | PM_READONLY, GSU(isearchmatchactive_gsu), NULL },
+    { "ISEARCH_MATCH", PM_SCALAR | PM_READONLY, GSU(isearchmatch_gsu), NULL },
     { "SUFFIX_START", PM_INTEGER, GSU(suffixstart_gsu), NULL },
     { "SUFFIX_END", PM_INTEGER, GSU(suffixend_gsu), NULL },
     { "SUFFIX_ACTIVE", PM_INTEGER | PM_READONLY, GSU(suffixactive_gsu), NULL },
@@ -876,3 +879,26 @@ get_zle_state(UNUSED(Param pm))
 
     return zle_state;
 }
+
+/**/
+static char *
+get_isearchmatch(UNUSED(Param pm))
+{
+    Param pm_BUFFER;
+    const char *val_BUFFER;
+    char *val;
+    size_t nbytes;
+
+    /* ### TODO: Maybe just call get_buffer() directly without going through paramtab? */
+    pm_BUFFER  = (Param) paramtab->getnode(paramtab, "BUFFER");
+    val_BUFFER = pm_BUFFER->gsu.s->getfn(pm_BUFFER); /* heap allocated */
+
+    if (! isearch_active)
+	/* TODO: what to do? */;
+
+    nbytes = isearch_endpos - isearch_startpos;
+    val = zhalloc(nbytes + 1 /* NUL */);
+    strncpy(val, &val_BUFFER[isearch_startpos], nbytes);
+    val[nbytes] = '\0';
+    return val;
+}

Re: [PATCH] Expose isearch and suffix regions to widgets.

[Bart Schaefer]

On Apr 23,  9:36pm, Daniel Shahaf wrote:
}
} m0viefreak wrote on Sat, Apr 16, 2016 at 18:17:40 +0200:
} > I think ISEARCH_MATCH would be the ideal name, if the matched string was
} > exposed, but I haven't found a simple way to do that.
} 
} Something like the attached, perhaps?  Do you think something like this
} should be added?  (Myself, I'm not sure, since the value would be
} derivable from the three ISEARCHMATCH_* parameters' values.)

My point in suggesting ISEARCH_MATCH was to limit the feature to three
variables with "ISEARCH_" as a prefix.  This was countered with the
expressed desire to follow the "_ACTIVE" suffix pattern instead.  I'm
not particularly invested in this either way, but having *both* the
"_MATCH" and "_ACTIVE" variants is certainly redundant, and having
two different prefixes ("ISEARCH_" and "ISEARCHMATCH_") is annoying.

Other comments:

I will posit that isearch is rather different from YANK/SUFFIX/REGION
in that one might be interested in what the current search pattern is,
as well as what string is matched.

There are two existing variables LASTABORTEDSEARCH and LASTSEARCH which
refer to that search pattern, neither of which uses the "I", so maybe
these new three (or four or five) shouldn't use it either.

Those two variables aren't cleared when you start a new search, they
only change based on the final state of the search.

Re: [PATCH] Expose isearch and suffix regions to widgets.

[Daniel Shahaf]

Bart Schaefer wrote on Sat, Apr 23, 2016 at 15:33:56 -0700:
> I will posit that isearch is rather different from YANK/SUFFIX/REGION
> in that one might be interested in what the current search pattern is,
> as well as what string is matched.
> 
> There are two existing variables LASTABORTEDSEARCH and LASTSEARCH which
> refer to that search pattern, neither of which uses the "I", so maybe
> these new three (or four or five) shouldn't use it either.

I have no strong opinion regarding whether the new parameters should
have the "I" in their names.