Evaluating parameters in general-purpose widgets

Evaluating parameters in general-purpose widgets

[Daniel Shahaf]

zsh-syntax-highlighting is designed to run as a zle-line-pre-redraw widget.

Is it safe for zsh-syntax-highlighting to evaluate parameter expansions
in the input?

Things like «${:-`foo`}» and «${foo:=bar}» clearly may have side effects
and are not evaluated by z-sy-h under any circumstances.  However, what
about simple expressions such as «${foo}»?  Even those can have side
effects when $foo is provided by a module:

[[[
diff --git a/Src/Modules/parameter.c b/Src/Modules/parameter.c
index 10c47d214..789d262fe 100644
--- a/Src/Modules/parameter.c
+++ b/Src/Modules/parameter.c
@@ -1821,6 +1821,24 @@ setpmdissaliases(Param pm, HashTable ht)
     setaliases(sufaliastab, pm, ht, ALIAS_SUFFIX|DISABLED);
 }
 
+/* autoincrement */
+
+static zlong autoincrement = 0;
+
+/**/
+static zlong
+autoincrementgetfn(UNUSED(Param pm))
+{
+    return ++autoincrement;
+}
+
+/**/
+static void
+autoincrementsetfn(UNUSED(Param pm), zlong value)
+{
+    autoincrement = value;
+}
+
 static const struct gsu_scalar pmralias_gsu =
 { strgetfn, setpmralias, unsetpmalias };
 static const struct gsu_scalar pmgalias_gsu =
@@ -2168,6 +2186,8 @@ static const struct gsu_hash pmdisgaliases_gsu =
 { hashgetfn, setpmdisgaliases, stdunsetfn };
 static const struct gsu_hash pmdissaliases_gsu =
 { hashgetfn, setpmdissaliases, stdunsetfn };
+static const struct gsu_integer pmautoincrement_gsu =
+{ autoincrementgetfn, autoincrementsetfn, stdunsetfn };
 
 static const struct gsu_array funcstack_gsu =
 { funcstackgetfn, arrsetfn, stdunsetfn };
@@ -2254,7 +2274,9 @@ static struct paramdef partab[] = {
     SPECIALPMDEF("userdirs", PM_READONLY,
 	    NULL, getpmuserdir, scanpmuserdirs),
     SPECIALPMDEF("usergroups", PM_READONLY,
-	    NULL, getpmusergroups, scanpmusergroups)
+	    NULL, getpmusergroups, scanpmusergroups),
+    SPECIALPMDEF("autoincrement", PM_INTEGER,
+	    &pmautoincrement_gsu, NULL, NULL)
 };
 
 static struct features module_features = {
% 
% zmodload zsh/parameter
% print $autoincrement $autoincrement
1 2
% 
]]]

So...

1. Suppose [[ $BUFFER == 'echo $foobar' ]], is it safe for a
general-purpose widget (= z-sy-h) to evaluate $foobar?

2. Likewise, after checking that «[[ ${parameters[foobar]} != *special* ]]»?

Cheers,

Daniel

P.S. Currently, the only case in which z-sy-h expands parameters is when
they appear at command position, in order to know what the effective
command word (after expansions) is.

P.P.S. I wasn't going to commit the above, and it has some quirks (for
example, evaluating ${+autoincrement} increments the parameter), but if
there's interest let me know.

Re: Evaluating parameters in general-purpose widgets

[Bart Schaefer]

On Thu, Jan 18, 2018 at 4:21 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Is it safe for zsh-syntax-highlighting to evaluate parameter expansions
> in the input?

Depending on how costly you're willing to make this, you could always
use "${$(print -nr -- "$foobar"X)#X}" to assure the parameter is
evaluated where it can't have any effects on the current shell.

Re: Evaluating parameters in general-purpose widgets

[Bart Schaefer]

On Thu, Jan 18, 2018 at 10:25 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> use "${$(print -nr -- "$foobar"X)#X}"

That should say %X of course.  Also meant to point out that
adding/removing the trailing "X" is to force newlines to be kept in
$(...).

Re: Evaluating parameters in general-purpose widgets

[Daniel Shahaf]

Bart Schaefer wrote on Thu, 18 Jan 2018 22:25 -0800:
> On Thu, Jan 18, 2018 at 4:21 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > Is it safe for zsh-syntax-highlighting to evaluate parameter expansions
> > in the input?
> 
> Depending on how costly you're willing to make this, you could always
> use "${$(print -nr -- "$foobar"X)%X}" to assure the parameter is
> evaluated where it can't have any effects on the current shell.

That's a handy idiom :-).

In this case, however, I can think of two issues with it: it wouldn't be
performant on platforms where fork() is expensive, and it would mess
with modules-provided parameters whose getfn uses out-of-process state.

Therefore, I'm currently inclined to
.
    if $parameters[foobar] == *special* ; then
        # leave it alone
    else
        # expand it using ${(P)${:-foobar}}
    fi
.
to sidestep module-provided parameters entirely.

Thanks,

Daniel

P.S. For anyone else reading this: using ${(P)} like that is only
     correct when SH_WORD_SPLIT hasn't been set.