On Tue, Jul 23, 2013 at 12:39:30PM -0400, Jorge Arellano Cid wrote:
On Sun, Jul 21, 2013 at 07:19:16PM +0200, Johannes Hofmann wrote:
yOn Fri, Jul 19, 2013 at 11:22:36AM -0400, Jorge Arellano Cid wrote:
On Thu, Jul 18, 2013 at 11:06:36PM +0200, Johannes Hofmann wrote:
On Wed, Jul 10, 2013 at 09:21:51AM +0200, Johannes Hofmann wrote:
On Tue, Jul 09, 2013 at 05:02:12PM -0400, Jorge Arellano Cid wrote:
Hi Johannes,
On Tue, Jul 09, 2013 at 09:51:39PM +0200, Johannes Hofmann wrote: > On Thu, Jun 20, 2013 at 08:20:27PM +0200, Johannes Hofmann wrote: > > On Wed, Jun 19, 2013 at 04:41:23PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Mon, Jun 17, 2013 at 03:16:09PM +0300, Aki Helin wrote: > > > > > Hi, > > > > > > > > > > Currently when using a window manager where focus follows mouse, making a > > > > > search usually requires you to reach for the mouse. One way to avoid this > > > > > would be to allow using search engine(s) directly from the address bar. > > > > > > > > > > Searches would have to be differentiated somehow from URLs. Dillo already > > > > > has a customizable list of engines in preferences, so one natural solution > > > > > would be to interpret url strings which start with the name of a search > > > > > engine as searches to be performed using it, so that e.g. 'wikipedia > > > > > slartibartfast', 'google foo' and 'weather oulu' do what you would expect. > > > > > > > > > > Below is a quick patch I've used to do this for a while, should anyone > > > > > else find this feature useful. > > > > > > > > This has been discussed before, but somehow wasn't completed. I like > > > > your idea to reuse the search engine name to derive the shortcut. > > > > However, I would allow arbitrary prefixes of the search engine name > > > > as in the slightly modified patch below. > > > > What do you think? > > > > > > This is good, although there's a leading space in the search text that > > > some of my search sites don't like. > > > > The leading space should of course not be part of the search term. > > If nobody objects I will commit this tomorrow.
The current format for search_url in a_Misc_parse_search_url() is:
"[<label> ]<url>"
IMHO, it'd be much better to have it this way in the patch:
"[<label[:abbr]> ]<url>"
where "abbr" means abbreviation. e.g.
search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s"
that way I could search "slick" from the location box like this:
fd slick
and keep the descriptive names for the GUI interface.
The idea of the proposed patch is to allow arbitrary prefixes of the descriptive names as shortcuts, so
goo dillo duck dillo
but also
g dillo d dillo
would work without further configuration work. In case there is more than one match, the first wins.
Does this make sense or should do you prefer explicit configurable shortcuts?
It makes sense, but I prefer the configurable shortcuts.
For instance, I have:
search_url="Free Dictionary http://www.thefreedictionary.com/%s" search_url="Free Dictionary (es) http://es.thefreedictionary.com/%s"
and would like to be able to set it this way:
search_url="Free Dictionary:fd http://www.thefreedictionary.com/%s" search_url="Free Dictionary (es):fde http://es.thefreedictionary.com/%s"
Ok, it makes sense to be able to optionally specify a shortcut, but I'm a bit worried that the syntax of the search_url field get's more and more complicated. We already have the ' ' as separator between title and url, now we add a ':'. I see two options:
* We stick with title and url only and for your example one would use: search_url="fd Free Dictionary http://www.thefreedictionary.com/%s" search_url="fde Free Dictionary (es) http://es.thefreedictionary.com/%s" and live with the "fd" and "fde" shortcurts beeing displayed as part of the title.
I like this idea. It's simple and allows us to feel-test the solution.
* Or we enhance the prefs parser and somehow have separate fields for url, title, and shortcut, i.e. something like that: search_url="http://www.thefreedictionary.com/%s" search_title="Free Dictionary" search_shortcut="fd" where these three fields would have to be grouped together in some way.
This is more complicated and may not be worth the effort.
Committed! Cheers, Johannes