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: 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

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