Bug 321558

Comment 1 Dani Megert 2010-08-03 04:45:16 EDT

M1 if easy to fix. M2 otherwise.

Comment 2 Markus Keller 2010-08-03 05:58:41 EDT

I would rather expect "param ~warn" or "~warn param" to do this.

Comment 3 Dani Megert 2010-08-03 06:03:59 EDT

>I would rather expect "param ~warn" or "~warn param" to do this.
If so, you also need to allow "param " to match "param". Currently this results in 0 matches (if there is no "param " in the UI). That we then add matches back after typing ~warn would be strange.

Comment 4 Deepak Azad 2010-08-03 06:58:21 EDT

(In reply to comment #3)
> >I would rather expect "param ~warn" or "~warn param" to do this.
> If so, you also need to allow "param " to match "param". Currently this results
> in 0 matches (if there is no "param " in the UI). That we then add matches back
> after typing ~warn would be strange.
The discussion is whether there is space in between or not, right? I don't see how that matters (though aesthetically speaking, I prefer having space). The result would be an && of both conditions, for this example the result would be all options with labels matching 'param' AND with value matching 'warn'. I don't see how the matches are added back.

(In reply to comment #2)
> I would rather expect "param ~warn" or "~warn param" to do this.
Markus, are you sure you want to have the second option as well. Someone will then try 'method ~warn param'. Does the result return options with labels matching 'method' OR 'param' AND value matching 'warn?

Or what happens if we have a value with a space in it? (though right now we do not have this case)

To keep it simple I would support only 'name ~value'.

Comment 5 Dani Megert 2010-08-03 07:06:53 EDT

>The discussion is whether there is space in between or not, right? I don't see
>how that matters
Well, currently spaces do matter, e.g. enter "block" then add a space
==> boom no matches. It would be strange to me if matches come back magically if I enter "~warn" afterwards. So, if we go for 'name ~value', then we must first agree that any spaces after the name are ignored i.e. "block " or "block  " would give the same result as just entering "block". If we do so, I think we can keep it simple and only allow
name<trailing whitespace is ignored>
~value<trailing whitespace is ignored>
name<at least one whitespace>~value

Comment 6 Deepak Azad 2010-08-03 08:46:55 EDT

(In reply to comment #5)
> >The discussion is whether there is space in between or not, right? I don't see
> >how that matters
> Well, currently spaces do matter, e.g. enter "block" then add a space
> ==> boom no matches. It would be strange to me if matches come back magically
> if I enter "~warn" afterwards. So, if we go for 'name ~value', then we must
> first agree that any spaces after the name are ignored i.e. "block " or "block 
> " would give the same result as just entering "block". If we do so, I think we
> can keep it simple and only allow
> name<trailing whitespace is ignored>
> ~value<trailing whitespace is ignored>
> name<at least one whitespace>~value
yeah,I see the problem now...
Will ignore trailing whitespace and support these 3 cases, and will try to get this done for M1.

Comment 7 Markus Keller 2010-08-03 09:22:42 EDT

Since we don't describe this syntax on the page, I think it should work both ways (<valueFilter><pattern> and <pattern><valueFilter>, stripping whitespace):
- trim pattern
- if <valueFilter> at beginning or end, remove it from pattern and trim remaining pattern again

Comment 8 Dani Megert 2010-08-03 09:30:08 EDT

Is also fine for me.

Comment 9 Deepak Azad 2010-08-04 03:17:46 EDT

Created attachment 175815 [details]
fix

Fixed in HEAD.

Comment 10 Deepak Azad 2010-08-04 06:48:27 EDT

.

Comment 11 Dani Megert 2010-08-05 03:02:24 EDT

Verified in I20100804-1800. Works well. Filed bug 321818 for a scenario that I missed.