Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: [PATCH] Fix a logic bug in _zle

On Tue, Jun 1, 2021 at 12:56 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Mon, May 31, 2021 at 10:49 AM Marlon Richert
> <marlon.richert@xxxxxxxxx> wrote:
> >
> > On Mon, May 31, 2021 at 8:08 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > >
> > > For purposes of the commit log, we should be told what this means in
> > > terms of a behavior change.
> >
> > Is it good enough this way?
> Better, but you could have just said that in the email text rather
> than embed it in the patch file.

Ah, OK. I thought you meant I should include it in the patch itself.

> However, I can't figure out when $state[1] == widget-function is ever
> true.  Did you possibly mean widget-or-function ?  If not, can you
> give an example?

Sorry, typo. Yes, I meant widget-or-function. But actually, I realize
now that I made further mistakes in my explanation yesterday evening.
I'll try to explain better.

What happens in the unpatched _zle code is this:
* On line 54, `;&` causes the (widget*) case to always proceed to the
(function) case.
* On line 56, `[[ $state[1] != *function ]] ||` checks to see whether
the flow should actually continue from (widget*) to (function).
* However,
  * when `[[ $state[1] != *function ]]` is true,
  * then we correctly skip the _wanted call on lines 57-58,
  * but because the _wanted call is followed by `&& ret=0`
  * and because || and && have equal precedence and are left associative,
  * then we incorrectly do `ret=0`,

So, to correctly summarize the bug: When $state[1] == widget, _zle
always returns 0, instead of returning 0 for success and non-zero for
failure. The patch fixes this. If you could update the commit message
accordingly, that would be great.

Apologies for the confusion.

Messages sorted by: Reverse Date, Date, Thread, Author