[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    RE: A more flexible solution for internet keywords
From:       Andreas Hochsteger <e9625392 () student ! tuwien ! ac ! at>
Date:       2001-06-12 6:19:09
[Download RAW message or body]

Hi!

On Mon, 11 Jun 2001, Yves Arrouye wrote:

> > For now I'll implement the compatibility mode I suggested in 
> > my last mail
> > (query definitions with only one single \1 get replaced with \0 before
> > substitution) and submit another patch. It should work 
> > without problems
> > with both, old and new queries, since the case where only the 
> > first query
> > argument should be used, is not vere useful.
> 
> Please test it by doing something like this: select Google as your fallback
> search engine, and then put this in Konqueror's address bar: "un été très
> chaud". After you get to Goggle, the query should not be changed. If it
> contains weird symbols, then \2 (charset) broke. There's a chance it won't
> since you may be modifying the logic only for web shortcuts. Still, it makes
> the two things work differently which is bad.

Yes, the query you suggested works quite well.
There is not much difference to the old format. I only changed \2 to
\ikw_charset, which is stored in the IKWMap like it would be given on the
address bar.
Theoretically it should be possible to override the hardcoded references
by giving it at the command line (ikw_charset=utf-8).

My goal is to provide a general way to substitute the defined queries,
which is a better design IMHO.
\ikw_fallbackuri (in method ikwsQuery) is still an exception to that rule,
which I'd like to put into the IKWMap too, but I have to figure that out
first.

> 
> About the "$" sign. Since RFC 2396 marks it as reserved, you're right, it
> could be a dangerous choice. But you could still keep the "\" as a lead, and
> have a second char that is used for the new meaning, as in \{1} for example
> (keeping all the chars from the unwise set of RFC 2396). 

I think as long as there's a way to avoid introducing yet another escape
character or syntax for the query references, I'd like to keep it as
simple as possible.

I submitted the last patch before I got your mail.
Perhaps you might test it with the current implementation.
I'm using it now for my normal work and it's quite stable and working very
well.

> 
> YA
> 

Bye,
	Andreas

[prev in list] [next in list] [prev in thread] [next in thread]