Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: completion grouping
- X-seq: zsh-workers 8557
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: completion grouping
- Date: Fri, 5 Nov 1999 07:20:29 +0000
- In-reply-to: <199911040932.KAA11903@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <199911040932.KAA11903@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Nov 4, 10:32am, Sven Wischnowsky wrote:
} Subject: Re: completion grouping
}
} Bart Schaefer wrote:
}
} > I'm also never sure what to expect from "sorted by priority." In this
} > case a smaller number is a higher priority, right? But a negative
} > number is treated as bigger than any positive one? That's a bit weird.
} > Or am I misunderstanding?
}
} No. Only tags with a positive (or zero) priority are used and then
} smaller numbers mean higher priorities (hm, maybe we should change
} that if people think that that would feel more natural).
Not necessarily "more natural."
} > } comptag option+='*dvi*=1'
} > }
} > } the `+=' means that the definition is prepended to the already
} > } existing definition
} >
} > Hrm. I would have expected += to *append* rather than *prepend* (my
} > C++ is showing).
}
} Looking at my mail again I noticed that I forgot to mention that `+='
} prepends and `=+' appends. With that said this hopefully looks more
} sensible ;-)
Hmm.
} But I'd like think about changing this function anyway. I.e. I hope to
} find a somewhat easier interface. Currently this is still too near to
} the way things are stored in `$comptags' and I think the user shouldn't
} have to worry/know about the internal representation.
I don't see how you can avoid having the user know *something* about at
least the ordering of the alternatives for a given tag, so although I'm
not entirely happy with the syntax I don't mind the semantics.
} we probably should think about some standard structure for defining
} styles. Things like multiple styles (separated by commas?), styles
} with values (`[style_a=foo,style_b=bar]' or something like that). If
} this turns out to be useful, I would like change `_tags' to report
} styles in a format that is easier to parse in the calling functions.
I repeat my suggestion that this be enveloped in a mini-language, as with
the _arg_compile function.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author