zsh-workers
 help / color / Atom feed
* [PATCH] _multi_parts doesn't always pass -f to compadd
@ 2019-12-22  4:46 dana
  2019-12-22  5:31 ` Bart Schaefer
  0 siblings, 1 reply; 3+ messages in thread
From: dana @ 2019-12-22  4:46 UTC (permalink / raw)
  To: Zsh Workers List

I noticed this the other day and forgot about it until now. In some cases
(seemingly the most common ones?), _multi_parts doesn't pass -f to compadd,
which prevents colours/symbols from being applied to files. Just adding -f to
the list of options that are passed unconditionally seems to fix it? Possibly
some of the other options could be added too, but i didn't check

dana


diff --git a/Completion/Base/Utility/_multi_parts b/Completion/Base/Utility/_multi_parts
index 00e3e26cc..8a77ff0f0 100644
--- a/Completion/Base/Utility/_multi_parts
+++ b/Completion/Base/Utility/_multi_parts
@@ -15,7 +15,7 @@ typeset -U tmp1 matches
 
 zparseopts -D -a sopts \
     'J+:=group' 'V+:=group' 'x+:=expl' 'X+:=expl' 'P:=opts' 'F:=opts' \
-    S: r: R: q 1 2 o+: n f 'M+:=matcher' 'i=imm'
+    S: r: R: q 1 2 o+: n 'f=opts' 'M+:=matcher' 'i=imm'
 
 sopts=( "$sopts[@]" "$opts[@]" )
 if (( $#matcher )); then


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

* Re: [PATCH] _multi_parts doesn't always pass -f to compadd
  2019-12-22  4:46 [PATCH] _multi_parts doesn't always pass -f to compadd dana
@ 2019-12-22  5:31 ` Bart Schaefer
  2019-12-22  5:36   ` dana
  0 siblings, 1 reply; 3+ messages in thread
From: Bart Schaefer @ 2019-12-22  5:31 UTC (permalink / raw)
  To: dana; +Cc: Zsh Workers List

On Sat, Dec 21, 2019 at 8:47 PM dana <dana@dana.is> wrote:
>
> I noticed this the other day and forgot about it until now. In some cases
> (seemingly the most common ones?), _multi_parts doesn't pass -f to compadd,
> which prevents colours/symbols from being applied to files. Just adding -f to
> the list of options that are passed unconditionally seems to fix it?

_multi_parts is intended to be usable in cases that are not files,
such as (IIRC) tar listings, perl module names, etc.

I don't know if passing -f to compadd when adding something that is
not a file has any bad effects.

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

* Re: [PATCH] _multi_parts doesn't always pass -f to compadd
  2019-12-22  5:31 ` Bart Schaefer
@ 2019-12-22  5:36   ` dana
  0 siblings, 0 replies; 3+ messages in thread
From: dana @ 2019-12-22  5:36 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh Workers List

On 21 Dec 2019, at 23:31, Bart Schaefer <schaefer@brasslantern.com> wrote:
> _multi_parts is intended to be usable in cases that are not files,
> such as (IIRC) tar listings, perl module names, etc.

Yeah. The caller still has to explicitly pass -f to _multi_parts (which is not
common — _git is like the only thing in the repo that does), so it shouldn't
affect anything that doesn't AFAIK

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 --
2019-12-22  4:46 [PATCH] _multi_parts doesn't always pass -f to compadd dana
2019-12-22  5:31 ` Bart Schaefer
2019-12-22  5:36   ` 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