> The trouble is, the modifier-aware command appears second. the
> default options is, hence, useless.

Agreed :\

> Is there any way to force a
> suggestion to come up on top (if not exclusively?)

Unfortunately, no.

> i honestly don't know why i get those options

Neither do I! Seems like a bug to me, but Jono/Mitcho will know more.

- Blair



On 16/05/09 2:06 AM, Edgar Gonçalves wrote:
>
> I have a simillar issue. With the "buxfer-spend 5.5 in movie", I get
> the two options, one recognizing the "in" modifier and its argument,
> and another using the selected text instead of whatever i write after
> "in". The trouble is, the modifier-aware command appears second. the
> default options is, hence, useless. Is there any way to force a
> suggestion to come up on top (if not exclusively?)
>
> I also get lots of suggestions if i start adding words to the argument
> of the "in" modifier. e.g., "buxfer-spend 238 in last trip to paris" i
> get
> - buxfer-spend 238 in<selected-text>
> - buxfer-spend 238 in last trip to paris
> - buxfer-spend 238 in last trip to
> - buxfer-spend 238 in last trip
>
>
> i honestly don't know why i get those options. neither how to enable
> just one. (note that i require the multiple word text to appear within
> a modifier, not as the direct complement).
>
> thanks for the help!
>
>
> On May 14, 11:58 pm, Blair McBride<[email protected]>  wrote:
>> It could be due to fixes in the parser between 0.1.7 and 0.1.8. For
>> instance, based on the input of "searchfor foo on bar" there should be
>> these suggestions:
>>
>> SEARCHFOR foo ON bar
>> SEARCGFOR foo on bar
>>
>> Where capitalized words are the verb name, or a modifier name.
>>
>> Could you post a screenshot?
>>
>> - Blair
>>
>> On 15/05/09 1:40 AM, Net Wolf wrote:
>>
>>
>>
>>> I wrote a command which uses an optional modifier. eg.
>>>     searchfor foo on bar
>>
>>> On Ubiquity  1.7.x this would show one command in the left column
>>> (Evolved skin), and the preview output in the right column.
>>> However, since 1.8.x, two commands appear in the left column as soon
>>> as the first character of the modifer's text is entered. eg,
>>> "searchfor foo on b" shows searchfor listed twice, and it defaults to
>>> the version that does not take advantage of the modifier. This means
>>> it never finds any items, because "foo on b" returns no records until
>>> you press down to go to the second instance of the command.
>>
>>> Can this be fixed in my code, or is it a bug in Ubiquity? I note that
>>> the translate command does a similar thing, but at least defaults to
>>> the useful version (which takes advantage of the modifiers) first.
>>
>>> Thanks in advance,
>>> Net Wolf.
>>
>>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"ubiquity-firefox" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/ubiquity-firefox?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to