zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: compset -q oddities
Date: Tue, 13 Sep 2016 22:20:29 -0700	[thread overview]
Message-ID: <160913222029.ZM13117@torch.brasslantern.com> (raw)
In-Reply-To: <20160914032254.GA32528@fujitsu.shahaf.local2>

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).


  reply	other threads:[~2016-09-14  5:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-11  7:30 Daniel Shahaf
2016-09-12  2:14 ` Bart Schaefer
2016-09-12 23:06   ` Daniel Shahaf
2016-09-13  6:28     ` Bart Schaefer
2016-09-13 10:21       ` Peter Stephenson
2016-09-14 17:56         ` Bart Schaefer
2016-09-15  5:10           ` Daniel Shahaf
2016-09-16  0:40             ` Bart Schaefer
2016-09-16  3:05               ` [PATCH] Etc/BUGS: Remove fixed items, add 'compset -q' item from workers/39306 Daniel Shahaf
2016-09-16  5:00                 ` Bart Schaefer
2016-09-14  3:22       ` compset -q oddities Daniel Shahaf
2016-09-14  5:20         ` Bart Schaefer [this message]
2016-09-14  6:12           ` Daniel Shahaf
2016-09-14 14:59             ` Bart Schaefer
2016-09-14 19:52               ` Oliver Kiddle
2016-09-15  3:08                 ` Bart Schaefer
2016-09-14  8:31           ` Peter Stephenson
2016-09-14 16:04             ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=160913222029.ZM13117@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).