Re: tab inserts literal tab instead of completing at beginning of line

[Mikael Magnusson <mikachu@gmail.com>]

On 23 May 2011 18:57, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On May 23,  4:55am, Mikael Magnusson wrote:
> }
> } On 23 May 2011 04:27, Bart Schaefer <schaefer@brasslantern.com> wrote:
> } > You're running into a strange combination of effects.  The completion
> } > internals initialize compstate[insert]=tab only when an actual tab is
> } > pressed, but the effect of explicitly assigning compstate[insert]=tab
> } > inside a completion function is to change the final keystroke into a
> } > self-insert.
>
> I'm trying to decide if this is worth documenting.
>
> } A tangent, I was just staring at these tests, and the (|[[:blank:]]*)
> } thing that appears on both sides, shouldn't the asterisk be to the left
> } of the blank when the thing is to the left of the word?
>
> I think you're correct about that.  There may be a few places that need
> that change.

I did a quick grep for the exact pattern that occurs here, and only
found it in _pids, and that already has the * on the right side.

> The two patches at the end of your message look fine if you want to
> commit one or the other (the "empty" one needs doc added, of course).

Okay, I'll commit the one without (the one with doesn't add it, it was
just on top of your patch). Is the patch to add "empty" pretty
uncontroversial if I add docs to it? I was a bit worried the subst +
length check might be a bit slow, but I ran a loop doing it 10000
times on a 1000 or so char long string and it only took 2 seconds or
so.

Is there some problem with zsh.org? I can't access www.zsh.org for the
mla to look up the number of my patch (gmail discards mailing lists
mails from yourself (sigh)), and iirc it was out a few days ago too.

-- 
Mikael Magnusson