What exactly does it mean to complete inside $'...' anyway?

What exactly does it mean to complete inside $'...' anyway?

[Bart Schaefer]

It occurs to me I have no idea what is intended to happen in the case of

% : $'<TAB>x

for any particular values of "x", which might be e.g. $'\07' or $'\M-x'.
Same goes for

% : $'<TAB>x'

or even

% : $'x<TAB>'

the latter of which doesn't produce any debug warnings but doesn't seem
to do anything helpful either.

-- 
Barton E. Schaefer

Re: What exactly does it mean to complete inside $'...' anyway?

[Peter Stephenson]

On Sun, 12 Oct 2014 13:49:36 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> It occurs to me I have no idea what is intended to happen in the case of
> 
> % : $'<TAB>x
> 
> for any particular values of "x", which might be e.g. $'\07' or $'\M-x'.
> Same goes for
> 
> % : $'<TAB>x'
> 
> or even
> 
> % : $'x<TAB>'
> 
> the latter of which doesn't produce any debug warnings but doesn't seem
> to do anything helpful either.

I don't think it's doing anything other than normal completion,
i.e. files in this case.  The only thing special is taking accoung of
how existing characters may be quoted.

Furthermore, I don't think there's ever been any (intentional) effort to
try to interpret the special $'...' quoting when completing inside.
The idea is if you have a complete $'...' you put it there by hand
to get some weird characters onto the command line.  If you're
completing inside it, or it's unfinished you just take what the
completion system gives you.

That doesn't necessarily reflect what's actually happening.

pws

Re: What exactly does it mean to complete inside $'...' anyway?

[Oliver Kiddle]

Bart wrote:
> 
> % : $'<TAB>x
> 
> for any particular values of "x", which might be e.g. $'\07' or $'\M-x'.
> Same goes for

The intent of existing zsh functionality (aside from bugs) seems to be
that quoting is ignored for the purposes of matching. So if you have
$'\x41', it will look for a completion candidate (filename or whatever)
that matches uppercase A. The x character forming part of the suffix
rather than the prefix doesn't really make much difference other than
the expected position of completed characters. For $'...' style quotes
I'm not sure anything else would be especially useful: either filtering
matches that would need special quoting or completing sequences like
\M-x.

When inserting a completion match, zsh seems to use the quoting style
from the first character. The ideal would be to preserve existing
quoting as far as possible.

By default a \ is removed when completing directly after it which is
especially useless. (I've largely worked around this my binding \ to a
custom widget.)

Oliver

Re: What exactly does it mean to complete inside $'...' anyway?

[Bart Schaefer]

Reordering a little because there's a wad of new stuff at the end.

On Oct 13,  2:21pm, Oliver Kiddle wrote:
}
} When inserting a completion match, zsh seems to use the quoting style
} from the first character. The ideal would be to preserve existing
} quoting as far as possible.

Yeah, we've been over that several times over the years.  The problem is
that completion has to arbitrarily rewrite the word on the line (think
complete_in_word, for example, or partial path completion) and it's
just too difficult to line up the original input with the result to
determine where the quotes should be inserted, especially with nested
quoting like backslashes inside quotes.

} By default a \ is removed when completing directly after it which is
} especially useless. (I've largely worked around this my binding \ to a
} custom widget.)

The backslash is removed because it appears to be extraneous and will
be put back if it's needed ... if e.g. you complete filenames in a
directory where all the files begin with characters that need quoting,
the backslash remains:

torch% touch '*foo' '"bar' '#this'
torch% : \
\"bar   \*foo   \#this

Add a file that doesn't need the backslash and then you can see what's
going on by doing a listing:

torch% touch other
torch% : \<ctrl+d>
\"bar   \*foo   other   \#this

Since "other" is a valid completion that doesn't have "\" as a prefix,
the backslash is removed when completing instead of listing.

} The intent of existing zsh functionality (aside from bugs) seems to be
} that quoting is ignored for the purposes of matching.

OK.  For what it's worth, that produces the correct output in both of
the cases that print these "BUG" warnings.  I suspect the "unterminated
substitution" warning could just be removed if we can determine that the
call came from completion.  The other one is a bit more serious:

torch% $' ../../../zsh-5.0/Src/Zle/zle_tricky.c:666: BUG: 0 <= wb <= zlemetacs
<= we is not true!
*** glibc detected *** realloc(): invalid size: 0x091667d8 ***
Program received signal SIGABRT, Aborted.

