zsh-workers
 help / color / mirror / code / Atom feed
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}' \




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