PATCH: Don't store ZLE_LINE_ABORTED in vared context

PATCH: Don't store ZLE_LINE_ABORTED in vared context

[Mikael Magnusson]

The description of the parameter itself says

ZLE_LINE_ABORTED
       This  parameter  is  set  by the line editor when an error occurs.  It
       contains the line that was being edited at the  point  of  the  error.
       `print  -zr  --  $ZLE_LINE_ABORTED'  can  be used to recover the line.
       Only the most recent line of this kind is remembered.

and the description of send-break says

send-break (^G ESC-^G) (unbound) (unbound)
       Abort  the current editor function, e.g. execute-named-command, or the
       editor itself, e.g. if you are in vared. Otherwise abort  the  parsing
       of the current line; in this case the aborted line is available in the
       shell variable ZLE_LINE_ABORTED.

However, pressing ctrl-c inside vared stores whatever was being edited
in ZLE_LINE_ABORTED, which the above seems to imply should not happen.
The following adjusts the code accordingly. It was actually a bit
annoying if you set up a widget to do the up-line-or-aborted, because
it will grab the vared text as a command then.

diff --git a/Src/Zle/zle_main.c b/Src/Zle/zle_main.c
index f344ecc..5b1d5f9 100644
--- a/Src/Zle/zle_main.c
+++ b/Src/Zle/zle_main.c
@@ -1252,7 +1252,7 @@ zleread(char **lp,

     zlecore();

-    if (errflag)
+    if (errflag && zlecontext != ZLCON_VARED)
        setsparam("ZLE_LINE_ABORTED", zlegetline(NULL, NULL));

     if (done && !exit_pending && !errflag)



-- 
Mikael Magnusson

Re: PATCH: Don't store ZLE_LINE_ABORTED in vared context

[Bart Schaefer]

On Mar 4,  7:40pm, Mikael Magnusson wrote:
} Subject: PATCH: Don't store ZLE_LINE_ABORTED in vared context
}
} send-break (^G ESC-^G) (unbound) (unbound)
}        Abort  the current editor function, e.g. execute-named-command, or the
}        editor itself, e.g. if you are in vared. Otherwise abort  the  parsing
}        of the current line; in this case the aborted line is available in the
}        shell variable ZLE_LINE_ABORTED.
} 
} However, pressing ctrl-c inside vared stores whatever was being edited
} in ZLE_LINE_ABORTED, which the above seems to imply should not happen.

Another documentation error rather than code error, IMO.

} The following adjusts the code accordingly. It was actually a bit
} annoying if you set up a widget to do the up-line-or-aborted, because
} it will grab the vared text as a command then.

Hrm, perhaps, but I believe the intent was to be able to hang on to
whatever buffer was most recently being edited when the interrupt came
through.

Re: PATCH: Don't store ZLE_LINE_ABORTED in vared context

[Mikael Magnusson]

On Thu, Mar 5, 2015 at 2:57 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Mar 4,  7:40pm, Mikael Magnusson wrote:
> } Subject: PATCH: Don't store ZLE_LINE_ABORTED in vared context
> }
> } send-break (^G ESC-^G) (unbound) (unbound)
> }        Abort  the current editor function, e.g. execute-named-command, or the
> }        editor itself, e.g. if you are in vared. Otherwise abort  the  parsing
> }        of the current line; in this case the aborted line is available in the
> }        shell variable ZLE_LINE_ABORTED.
> }
> } However, pressing ctrl-c inside vared stores whatever was being edited
> } in ZLE_LINE_ABORTED, which the above seems to imply should not happen.
>
> Another documentation error rather than code error, IMO.
>
> } The following adjusts the code accordingly. It was actually a bit
> } annoying if you set up a widget to do the up-line-or-aborted, because
> } it will grab the vared text as a command then.
>
> Hrm, perhaps, but I believe the intent was to be able to hang on to
> whatever buffer was most recently being edited when the interrupt came
> through.

So how should I handle this case in my shell widget then? I think pws
introduced the feature so maybe he can clarify. (I won't push the
commit in the meantime).

-- 
Mikael Magnusson

Re: PATCH: Don't store ZLE_LINE_ABORTED in vared context

[Bart Schaefer]

On Mar 5,  3:41am, Mikael Magnusson wrote:
} Subject: Re: PATCH: Don't store ZLE_LINE_ABORTED in vared context
}
} On Thu, Mar 5, 2015 at 2:57 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:
} > } annoying if you set up a widget to do the up-line-or-aborted, because
} > } it will grab the vared text as a command then.
} >
} > Hrm, perhaps, but I believe the intent was to be able to hang on to
} > whatever buffer was most recently being edited when the interrupt came
} > through.
} 
} So how should I handle this case in my shell widget then?

Based on this:  http://www.zsh.org/mla/workers/2010/msg00702.html

I wonder if the solution is that zle-line-finish should be called even
when the editor is aborted with send-break.

However, you should be able to do something like

zle-line-init() {
  if [[ $LAST_CONTEXT = vared ]]
  then unset ZLE_LINE_ABORTED
  else : your thing with ZLE_LINE_SAVED
  fi
  LAST_CONTEXT=$CONTEXT
}

} I think pws introduced the feature so maybe he can clarify.

Look at http://www.zsh.org/mla/workers/2010/msg00681.html and then
http://www.zsh.org/mla/workers/2010/msg00685.html ...

> Hmm... I'm wondering if I put it in the right place.  sendbreak can abort
> other things than the full line edit, and I already claimed that "this
> parameter is set by the line editor when an error occurs", which as you
> spotted isn't necessarily true.

I think the intent was to capture "other things than the full line edit"
with ZLE_LINE_ABORT.  But yes, let PWS weigh in.

Re: PATCH: Don't store ZLE_LINE_ABORTED in vared context

[Peter Stephenson]

On Wed, 4 Mar 2015 19:40:03 +0100
Mikael Magnusson <mikachu@gmail.com> wrote:
> send-break (^G ESC-^G) (unbound) (unbound)
>        Abort  the current editor function, e.g. execute-named-command, or the
>        editor itself, e.g. if you are in vared. Otherwise abort  the  parsing
>        of the current line; in this case the aborted line is available in the
>        shell variable ZLE_LINE_ABORTED.
> 
> However, pressing ctrl-c inside vared stores whatever was being edited
> in ZLE_LINE_ABORTED, which the above seems to imply should not happen.
> The following adjusts the code accordingly. It was actually a bit
> annoying if you set up a widget to do the up-line-or-aborted, because
> it will grab the vared text as a command then.

I'm not really sure I decided clearly one way or the other which was
likely to be better, so it's more a matter for experience rather than
the original intention.  I do seem to have been fairly deliberate with
the documentation, though; the "otherwise" doesn't seem to leave much
doubt.

Having the variable set in special cases is a bit of a headache, I
agree, since you don't necessarily know they're there, even if there are
ways round.

It would be tempting to have a different variable for the vared case
such as ZLE_VARED_ABORTED.

pws

Re: PATCH: Don't store ZLE_LINE_ABORTED in vared context

[Peter Stephenson]

On Thu, 5 Mar 2015 09:59:44 +0000
Peter Stephenson <p.stephenson@samsung.com> wrote:
> Having the variable set in special cases is a bit of a headache, I
> agree, since you don't necessarily know they're there, even if there are
> ways round.
> 
> It would be tempting to have a different variable for the vared case
> such as ZLE_VARED_ABORTED.

This would same to cover all the bases, except for the case where
someone really wants to use the same variable to deal with vared and the
shell command line.  Mikael's experience suggests that's not the most
obvious or convenient case.

pws

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index dd8e628..b8b9b8c 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -2223,7 +2223,8 @@ item(tt(send-break) (^G ESC-^G) (unbound) (unbound))(
 Abort the current editor function, e.g. tt(execute-named-command), or the
 editor itself, e.g. if you are in tt(vared). Otherwise abort the parsing of
 the current line; in this case the aborted line is available in the shell
-variable tt(ZLE_LINE_ABORTED).
+variable tt(ZLE_LINE_ABORTED).  If the editor is aborted from within
+tt(vared), the variable tt(ZLE_VARED_ABORTED) is set.
 )
 tindex(run-help)
 item(tt(run-help) (ESC-H ESC-h) (unbound) (unbound))(
diff --git a/Src/Zle/zle_main.c b/Src/Zle/zle_main.c
index a2f48e1..cec44c0 100644
--- a/Src/Zle/zle_main.c
+++ b/Src/Zle/zle_main.c
@@ -1253,7 +1253,9 @@ zleread(char **lp, char **rp, int flags, int context, char *init, char *finish)
     zlecore();
 
     if (errflag)
-	setsparam("ZLE_LINE_ABORTED", zlegetline(NULL, NULL));
+	setsparam((zlecontext == ZLCON_VARED) ?
+		  "ZLE_VARED_ABORTED" :
+		  "ZLE_LINE_ABORTED", zlegetline(NULL, NULL));
 
     if (done && !exit_pending && !errflag)
 	zlecallhook(finish, NULL);

Re: PATCH: Don't store ZLE_LINE_ABORTED in vared context

[Peter Stephenson]

On Thu, 5 Mar 2015 13:58:30 +0000
Peter Stephenson <p.stephenson@samsung.com> wrote:
> On Thu, 5 Mar 2015 09:59:44 +0000
> Peter Stephenson <p.stephenson@samsung.com> wrote:
> > Having the variable set in special cases is a bit of a headache, I
> > agree, since you don't necessarily know they're there, even if there are
> > ways round.
> > 
> > It would be tempting to have a different variable for the vared case
> > such as ZLE_VARED_ABORTED.
> 
> This would same to cover all the bases, except for the case where
> someone really wants to use the same variable to deal with vared and the
> shell command line.  Mikael's experience suggests that's not the most
> obvious or convenient case.
>...
> +variable tt(ZLE_LINE_ABORTED).  If the editor is aborted from within
> +tt(vared), the variable tt(ZLE_VARED_ABORTED) is set.

There didn't seem to be more comments on this, and the participants
in the discussion are certainly alive and kicking, so I've pushed it.

pws

Re: PATCH: Don't store ZLE_LINE_ABORTED in vared context

[Mikael Magnusson]

On Fri, Mar 6, 2015 at 10:52 AM, Peter Stephenson
<p.stephenson@samsung.com> wrote:
> On Thu, 5 Mar 2015 13:58:30 +0000
> Peter Stephenson <p.stephenson@samsung.com> wrote:
>> On Thu, 5 Mar 2015 09:59:44 +0000
>> Peter Stephenson <p.stephenson@samsung.com> wrote:
>> > Having the variable set in special cases is a bit of a headache, I
>> > agree, since you don't necessarily know they're there, even if there are
>> > ways round.
>> >
>> > It would be tempting to have a different variable for the vared case
>> > such as ZLE_VARED_ABORTED.
>>
>> This would same to cover all the bases, except for the case where
>> someone really wants to use the same variable to deal with vared and the
>> shell command line.  Mikael's experience suggests that's not the most
>> obvious or convenient case.
>>...
>> +variable tt(ZLE_LINE_ABORTED).  If the editor is aborted from within
>> +tt(vared), the variable tt(ZLE_VARED_ABORTED) is set.
>
> There didn't seem to be more comments on this, and the participants
> in the discussion are certainly alive and kicking, so I've pushed it.

Oh oops, yes, meant to say this change is good with me.

-- 
Mikael Magnusson