zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Cc: Vasiliy Ivanov <beelzebubbie.logs@gmail.com>
Subject: Re: _arguments not works as expected. Bug?
Date: Sun, 28 Sep 2014 11:47:21 -0700	[thread overview]
Message-ID: <140928114721.ZM27218@torch.brasslantern.com> (raw)
In-Reply-To: <5427DE81.3080308@gmail.com>

On Sep 28,  4:10pm, Vasiliy Ivanov wrote:
}
} Thanks for detailed clarification. I see all complications, but
} also I see that very powerful _arguments function looks slightly
} "incompleted" itself. Lot of people used only "basic" _arguments'
} functionality - maybe because of lack of consistency in "extended"
} functional. Maybe this inconsistency is not "important enough" because
} of hard to use?

Whether it's "important" would depend on whether many people complained
about it when *using* the completions, not when writing the completion
functions.  I don't recall this complaint coming up before, though that
doesn't mean it hasn't.

However, in the context "important enough to attract anyone" I'm making
somewhat euphemistic reference to the fact that zsh is entirely maintained
by volunteers, so the things that get fixed are serious problems and easy
cosmetic fixes, unless the issue actually interests someone who wants to
dive into a difficult but mostly cosmetic problem.  When the completion
system was designed many years ago, there was such a person, but it's not
so easy to find anyone now.

} For instance, I tried to implement simple scenario:
} command have a couple of "common" options: -a and -b; a few of
} mutually exclusive options: -k,-l,-m; and a -h option that could be
} used only alone. Exclusion sets are not nested, so I can't implement
} logic as "-h or (-a,-b (-k or -l or -m))". I can use prepending
} exclusion lists, but they aren't worked with -s so I have to deny
} multi-option words though exclusions sets do their work even in
} multi-option words. Very pity.

Even in the best cases, completion is only supposed to provide reminders,
help avoid typo errors, and fill in long strings such as file paths; it
isn't meant to be able to enforce correctness of the command.

I think something like

  _arguments '(-)-h' '(-h)'{-a,-b} - '(exclusive)' '(-h)'{-k,-l,-m}

expresses all of that except the part about multi-option words.  I would
have thought that

  _arguments : '(-h)'{-a,-b} - '(exclusive)' {-k,-l,-m} - help -h

would also have worked, but for some reason the (-h) exclusion doesn't
work when formulated that way; perhaps someone would be interested in
tracking *that* down.


      reply	other threads:[~2014-09-28 18:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-25 16:51 Vasiliy Ivanov
2014-09-26  7:02 ` Bart Schaefer
2014-09-28 10:10   ` Vasiliy Ivanov
2014-09-28 18:47     ` Bart Schaefer [this message]

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=140928114721.ZM27218@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=beelzebubbie.logs@gmail.com \
    --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).