Crashed reading the value of "compstate" so probably the actual error is
elsewhere, but here's a bit of stack trace:

#5  0x008ed7ec in realloc () from /lib/tls/libc.so.6
#6  0x081332e6 in sizeline (sz=5) at ../../../zsh-5.0/Src/Zle/zle_utils.c:79
#7  0x08133faf in spaceinline (ct=1)
    at ../../../zsh-5.0/Src/Zle/zle_utils.c:754
#8  0x081312b5 in inststrlen (str=0xb7d12c40 "'", move=0, len=1)
    at ../../../zsh-5.0/Src/Zle/zle_tricky.c:2151
#9  0x080fce1b in cline_str (l=0xb7d12ea0, ins=0, csp=0x8168b68, 
    posl=0xb7cf03d8) at ../../../zsh-5.0/Src/Zle/compresult.c:376
#10 0x080fd379 in unambig_data (cp=0x0, pp=0x0, ip=0x0)
    at ../../../zsh-5.0/Src/Zle/compresult.c:535
#11 0x080ecf58 in get_unambig (pm=0x9135f30)
    at ../../../zsh-5.0/Src/Zle/complete.c:1295
#12 0x0809e244 in getstrvalue (v=0xbfe41a90) at ../../zsh-5.0/Src/params.c:1997
#13 0x0809aae0 in scanparamvals (hn=0x9135f30, flags=259)
    at ../../zsh-5.0/Src/params.c:578
#14 0x08074908 in scanmatchtable (ht=0x9189e30, pprog=0x0, sorted=0, flags1=0, 
    flags2=33554432, scanfunc=0x809a9a2 <scanparamvals>, scanflags=259)
    at ../../zsh-5.0/Src/hashtable.c:428
#15 0x0807494e in scanhashtable (ht=0x9189e30, sorted=0, flags1=0, 
    flags2=33554432, scanfunc=0x809a9a2 <scanparamvals>, scanflags=259)
    at ../../zsh-5.0/Src/hashtable.c:444
#16 0x0809ac27 in paramvalarr (ht=0x9189e30, flags=259)
    at ../../zsh-5.0/Src/params.c:602
#17 0x0809acd7 in getvaluearr (v=0xbfe41df0) at ../../zsh-5.0/Src/params.c:620
#18 0x0809e900 in getarrvalue (v=0xbfe41df0) at ../../zsh-5.0/Src/params.c:2175
#19 0x080bdb53 in paramsubst (l=0xb7cf45c0, n=0xb7cf45cc, str=0xbfe41ec8, 
    qt=1, pf_flags=0) at ../../zsh-5.0/Src/subst.c:2412
#20 0x080b9eb2 in stringsubst (list=0xb7cf45c0, node=0xb7cf45cc, pf_flags=0, 
    asssub=0) at ../../zsh-5.0/Src/subst.c:236
#21 0x080b966a in prefork (list=0xb7cf45c0, flags=2)
    at ../../zsh-5.0/Src/subst.c:77
#22 0x0806537c in addvars (state=0xbfe42860, pc=0x912e7e4, addflags=0)
    at ../../zsh-5.0/Src/exec.c:2239
#23 0x08066619 in execcmd (state=0xbfe42860, input=0, output=0, how=2, last1=2)
    at ../../zsh-5.0/Src/exec.c:2683
#24 0x08064039 in execpline2 (state=0xbfe42860, pcode=23683, how=2, input=0, 
    output=0, last1=0) at ../../zsh-5.0/Src/exec.c:1697
#25 0x080633de in execpline (state=0xbfe42860, slcode=5122, how=2, last1=0)
    at ../../zsh-5.0/Src/exec.c:1484
#26 0x08062cb6 in execlist (state=0xbfe42860, dont_change_job=1, exiting=0)
    at ../../zsh-5.0/Src/exec.c:1267
#27 0x080626ee in execode (p=0x9128090, dont_change_job=1, exiting=0, 
    context=0x813d0c8 "shfunc") at ../../zsh-5.0/Src/exec.c:1073
#28 0x0806bb62 in runshfunc (prog=0x9128090, wrap=0x0, 
    name=0xb7d08038 "_main_complete") at ../../zsh-5.0/Src/exec.c:5040
#29 0x080ed470 in comp_wrapper (prog=0x9128090, w=0x0, 
    name=0xb7d08038 "_main_complete")
    at ../../../zsh-5.0/Src/Zle/complete.c:1455