Danek Duvall wrote:
Philip Brown wrote:
if "pkg search" is "Intelligent" enough to auto-expand
basename:vim => ::basename:vim
it should be just as equally capable of auto-expanding
file:vim => :file::vim
Why? How do you know it's not file:::vim? What about "basename:file"?
That could reasonably be "basename:file::" or "::basename:file". And given
the way searching through set actions works, where the "key" is the value
of the "name" attribute (so I can do a search for, say
set:info.upstream-url:*gnu.org*), you can even have the key namespace
overlap the action namespace.
The same argument could be given against allowing
basename:vim -> ::basename:vim, couldnt it?
"How do you know it isnt :basename::vim"? etc, etc.
To not do so, may justify some pretty Backus-Naur grammar definition, but
it is horrible real world user interface!
I'm not saying I disagree entirely with you about needing something better
than the colon-separated search argument, but given that's what we've got,
there's not much more automagic we can do with the parsing.
Right now, searching for
"file:vim" (or "file:anything", AFAIK) turns up nothing.
Given that, seems like it shouldnt be too hard to add in a branch to the
automagic, when there is a SINGLE modifier,
(MOD:string) vs MOD with more than one ':')
along the lines of,
"if there's no match, try MOD as a different field".
(or perhaps even deeper intelligence, if possible, if the program somehow
knows "there is no 'file' token in field 3 for any record. Oh hey, but there
is one in field 2, lets try that")
Brock Pytlik wrote:
> [snip]
>
>> But anyways, you might at least make the simple improvement above that
>> I mentioned. Even if you have to explicit-special-case it in the code.
>> Then from a users point of view, it then becomes a much more sensibly
>> behaving tool.
>>
> Which improvement do you mean? The one about the initial slash? I will
> certainly file an RFE for your suggestion.
Thank you Brock. That would be great.
In this case, I was referring to the "file:" one though :)
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
