Re: compset -q oddities

[Bart Schaefer <schaefer@brasslantern.com>]

On Sep 14,  9:31am, Peter Stephenson wrote:
} Subject: Re: compset -q oddities
}
} On Tue, 13 Sep 2016 22:20:29 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > Well, no, not really.  "compset -q" should make note that there were
} > no quotes when it was called, and therefore not restore any quote on
} > the way back out.  There's a comment above compcore.c:307
} > 
} >     /*
} >      * It looks like we may need to do stuff with backslashes even
} >      * if instring is QT_NONE.
} >      */
} 
} I think the point is related to the fact that in the case of backslashes
} we never know there are no quotes.

Aha.  So if we see a word that starts with backslash, instring will be
QT_BACKSLASH, but when instring is QT_NONE, we do not know whether any
other backslashes appear in the middle of the word.

However, as I said in a previous reply:

>> The problem isn't really with the backslash being added there, it's
>> somewhere later on when the prefix is being compared to the candidate
>> match and one side of gets too much (? different?) quoting before the
>> comparison is made.

That later stage [wherever it is, I suspect comp_match()] also expects
that quoting has been manipulated in this way, and so if it has *not*
(I played with compcore.c:307) then strings that should match, do not.

The problem is that we have [at least] three sources of data:  The
literal command line, the (possibly quoting-manipulated) subset of
the command line against which completion is being attempted, and the
candidate matches passed to compadd.  Canonicalizing in a way that
makes it possible to compare any two of the three is very difficult.