zle_tricky.c:659: BUG: 0 <= wb (4) <= zlemetacs (2) <= we (5) is not true!

zle_tricky.c:659: BUG: 0 <= wb (4) <= zlemetacs (2) <= we (5) is not true!

[Daniel Shahaf]

To reproduce:

$ zsh -f
% echo $ZSH_PATCHLEVEL
0920bc6881af979ec538c8ab635c07f52601de4b
% : 2>1[move the cursor such that LBUFFER=": "][press <TAB>]
% :  zle_tricky.c:659: BUG: 0 <= wb (4) <= zlemetacs (2) <= we (5) is not true!
  : 2>1

It's this line from docomplete():

    DPUTS3(wb < 0 || zlemetacs < wb || zlemetacs > we,
          "BUG: 0 <= wb (%d) <= zlemetacs (%d) <= we (%d) is not true!",
           wb, zlemetacs, we);                                                  

That line was last mentioned in users/20042 (in the discussions about
whether to commit 34781).

It reproduces in 5.0.7 too (didn't check older).

Re: zle_tricky.c:659: BUG: 0 <= wb (4) <= zlemetacs (2) <= we (5) is not true!

[Peter Stephenson]

On Thu, 29 Oct 2015 13:12:53 +0000
Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> To reproduce:
> 
> $ zsh -f
> % echo $ZSH_PATCHLEVEL
> 0920bc6881af979ec538c8ab635c07f52601de4b
> % : 2>1[move the cursor such that LBUFFER=": "][press <TAB>]
> % :  zle_tricky.c:659: BUG: 0 <= wb (4) <= zlemetacs (2) <= we (5) is not true!
>   : 2>1

inredir and linredir in get_comp_string() probably have something to do
with this.  It looks like the "word" it thinks it's on is the "1" after
the ">", rather than the "2" before it.

It would probably be sensible to take the attitude that we just shrug
our shoulders until somebody volunteers to rewrite get_comp_string()
properly to use a state machine.

However, sense and completion code maintainance have never had a lot to
do with one another.

pws