zsh-workers
 help / color / Atom feed
* [BUG] Issue with _arguments !-x !+x
@ 2020-02-12 22:57 dana
  2020-03-01 21:36 ` Oliver Kiddle
  0 siblings, 1 reply; 3+ messages in thread
From: dana @ 2020-02-12 22:57 UTC (permalink / raw)
  To: Zsh hackers list

I noticed something unexpected when i have both !-x and !+x type option specs
and then i try to complete stacked options containing the -x ones:

  # Only !-x
  % _foo() { _arguments -s -S : -{a,b,c} \!-{d,e,f} }
  % compdef _foo foo
  % foo -ad<TAB>
  completing option:
  -b  -c
  % foo -da<TAB>
  completing option:
  -b  -c
  % foo -def<TAB>
  completing option:
  -a  -b  -c

  # Both !-x and !+x
  % _foo() { _arguments -s -S : -{a,b,c} \!-{d,e,f} \!+{d,e,f} }
  % compdef _foo foo
  % foo -ad<TAB>
  completing no arguments:
  % foo -da<TAB>
  completing option:
  -b  -c
  % foo -def<TAB>
  completing no arguments:

All i can figure out so far is that comparguments doesn't think there's
anything to complete. But i'm not sure why. Something to do with how ca_doff
is calculated, i think?

dana


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [BUG] Issue with _arguments !-x !+x
  2020-02-12 22:57 [BUG] Issue with _arguments !-x !+x dana
@ 2020-03-01 21:36 ` Oliver Kiddle
  2020-03-02  6:04   ` dana
  0 siblings, 1 reply; 3+ messages in thread
From: Oliver Kiddle @ 2020-03-01 21:36 UTC (permalink / raw)
  To: dana; +Cc: Zsh hackers list

On 12 Feb, dana wrote:
> I noticed something unexpected when i have both !-x and !+x type option specs
> and then i try to complete stacked options containing the -x ones:

> All i can figure out so far is that comparguments doesn't think there's
> anything to complete. But i'm not sure why. Something to do with how ca_doff
> is calculated, i think?

The problem is the single array in struct cadef. In effect this gets
overloaded for both + and - options. For both -d and +d, we look up the
entry with 'd' in unsigned form as the index. A quick hack to add 128 to
the index for + options appears to fix the issues you list.

But I wonder whether we should go for a somewhat different approach.
Instead of: d->single[STOUC(*line) + (pre == '-' ? 0 : 128)]
Have a macro for: d->single[SINGLEIDX(*line, pre)]
Allowing 256 entries was simple and efficient before multibyte character
sets was an issue. I don't think there is any point supporting
clumping of options that use non-ASCII characters. So the single array
doesn't need to be a hash or list. It could even be smaller if we skip
populating it for control characters in addition to those with the high
bit set.

Any thoughts?

Oliver

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [BUG] Issue with _arguments !-x !+x
  2020-03-01 21:36 ` Oliver Kiddle
@ 2020-03-02  6:04   ` dana
  0 siblings, 0 replies; 3+ messages in thread
From: dana @ 2020-03-02  6:04 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Zsh hackers list

On 1 Mar 2020, at 15:36, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> Any thoughts?

Thanks for looking, i never got back to it.

Off the top of my head, i like your idea. I agree that there's probably no
need to support non-ASCII characters (nor control characters, if it's
worth-while to skip those)

dana


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-12 22:57 [BUG] Issue with _arguments !-x !+x dana
2020-03-01 21:36 ` Oliver Kiddle
2020-03-02  6:04   ` dana

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git