From: Jun T <takimoto-j@kba.biglobe.ne.jp>
To: zsh-workers@zsh.org
Subject: Re: PATCH: list units in brackets at the end of completion group descriptions
Date: Tue, 2 Nov 2021 21:08:58 +0900 [thread overview]
Message-ID: <6DF97A0F-0544-4D6C-BBD6-0D83B0AF272E@kba.biglobe.ne.jp> (raw)
In-Reply-To: <89303-1635367918.379239@3fX8._yj_.piD6>
> 2021/10/28 5:51, Oliver Kiddle <opk@zsh.org> wrote:
>
> On further relection, for handling unit suffixes, we ideally also want
> to complete them.
Yes, for example _head/_tail completes the unit suffix in a dirty way.
> Units are nearly always only applicable on the end of numbers. So how
> about we add _numbers as a helper function to take care of completing
> unit suffixes.
(snip)
> The attached patch shows a possible approach.
Thank you for the patch. It works great. I can't think of any better idea.
I thought I could improve _head/_tail by using _numbers, but these
command (and maybe some others) accept a '+' sign before the number
(in addition to '-'). So either let _numbers accept '+' if the option -N
is given, or add another option, say -P, to make it accept '+'.
> I've used %m for units (measurement
> - u is taken for underline), %r for range (e.g 1-30), %o for default
> (otherwise - d is taken), %x for the list of suffixes (s is taken) and
> %h for the unadorned description (heading).
(snip)
> Corresponding to these are uppercase forms for use with the zformat
> conditional. This allows, e.g. %(M. %F{28}(%m%)%f.) for adding the units
> conditionally.
As you know, %(M is equivalent to %0(M. We need to use %2(M here since
> + (( $#units )) && formats+=( m:${units[2]} M:${#units} ) desc+=" ($units[2])"
${#units} is 2 if option -u is given (and 0 otherwise).
For %R %O %X and %H we need to use %1(R etc.
At least we need to set M to 1 as others.
Or is it better to set them to 0 so that %(M etc. works?
> _numbers also constructs the list of suffixes using zformat; looked up
> using unit-suffixes as the tag.
This works fine (some users may feel it too complicated, but I think it is
unavoidable).
Isn't it better to use some default format if the format style is not set for
the unit-suffixes tag? Maybe '%(d.%U.)%x%(d.%u.)%(r..|)' ?
I guess most of the users just set the format style for the descriptions tag to
'%B%d%b'. Currently %d gives 'header (unit) [default]'. I guess some (many?)
users also want to see the possible suffixes before they start typing the
number. But since () and [] are already used the only possibility would be {},
like '{k|M|G|T}' But some users may not understand that this is a list of
possible suffixes. Probably it is enough to show an example format, such as
'%B%d%(X.{%x}.)%b', in the document?
> This _numbers function takes quite a few options. Should we allow a way
> to configure how a range is presented - this hardcodes a dash separating
> min and max and has no way to indicate for decimal numbers whether the
> min and max values are inclusive?
I think we need not to indicate that min/max is inclusive.
For the '-' (dash) as a separator: if min/max is negative it would look like
'-5--2'. But I guess negative min/max are quite rare and maybe we don't
need to care about such cases. Or we could use '[-5,-2]' (a mathematical
notation for a closed interval), but it may be confused with the default value.
> diff --git a/Completion/Unix/Command/_zfs b/Completion/Unix/Command/_zfs
(snip)
> - '-b[Set volblocksize]:blocksize:' \
> - '-V[Set size]:size:' \
> + '-b+[set volblocksize]:block size:_numbers -M 'm:{a-zA-Z}={A-Za-z}' -u bytes {k,M,G,T,P,E,Z}{,B}' \
> + '-V+[set size]:size:_numbers -M 'm:{a-zA-Z}={A-Za-z}' -u bytes {k,M,G,T,P,E,Z}{,B}' \
There are typos here. The two lines should be
'-b+[set volblocksize]: :_numbers -M "m\:{a-zA-Z}={A-Za-z}" -u bytes blocksize {k,M,G,T,P,E,Z}{,B}' \
'-V+[set size]: :_numbers -M "m\:{a-zA-Z}={A-Za-z}" -u bytes size {k,M,G,T,P,E,Z}{,B}' \
next prev parent reply other threads:[~2021-11-02 12:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-27 11:52 Oliver Kiddle
2021-08-27 12:10 ` Daniel Shahaf
2021-10-27 20:51 ` Oliver Kiddle
2021-11-02 12:08 ` Jun T [this message]
2021-11-07 1:16 ` Oliver Kiddle
2021-11-08 10:56 ` Jun T
2021-11-10 23:08 ` PATCH: zformat (was list units in brackets at the end of completion group descriptions) Oliver Kiddle
2021-11-22 21:24 ` PATCH: list units in brackets at the end of completion group descriptions Oliver Kiddle
2021-12-01 3:27 ` Daniel Shahaf
2021-08-27 14:44 ` Mikael Magnusson
2021-08-27 16:14 ` Oliver Kiddle
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=6DF97A0F-0544-4D6C-BBD6-0D83B0AF272E@kba.biglobe.ne.jp \
--to=takimoto-j@kba.biglobe.ne.jp \
--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).