DonationCoder.com Software > FARR Plugins and Aliases

FARR plugin: Akete

<< < (5/14) > >>

ewemoa:
Thanks for taking the time and making the effort to read the draft -- I really appreciate it!

As to the keywords that begin with "openwith", I chose this based on phitsc's example and am not particularly attached to it -- except that if it's changed, I guess trying to maintain backward compatibility might be something to consider.

Oh no, don't say we should be able to configure what the keyword starts with via FARR User Variables! ;)

phitsc:
I agree with mouser, looks very good!

As to the keywords that begin with "openwith", I chose this based on phitsc's example and am not particularly attached to it -- except that if it's changed, I guess trying to maintain backward compatibility might be something to consider.
-ewemoa (January 14, 2009, 06:38 AM)
--- End quote ---
And neither am I. Wouldn't give me a lot of work if you changed it. I'm no big fan of abbreviations though, so I still think openwithnpp would be clearer than something like e.g. ownpp.

What about just using the same definition as used for extensions, e.g. if one specified something like:

txt=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe

then it would open .txt files with Wordpad, but one could also do this:

C:\boot.ini +txt

and it would also open with Wordpad.

I could then choose whatever definition I liked (even openwithnpp ;) ) and since there are no files with an extension of .openwithnpp it would just work with this C:\boot.ini +openwithnpp. You would have to check if it might give problems with other keywords though.

ewemoa:
Thank you phitsc, for also taking the time and making the effort to read the draft and comment on it :)

The idea you suggested sounds interesting.  As you pointed out, there does seem to be a potential issue with keyword collision and I am mulling over what might be done about that.  Perhaps allowing a configurable prefix (which defaults to something) for the keyword and reusing the definitions from file extensions as you suggested might work out.

My impression at the moment is that having a particular prefix helps in picking out an appropriate keyword from the query.  Supposing that there is no particular prefix string for the keywords this plugin should handle, if a query contains multiple keywords, I am not sure how to decide which keyword (possibly multiple?) should be selected by the plugin.

Regarding a default keyword prefix, "open" or "with" seem like possibilities to me.

What do folks think?

mouser:
both prefixes seem good to me, or even use "ow" as a prefix (for open with)
so
+owtxt
would open with whatever is configured as txt editor.

ewemoa:
I think I'll go with a default of "with" as the prefix, provide a way to change the prefix, and leverage any existing file extension association configuration so that it may be used with a keyword (e.g. if you have an association defined for 'html', then the plugin should recognize the keyword 'withhtml').

I discovered that one can use period-separated names for both section names (e.g. "Akete.Options") and variable names (e.g. "Options.KeywordPrefix") in FARR User Variables.  Also, that:

  [Akete.Options]
  KeywordPrefix=test

ends up being the same (?) as (at least as far as requesting the value from FARR is concerned):

  [Akete]
  Options.KeywordPrefix=test

I'm currently leaning toward suggesting the use of the variable names in the official documentation.

Navigation

[0] Message Index

[#] Next page

[*] Previous page