Re: compset -q oddities

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 14,  3:22am, Daniel Shahaf wrote:
} Subject: Re: compset -q oddities
}
} Bart Schaefer wrote on Mon, Sep 12, 2016 at 23:28:53 -0700:
} > You didn't start from ~~~.  You started from an empty word and typed
} > TAB twice.  ~~~ was never on the line.  I concur that the result of
} > the second attempt is weird, I would have expected it just to fail.
} 
} I would have expected the second <TAB> press to do nothing

If the first tab had correctly produced one of ~~~ or \~\~\~ then I
would have expected the second tab to do nothing, but given what the
first tab incorrectly burped out, it should have failed.

Also now that I think of it, there's only one match with that compadd,
so it should have appended a trailing space and the second tab should
have been in an entirely new (also empty) word.

} > On the first tab (empty word), the prefix is empty but "compset -q"
} > causes completion to believe there is quoting on the line (backslash
} > by default).  The compadd call makes ~~~ a valid completion, which
} > when added is quoted to \~\~\~.  The effect of compset is then undone,
} > meaning the backslash-quoting that was presumed removed is restored,
} > and you end up with \\\~\\\~\\\~.
} 
} All this is fine.

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.
     */

Peter, that was you in workers/22819, can you explain?

} It would also have been correct for the first level of quoting not to
} occur, since "~~~" doesn't need command-line escaping.

As noted later, this is because of extendedglob.  Examining each tilde
in isolation, quotestring() has to assume the string may be interpreted
as an X~Y pattern, so it quotes all tildes.

} This makes sense as far as quotestring() is concerned, but when called
} from completion, this causes the tilde to be quoted even though
} ${_comp_caller_options[extendedglob]} is unset.

Indeed.  It might make sense for the internals to save the top-level
option state on entry and implicitly re-assert it during compadd.

} The backslash in \\~~~ is probably added by quotestring() [despite
} unsetting extendedglob] because the 'u==s' part of the condition

That's exactly what happens, and is also why a leading = gets quoted.

} Perhaps making quotestring() not add that redundant first
} backslash would workaround the issue

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.  I haven't figured out where that is, yet (and am
not going to try too hard, honestly).