Re: bug with completion in quotes

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 12,  9:15pm, Peter Stephenson wrote:
}
} > I think this is zsh-workers/23809, commit
} > e0a3e74b15fd39b21ef1770e67e2f005321b5fb9, going off at the wrong time.
} > It was supposed to apply to expanding complete $'...' expressions, but
} > in this case it's being applied to an uncompleted completion.
} > 
} > It looks like the intended purpose is basically OK since completing
} > after a $'...' works OK, at least in simple cases.  So it may be we
} > simply need to skip the code added by that change --- simply setting
} > skipchars to 2 instead looks like it's probably the right thing to do
} > --- if we're in the middle of it.
} 
} Sigh.  Nope.  I think it *is* doing the skipchars == 2 branch but that's
} not the right thing to do for some reason.  I don't know what is.

So below I'm talking about the incomplete $'x expression.  The case of
the $'x' expression with the wb <= zlemetacs may be different.

I've GDB'd through it and it's definitely taking the branch that begins
(zle_tricky.c) with the comment

		/*
		 * Try and substitute the $'...' expression.
		 */

If it took the skipchars = 2 branch it'd never hit the DPUTS that got
this whole thread started.

Comment in utils.c:

 * *misc is used for various purposes:
 * - If GETKEY_UPDATE_OFFSET is set, it is set on input to some
 *   mystical completion offset and is updated to a new offset based
 *   on the converted characters.  All Hail the Completion System
 *   [makes the mystic completion system runic sign in the air].

But nothing ever passes GETKEY_UPDATE_OFFSET.  That branch of zle_tricky
looks like the only reasonable place to use that, but I don't know what
mystical offset is meant to be passed in *misc and returned updated.
Maybe &skipchars ?  But what value should it start with?

Note that both of these bugs only occur when the completion is at the
START of the $'x' expression (before the "x").  When after the x or
after the whole expression, everything works OK.

So maybe the problem is that getkeystring() is reading too far ahead
and returning the length of the entire $'...' (or the length so far,
in the case of the unclosed quote) and really what we want is only
the length up to the cursor position?