zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>,
	zsh-workers@sunsite.dk
Subject: Re: long/short options
Date: Fri, 13 Jul 2001 17:01:08 +0000	[thread overview]
Message-ID: <1010713170109.ZM1620@candle.brasslantern.com> (raw)
In-Reply-To: <200107130807.KAA00965@beta.informatik.hu-berlin.de>

On Jul 13, 10:07am, Sven Wischnowsky wrote:
} Subject: Re: long/short options
}
} Andrej Borsenkow wrote:
} 
} > ...
} > 
} > What I'd really like is something like
} > 
} > -b, --binary        -- Unix line endings
} > ...
} > 
} > Or do I miss something and this is already possible?
} 
} It isn't.  And it's hard to write (but that didn't stop us in the past).
} One would have to change the way comparguments stores and reports the
} options and one would have to change the code in _describe to list
} things differently.

I would thing that the real reason it's difficult is because of menu-
selection.  If the options get lumped together like that, where should
the select-cursor go, and what should it insert on the command line?
You'd have to decide that e.g. its not possible to menu-select the one-
letter version of the option, or some such.

Anyway, that aside, obviously it would require a change to _describe,
but would it really need a change in the C code?  Taking this fragment
as an example:

    _arguments -s \
        '(-b -t --text)--binary[Unix line endings LF]' \
        '(--binary -t --text)-b[Unix line endings LF]'

One solution would be to have _describe actually scan the description
strings looking for duplicates, and condense them in the listing by
adding one option to the display string for the other and dropping the
duplicate from the list of completions (i.e., the duplicate would get
passed to `compadd -n ...').  That would have the effect I mentioned,
that you'd see `-b, --binary ...' but only be able to menu-select
`--binary'.

That still means the caller of _arguments has to supply all the duplicate
description strings for _describe to search for.  So another possibility
would be for the caller to use something like:

    _arguments -s \
        '(-b -t --text)--binary[Unix line endings LF]' \
        '(--binary -t --text)-b[(--binary)]'

Here _describe would parse off the leading parenthesized string from the
description.  If the option named in the parens is among the possible
completions, it prepends the option name and a comma to the description
string of the option named in the parens and uses `compadd -n' for the
option that has this special description.  Otherwise it adds the option
and the rest of the description (after the parens) as usual.  [This is
to handle a strange special case where you have two options that mean
the same thing individually but have different exclusion lists, e.g. one
of them has a new meaning when in combination with some third option.]

Both of these approaches mean that _describe has to make an extra pass
over the options before `compadd'ing them.  And I'm really not sure how
difficult they actually would be to implement.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   


  reply	other threads:[~2001-07-13 17:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-12 16:01 Andrej Borsenkow
2001-07-13  8:07 ` Sven Wischnowsky
2001-07-13 17:01   ` Bart Schaefer [this message]
2001-07-16  7:14     ` Sven Wischnowsky
2001-07-18 13:07       ` PATCH: " Sven Wischnowsky
2001-07-18 13:46         ` Andrej Borsenkow
2001-07-18 13:51           ` Sven Wischnowsky
2001-07-18 13:59             ` Andrej Borsenkow
2001-07-18 17:20         ` Oliver Kiddle
2001-07-19  8:36           ` 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=1010713170109.ZM1620@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.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).