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: Mon, 8 Nov 2021 19:56:49 +0900 [thread overview]
Message-ID: <2C471545-3339-4B78-BADD-B98336D3833D@kba.biglobe.ne.jp> (raw)
In-Reply-To: <72984-1636247814.729146@gNqB.dXT4.M5JK>
> 2021/11/07 10:16, Oliver Kiddle <opk@zsh.org> wrote:
>
> Do you see an issue with the behaviour of the following:
> local alts
> [[ -z $PREFIX ]] && alts=( 'sign:sign:((-\:"print all but the last specified bytes/lines" +\:"print the first specified bytes/lines (default)"))' )
> compset -P '+'
> alts+=( 'numbers: :_numbers number b\:512 K\:1024 KB\:1000 M\:1024\^2 MB\:1000\^2 G\:1024\^3 GB\:1000\^3 T\:1024\^4 TB\:1000\^4' )
> _alternative $alts
It works if we use either "compset -P '[-+]'" or "_numbers -N".
>> Or is it better to set them to 0 so that %(M etc. works?
>
> The absence of any M: spec is treated as 0, unfortunately.
Oops, sorry. I thought I've tested that %(M is false if M: is not
given, but it seems I did the test in a wrong way.
> Perhaps we should add an option to
> zformat so that we can simply use $(m. %(m).) with no need for the
> uppercase spec.
(snip)
> An option to zformat would not be backward
> compatible for the format style (not that we ever used the feature but
> someone might).
(snip)
> Or should we just stick
> with M:1 and needing the else branch or a 1.
I think %1(M is enough for the current purpose.
(or set %M to 0 if unit is given, and nonzero otherwise; i.e., never leave
it undefined).
But, in zshcompsys(1), neither the section for the 'format' style nor the
section for '_description' says that the ternary expression of zformat can
be used (or is it mentioned somewhere?). So if adding a new option to
zformat would have wider use, then I think adding the option and using it in
_description would not break the compatibility.
The format for the unit-suffixes tag accepts %d that is set to 0 if
the suffix is marked as the default (such as :k:kilo) and 1 otherwise.
This may cause some confusion, but I feel it is OK.
---
Jun
next prev parent reply other threads:[~2021-11-08 10:57 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
2021-11-07 1:16 ` Oliver Kiddle
2021-11-08 10:56 ` Jun T [this message]
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=2C471545-3339-4B78-BADD-B98336D3833D@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).