zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@ibmth.df.unipi.it>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: completion in quotes
Date: Mon, 07 Jun 1999 13:54:51 +0200	[thread overview]
Message-ID: <9906071154.AA28129@ibmth.df.unipi.it> (raw)
In-Reply-To: "Sven Wischnowsky"'s message of "Mon, 07 Jun 1999 12:54:36 DFT." <199906071054.MAA06674@beta.informatik.hu-berlin.de>

Sven Wischnowsky wrote:
> This makes completion always work on whole quoted strings. It has the
> special casing for string that start with a quote as discussed last
> week. The code is very careful to change the word as few as possible,
> I hope it is even better than what Bart suggested in 6471.

Wow.  It looks like the compsys.yo chunk was just a repeat of the
documentation for $compcontext, and there was some debugging code in
_brace_parameter so it needed applying by hand, but I think it was all
unambiguous.

> 1) The code tries to automatically insert closing quotes. This is also 
>    done during menucompletion -- is this ok?

Maybe in principle this should be compstate-able, but I won't worry too
much.

> 2) `compset -q' currently does nothing if the current word isn't
>    quoted. This could be changed to always split the current word at
>    spaces even if not inside quotes. Should we?

I'd say, not until there's a clear use for this, then (presumably) you can
share code in cases which do or don't have quotes.  The spaces to split on
in this case would have to have been put there explcitly by the completion
code, wouldn't they?  Otherwise they'd have to be quoted already to get
that far.  Or are you distinguishing between "zsh -c 'echo foo'" and "zsh
-c echo\ foo"?  Ideally those two should be split in the same way.

> 3) The code tries hard to correctly close quotes inside parameter
>    expansions. While writing this is saw again that ${'$a'} is the
>    same as $$. Shouldn't we disallow single quotes there?
>    At least the completion code can only handle double quotes.

Ideally, yes, if they don't work.  Most shells test give a `bad
substitution' message which suggests they test it in the equivalent of
parmsubst().  It could be hard to work out where it's necessary then.

> 4) I changed `_brace_parameters' to automatically insert closing
>    quotes inside parameter expansions (`${"foo<TAB>'). This fails with 
>    completeinword if there already was a closing quote on the line.
>    I may have to rethink something here. Maybe this should always be
>    done automatically without the completion widget having to bother
>    about it. Probably in a way that closes the expansion automatically 
>    only if there is no user-supplied -S suffix.

It could get quite icky if you're trying to close nested things all the
time.  Anything simple and consistent would be OK.

> 5) The `_closequotes' completer should be superfluous now.

I was about to ask.  I'll delete it in the next version (and the
documentation).  I won't bother sending a patch.

> Ok. Now I beg everyone who ever complained about the handling of
> quotes in completion to test all this and send us comments,
> suggestions, and so on. Please. Yes?

I'll try and get pws-21 out by tomorrow, after I've dealt with Andrej's
comments on installing functions.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy


  reply	other threads:[~1999-06-07 12:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-06-07 10:54 Sven Wischnowsky
1999-06-07 11:54 ` Peter Stephenson [this message]
1999-06-07 11:55 Sven Wischnowsky
1999-06-07 12:42 Sven Wischnowsky

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=9906071154.AA28129@ibmth.df.unipi.it \
    --to=pws@ibmth.df.unipi.it \
    --cc=zsh-workers@sunsite.auc.dk \
    /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).