Bug 51259

Was going to request it myself.  This feature used to be called "Type Ahead Find", it 
is now called "Find As You Type". You can read all about it here, 
http://www.mozilla.org/projects/ui/accessibility/typeaheadfind.html 
 
It's a shame that you cannot change the short description of the bugs (can you?), I 
don't think the one used is very clear, and it does not includes the new name of the 
feature. Also seems to me like Khtml is not the proper component in this case. 
 
J.A. 

I second this request.  This is a must have for Konqueror ... for 3.2 even :P

Oh, I would love to see this in konqueror.  
And if the search would wrap around the end of the page, then it would be even 
better than mozilla. :-) 

(See bug 53166)  Explorer has implemented part of this for a while -- at least the 
part where you explicitly search for text via control-f/f3, if it overlaps a link, the tab 
dotted-line (focus?) moves to the same (or about the same) location.  The entirety of 
this sounds pretty nice too. 
 
To be honest, it would be nice to have this kind of functionality in all KDE apps -- 
heck, any GUI app.  Perhaps it belongs in the toolkit, rather than in an individual 
app. 

Emacs interactive search - but not as good... 
 
(Start emacs. ESC-< to move to beginning of document. 
CTRL-S enter text to search for. Repeat CTRL-S to search next.) 

I suggest changing the product to kdelibs since this is a feature potentially
useful for a wide range of different applications and is already used in several
aingle products (KMenu, Konqueror file manager view), unifying it in kdelibs and
then using it in khtml and editors.

This is known as I-Search in Kate and exists in keditbookmarks too. Should not 
be too hard to add to konqueror.

How is this more useful than simply ctrl f and than click when the right selected text comes 
up? 
 
What I would really like to see is that after Ctrl f find an url I should be able to press enter to 
load it. 

Oh, the difference is there... with "type-ahead" I can immediately see where my current search 
moves me to. With CTRL-f I do not know how much of that word I search for I have to write.  
 
With CTRL-f I cannot search links only.  
 
Also, pressing CTRL-f each time would be annoying. :-) 
 
And to your question containing the word "click"... well the word "click" answers that. :-)) 

Once I got used to this in mozilla/phoenix, I really hate not having this in 
Konqueror too. Now, (un)fortunately, my fingers automatically go to the / or ' 
keys when searching ... and then realise I need Ctrl-F. 
 
While it is ok using Ctrl-F, it is an interruption out of the normal typing 
flow (esp. if your hand is on the arrow keys, / and ' are a lot more 
accessible than ctrl-f) 
 
and this would be similar to the lynx/links/vi form of /<search string><enter> 
which, too, is inbuilt for developers (if not using emacs :-)  
 
hrishikesh 

I like the way emacs handles incremental search:  
 
- You press a key-combination (Ctrl-S in emacs' case) to activate it 
- There's no popup that might obscure the searched text 
  but you type the search term letter by letter in a one-line bar at the    
  bottom.  
- It moves the cursor to the next match and highlights it, 
  but it also marks all the other matches that are currently visible.  
- If you hit the key combination again it jumps to the next match.  
- If you cancel the search (with Ctrl-G in emacs' case) it returns  
  the cursor to the point where the search was started, but when  
  you cancel it by moving the cursor with the arrow keys it stays  
  at the last highlighted match. 
- It gives visual feedback by flashing the screen if the search  
  reaches the bottom of the file, and hitting the key combo once  
  more wraps the search.  
- It gives visual feedback by flashing the screen if you type a  
  character that causes the search to fail (no more matches) 
- Using Backspace you can correct/change your search term, and the cursor  
  moves back to the previous match. 
- It auto-detects whether the search should be case-sensitive or not:  
  If the search term is all-lowercase then the search will be 
case-insensitive,  
  but if there's at least one uppercase char it'll be case-sensitive 
  AFAIK there's no way to search case-sensitively for an all-lowercase  
  search term, but it still works very well for me.  
- Using a different key combination (Ctrl-R in emacs) you can  
  activate the same type of search, but backwards. 
- It's is not restricted to links, of course, but works with any text.  
 
IMHO this provides for a very efficient search without moving  
your hands off the keyboard. 
What do you think about adapting these ideas from emacs for konqi? 
 
 

Subject: Re:  konqueror browser feature "type ahead" aka "find as you type"

> I like the way emacs handles incremental search:
> - You press a key-combination (Ctrl-S in emacs' case) to activate it

In Mozilla 
- just typing the word ->incremental search on links
- '/' -> activates search on text

I'd go for the Mozilla way because
- It's faster, popups, no key combinations, it's easy and fast
- Consistency with Mozilla (it's always an advantage).

I'd just go for a key-combination if we were to implement this not as a 
browser specific but a global kde feature.


> - There's no popup that might obscure the searched text
Yeap, just like mozilla. Very important. 

>   but you type the search term letter by letter in a one-line bar at the
>   bottom.
This could be an interesting adition. Maybe show what your typing in the botom 
of the window. (Where some messages are shown, like "page loaded" you know?).


> - It moves the cursor to the next match and highlights it,
>   but it also marks all the other matches that are currently visible.
I don't know about this one... I understand the point but sometimes I find it 
confusing, I prefer focusing on the current match only. But I do understand 
it might be useful. I'd say either try to make it a very non intrusive mark, 
or put it as an option :D

> - If you hit the key combination again it jumps to the next match.
(related to the first one...)

> - If you cancel the search (with Ctrl-G in emacs' case) it returns
(Escape, like in Mozilla, is much more intuitive.)

>   the cursor to the point where the search was started, but when
>   you cancel it by moving the cursor with the arrow keys it stays
>   at the last highlighted match.
This *might* be nice, if we can still press the escape key even after moving 
the cursor to reset the search start position.

> - It gives visual feedback by flashing the screen if the search
>   reaches the bottom of the file, and hitting the key combo once
>   more wraps the search.
> - It gives visual feedback by flashing the screen if you type a
>   character that causes the search to fail (no more matches)

Flashing the screen sucks! :)
I'd go for a message in the bottom of the window or something like that, maybe 
bold or highlighted to make it more visible. Eventualy a beep like in Moz.


> - Using Backspace you can correct/change your search term, and the cursor
>   moves back to the previous match.
Yeap like in Moz.


> - It auto-detects whether the search should be case-sensitive or not:
>   If the search term is all-lowercase then the search will be
> case-insensitive,
>   but if there's at least one uppercase char it'll be case-sensitive
>   AFAIK there's no way to search case-sensitively for an all-lowercase
>   search term, but it still works very well for me.
Yeap it's nice.

> - Using a different key combination (Ctrl-R in emacs) you can
>   activate the same type of search, but backwards.
> - It's is not restricted to links, of course, but works with any text.
Again I like the Moz way. We got both options and both are *really* easy to 
activate, one of them just requires you to type. You cannot beat that.

J.A.

Disclaimer:   
I just described the way it works in emacs,  
e.g. for people who want to try it themselves to get first hand experience.  
I didn't want to suggest flashing the screen or using emacs' keybindings.   
 
That's why I talked abstractly of "visual feedback" and  
"adapting the ideas" :-) 
After all it has to fit into KDE as a whole. 
 
 
> > - You press a key-combination (Ctrl-S in emacs' case) to activate it  
  
> In Mozilla  
> - just typing the word ->incremental search on links  
 
Hmmm, I'm not sure if I want to fire off a search when I just press a letter. 
 
 
> - '/' -> activates search on text  
>  
> I'd go for the Mozilla way because  
> - It's faster, popups, no key combinations, it's easy and fast  
> - Consistency with Mozilla (it's always an advantage).  
 
ACK.  Consistency with other software is a Good Thing (tm)  
if it doesn't get into the way of KDE's own standards.  
The "/" is used to initiate a search in less and vi, too,  
although in these cases it's not incremental. 
 
  
> I'd just go for a key-combination if we were to implement this not as a  
> browser specific but a global kde feature.  
 
BTW: Someone mentioned that there's already an incremental search in kate but  
I haven't been able to find it.   How do you activate it? 
 
  
  
> > but you type the search term letter by letter in a one-line bar at the  
> > bottom.  
> This could be an interesting adition. Maybe show what your typing in the 
botom  
> of the window. (Where some messages are shown, like "page loaded" you 
know?).  
 
Yes, that's what I had in mind. 
  
  
> > - It moves the cursor to the next match and highlights it,  
> > but it also marks all the other matches that are currently visible.  
> I don't know about this one... I understand the point but sometimes I find 
it  
> confusing, I prefer focusing on the current match only. But I do understand  
> it might be useful. I'd say either try to make it a very non intrusive mark,  
> or put it as an option :D  
 
emacs does it by using a faint text background colour, a different one than  
for the current match, and I don't find that intrusive at all. 
 
 
> > - If you hit the key combination again it jumps to the next match.  
> (related to the first one...)  
  
How do you jump to the next match in Moz?   
 
 
> > - If you cancel the search (with Ctrl-G in emacs' case) it returns  
> (Escape, like in Mozilla, is much more intuitive.)  
 
Escape is already taken in konqi, it stops loading.  Not sure if it's wise  
to overload it (for an already completed load!) during a search.  
  
 
> > the cursor to the point where the search was started, but when  
> > you cancel it by moving the cursor with the arrow keys it stays  
> > at the last highlighted match.  
> This *might* be nice, if we can still press the escape key even after moving  
> the cursor to reset the search start position.  
 
I wanted to point out that there are two different exit points to the search.   
I think that having a way to choose that on a per-case basis is important. 
And if the current match is on a link or button then there might be a third 
way: Execute the action (follow the link or submit the form) if a special  
key is pressed, e.g. "Enter" or "Arrow right".   
 
 
  
> > - It gives visual feedback by flashing the screen if the search  
> > reaches the bottom of the file, and hitting the key combo once  
> > more wraps the search.  
> > - It gives visual feedback by flashing the screen if you type a  
> > character that causes the search to fail (no more matches)  
>  
> Flashing the screen sucks! :)  
> I'd go for a message in the bottom of the window or something like that, 
maybe  
> bold or highlighted to make it more visible. Eventualy a beep like in Moz.  
 
I was just describing emacs' behaviour (which is configurable, BTW).  
I didn't want to suggest this for konqi. 
 
Beeping sucks, too, IMHO :)  
But if it's a regular application event I guess you'd be able  
to configure the sound to play in kcontrol anyway,  
including the option to *not* play anything. 
A message in the status bar would be ok, I guess.  
  
 

Subject: Re:  konqueror browser feature "type ahead" aka "find as you type"

> Disclaimer:
> I just described the way it works in emacs,
> e.g. for people who want to try it themselves to get first hand experience.
> I didn't want to suggest flashing the screen or using emacs' keybindings.

Yeap, I thought so, I just felt like making comments about the whole thing :)

> Hmmm, I'm not sure if I want to fire off a search when I just press a
> letter.
It works like that already when browising locally or via ftp.
Just open Konqueror in your home dir and start typing ;)

> > - '/' -> activates search on text
> >
> > I'd go for the Mozilla way because
> > - It's faster, popups, no key combinations, it's easy and fast
> > - Consistency with Mozilla (it's always an advantage).
>
> ACK.  Consistency with other software is a Good Thing (tm)
> if it doesn't get into the way of KDE's own standards.
Yes, couldn't agree more. It is just one factor that should be taken into 
consideration, nothing more.
In fact I even think that it would be best if only typing searched the whole 
text since it's probably more used, and '/' (or some other key) enabled 
search on links. Many mozilla users agree on that.

> The "/" is used to initiate a search in less and vi, too,
> although in these cases it's not incremental.
Yeap.


> BTW: Someone mentioned that there's already an incremental search in kate
> but I haven't been able to find it.   How do you activate it?
Settings->Configure Kate->Editor->Plugins.
I don't really like it...


> How do you jump to the next match in Moz?
F3 or Ctrl+G
And no, I don't like either of them. 

You can read all how it works in Moz here by the way:
http://www.mozilla.org/projects/ui/accessibility/typeaheadfind.html

> > (Escape, like in Mozilla, is much more intuitive.)
>
> Escape is already taken in konqi, it stops loading.  Not sure if it's wise
> to overload it (for an already completed load!) during a search.
Also stops loading in Mozilla, overloading works fine IMO.

> > This *might* be nice, if we can still press the escape key even after
> > moving the cursor to reset the search start position.
>
> I wanted to point out that there are two different exit points to the
> search. I think that having a way to choose that on a per-case basis is
> important. And if the current match is on a link or button then there might
Yes I agree. 
I meant that besides that it should also be possible to reset the search point 
if you exit in a way that doesn't resets it. Was it understandable? :)


> I was just describing emacs' behaviour (which is configurable, BTW).
> I didn't want to suggest this for konqi.
>
> Beeping sucks, too, IMHO :)
Yeap :)

> But if it's a regular application event I guess you'd be able
> to configure the sound to play in kcontrol anyway,
> including the option to *not* play anything.
> A message in the status bar would be ok, I guess.
I think so to.

J.A.

>> Hmmm, I'm not sure if I want to fire off a search when I just press a  
> > letter.  
> It works like that already when browising locally or via ftp.  
> Just open Konqueror in your home dir and start typing ;)  
  
I see what you mean.  But then it should work *the same way* 
in all those cases.  Currently it only seems to work for the  
first letter when in file manager and (s)ftp mode.  
 
 
> > BTW: Someone mentioned that there's already an incremental search in kate  
> > but I haven't been able to find it. How do you activate it?  
> Settings->Configure Kate->Editor->Plugins.  
> I don't really like it...  
 
Ah, I didn't think of searching the plugins.  Thanks.   
 
Well, I'd say it's already at least half-way there.   
But then again, I'm probably biased because it's clearly inspired  
by the emacs way of doing I-Search, not the Mozilla way. 
 
The default key combos Ctrl-Alt-F and Shift-Ctrl-Alt-F  
are awkward though.  I guess all the easy ones are already taken... 
but this is even more emacs style ;-))) 
 
 

> > - '/' -> activates search on text 
 > > 
 > > I'd go for the Mozilla way because 
 > > - It's faster, popups, no key combinations, it's easy and fast 
 > > - Consistency with Mozilla (it's always an advantage). 
 > 
 > ACK.  Consistency with other software is a Good Thing (tm) 
 > if it doesn't get into the way of KDE's own standards. 
>  Yes, couldn't agree more. It is just one factor that should be taken into  
>  consideration, nothing more. 
>  In fact I even think that it would be best if only typing searched the whole  
> text since it's probably more used, and '/' (or some other key) enabled  
>  search on links. Many mozilla users agree on that. 
  
Consider the 'search' concept at a higher level; searching all widgets/controls text, or even all text 
in a view, window, or perhaps an entire application for a string or regexp.  If I was in a tabbed 
preference pane and want to search for a setting, I can see that the ability to strike some (kde-
wide/qt-wide ?) search key sequence, start typing, and have the application pop to the tab/view/
window containing this information could have a huge positive impact on accessibility and 
usability.  Perhaps even searching on keywords could be implemented (a button labeled 'burn' for a 
cd might also be tagged with searchable keywords such as 'write', 'create', 'finish', etc.)

I'm asking you to temporarily consider the entire application not as a set of buttons, knobs, and 
levers, but as a searchable, highly structured text 'buffer', and that I could jump to individual 
components via a textual/regexp search mechanism.  With this the case, and that a web page is 
somewhere between a text buffer and an application window, it be a good idea to decide whether 
an implementation of this wish should consider the browser search-as-you-type feature:

	* separately
	* to follow a 'text editor/text buffer' model
	* to follow the mozilla functionality closely
	* or perhaps to consider it as part of a larger picture of searching within KDE apps

I'd personally like to get a quick (even throwaway) implementation of find-as-you-type into 
konqueror so I can start using it more efficiently; but I can also see waiting if something is in the 
pipeline to create a search mechanism standard that spans all KDE/Qt apps, and that konqueror 
should fall into this category as well.  This, IMHO, could do for desktop usability what the per-site 
search engine does for the web.

I should clarify; when I say a kde-wide key sequence for searching, I mean a key sequence to 
initiate a search within the application currently in focus, and that such a key sequence would be 
standard across all kde apps (such as the sequences for 'save', 'open', 'quit', etc.).  I don't mean a 
key sequence that would search for a string across all of that user's running kde applications.

I also spent 20 votes on this bug, since this is the biggest thing I miss in 
konqueror (or generally kde) - even my InternetExplorer based browser MyIE2 for 
windows had something like "Find as you Type". 
 
I would opt for using a key to start this "typeaheadfind", since it is very important 
to keep other single-key shortcuts (like J + K for scrolling up/down) - like using "/" 
in mozilla. 

Subject: Re:  konqueror browser feature "type ahead" aka "find as you type"

> ------- Additional Comments From stubenschrott@gmx.net  2003-09-27 15:47
> ------- I also spent 20 votes on this bug, since this is the biggest thing
> I miss in konqueror (or generally kde) - even my InternetExplorer based
> browser MyIE2 for windows had something like "Find as you Type".
>
> I would opt for using a key to start this "typeaheadfind", since it is very
> important to keep other single-key shortcuts (like J + K for scrolling
> up/down) - like using "/" in mozilla.

Why is it so important to keep those single-key shortcuts? In "File 
Management" profile you don't have them.

J.A.

Subject: Re:  konqueror browser feature "type ahead" aka "find as you type"

> > I would opt for using a key to start this "typeaheadfind", since it is
> > very important to keep other single-key shortcuts (like J + K for
> > scrolling up/down) - like using "/" in mozilla.
>
> Why is it so important to keep those single-key shortcuts? In "File
> Management" profile you don't have them.
>
> J.A.

If they were only valid in Konqueror, i wouldn't really care - but also e.g. 
kmail uses the khtml engine for displaying html messages and i definetly 
don't want to lose "d" for deleting messages and all those other one-key
shortcuts. And so it would be easier to designate a "starter key", since it 
won't break all those apps which use (or will use) khtml.

Martin

Subject: Re:  konqueror browser feature "type ahead" aka "find as you type"

> > > I would opt for using a key to start this "typeaheadfind", since it is
> > > very important to keep other single-key shortcuts (like J + K for
> > > scrolling up/down) - like using "/" in mozilla.
> >
> > Why is it so important to keep those single-key shortcuts? In "File
> > Management" profile you don't have them.
> >
>
> If they were only valid in Konqueror, i wouldn't really care - but also
> e.g. kmail uses the khtml engine for displaying html messages and i
> definetly don't want to lose "d" for deleting messages and all those other
> one-key shortcuts. And so it would be easier to designate a "starter key",
> since it won't break all those apps which use (or will use) khtml.

OK good point. That's another story and I wouldn't like that either.

Related to this:
This made me realize that you can use khtml shortcuts in other applications 
that use khtml, besides konqueror. This shortcuts sometimes end up beeing 
intrusive, and therefore incosistent. In Kmail for instance, you can use "j" 
for "down" but not "k" for "up" because it is a kmail shortcut(*).

So either this shortcuts should be somehow disabled when used in other apps 
(not sure how feasable), or kde apps that use khtml should avoid at all costs 
using its key bidings.

(*) So your argument is not 100% correct, you'd not lose any kmail shortcuts, 
but I don't like the current mess with shortcuts so you still have a point.

J.A.

It's fine if search starts with a key.  In file management mode, search also starts with a key, and I hope it stays that way.  That makes looking for folders and files a snap.

It'd be awesome if the search in konqueror's file management mode would do a substring search if nothing was found beginning with the text I just typed.  Of course it should let me know of that particular in the status bar.  And I think it should also let me know what I am looking for in the status bar when I'm typing to find a file, a la Mozilla (File found: Ian Van Dahl...).  And the spacebar should also be paid attention to as well, because currently I can't search files with spaces in their name.  On a two thousand artists folder, a hundred of them beginning with the word "The" (the beatles, the beloved, the real mccoy, you get the idea, no pun intended), type ahead find is mostly useless.

On another note, ... dammit I forgot.

I really love the way Mozilla handles Type Ahead Find.
It makes keyboard-oriented browsing a nice experience.

The nice point is that links browsing in the current page
is linked to type ahead find.

If you search for "foobar" and find an occurence that is
in a link, you can simply type "Return" and the link is followed.

If you search for "foobar" and find an occurence, you can
go to the next link *after that occurence* by using Tab (resp.
to the previous links *before that occurence* by using Shift-Tab).

It helps a LOT!!! when keyboard-browsing.

How is the status of this bug report?
Because it was opened 1.5 years ago, and is still "new".

I'd like to hear, if any developer wants to implement this great enhancement in the future or if will become a "WONTFIX"?

Thanks,

Martin

What bug report? WONTFIX makes no sense for a valid (NEW) wish. 

CVS commit by arendjr: 

Fixed the popular wish #51259: konqueror browser feature "type ahead" aka "find as you type"

KHTML now gains type-ahead find. You can invoke it by pressing either
/ for 'Find text as you type' or ' for 'Find links as you type'. You can
exit type-ahead mode by pressing Escape or waiting 3 seconds.

Type-ahead works in all KHTML enabled applications, but I did discover
some issues in KMail. As KMail has a lot of single-letter shortcuts, those
keys won't work in type-ahead rendering in basically useless there. I'll
try to find a workaround for this.

CCMAIL: 51259-done@bugs.kde.org 


  M +131 -0    khtmlview.cpp   1.623
  M +3 -0      khtmlview.h   1.202

Great, thank you! :))))
Two questions.

- Will it be in KDE 3.2.2?
- When only text in a link is selected, can we follow it by pressing return?

Thanks again!
J.A.

> Will it be in KDE 3.2.2?
No, you'll have to wait for 3.3 or get it from CVS if you really can't wait ;)

> When only text in a link is selected, can we follow it by pressing return?
Not yet, but I intend to do that.

Arend jr.

> > Will it be in KDE 3.2.2?
> No, you'll have to wait for 3.3 or get it from CVS if you really can't wait
> ;)

Nah, I can wait...

> > When only text in a link is selected, can we follow it by pressing
> > return?
> Not yet, but I intend to do that.

Ok, nice :)

J.A.

wow, that's great thing, thanks a lot :)

somebody said, that anonymous cvs-access is some days behind current cvs, so I will probably have to wait 3-4 days, until I can finally browse the net with my keyboard :)

some questions about your implementation:
1) after searching an entry, can you select the next link, whcih matches the typed character with F3 or tab or something like that?
2) Is it/will it be possible to also search for text in non-links with e.g. a "?" starter key instead of "/" for links?

sorry for number 2) above, I just noticed, that this is already possible with your implementation.

but another feature-request related to this, and making find-as-you-type even better would be, if you could also search for alt-tags in images to select an image. (maybe configurable, or with another starter-key).

I'm realizing now that this feature, as originally filed, may not exactly match what has been implemented.  One of the most important capabilities I appreciate is the ability to follow a totally- or partially-overlapped link by hitting return.  There are many other possibilities for how this could work, however, which leads me to my next point.

I don't have the ability to test this out; could someone who's running a recent CVS rev (and has personally evaluated this recently added functionality) file a wish for the ability to follow links via return/enter so the people following this current wish can:

* track the new wish
* contribute their input re: the mozilla behavior(s) and the desired behavior(s)

I'd like to contribute my ideas in the context of a wish filed by someone who's tested out the current implementation under CVS.  Since the current wish is marked fixed, it seems proper to file a separate wish for this other functionality.  One of the reasons for this might be that mozilla's find-as-you-type is a mass of related functions associated with possibly different UI decisions.

Thanks greatly for adding this functionality, and for Konqueror.
Krishna Sethuraman

@Krishna: Why wouldn't the implementation match the bug filing? If you mean you want to be able to search for a link by typing its text and then press enter to follow the link, that has already been implemented.

Yes, I also think the search works like expected.

I have only 3 (very) little complaints:
First (and most disturbing): it only works in the current frame, so if you visit a web page with frames, you may have to Tab for a long time before you can use type-ahead-find.

Second, I am using a german keyboard, where the / and ' keys are very badly arranged (I have to use shift for both keys), so it would be great, if the starter-keys could be configured ('f' (like find) would be great for example for those people who like single key shortcuts  :)

Third, it's nice that it captures the keyboard for 3 seconds, but it shouldn't capture the F1-F12 function keys. They don't have a use in type-ahead-find because they are no printable characters, but I have mapped F1 for a new tab, F2 to switch to the previous tab, and so on, and can't use them while type-ahead find waits for another key. This is no big thing, because I can press <Esc> <F1> in the cases where I really need it.

However, thanks for this great improvement to khtml.

> Second, I am using a german keyboard, where the / and ' keys are very badly
> arranged (I have to use shift for both keys), so it would be great, if the

Isn't / on the Numpad on the right of the keyboard?
(I even thought * instead of ' could be better because of that).

J.A.

> Isn't / on the Numpad on the right of the keyboard? 
> (I even thought * instead of ' could be better because of that).

IMO: two things wrong with numpad:

- it is on the far edge of the keyboard
- not every keyboard has a numpad (think laptops)

I think "/" is a good default (it starts find in vi, less etc.), but still... Make it configurable. 

Yes I also like / as the default since I really like vim-bindings (btw, I am sooo happy that khtml has "j" and "k" keys to scroll up- and down. :)

BTW, another small annoyance:
If I search for a link, the page jumps. Ok, this is necessary very often, but rather disturbing, if the found link is in the visible area of the webpage. Of course sometimes the first letter  of a "verylonglink" is not in the visible area, and so a jump is necessary, but sometimes all letters would be visible, but the webpage jumps nevertheless in order to have the link on top of the visible area.

sorry for my bad english, but I hope you understand what I mean.

Will a link be selected if the search text only partially overlaps the link?

How about if it doesn't overlap at all, but is very near by -- say within 25, 100 characters?  I request this so that the next TAB-key strike will not jump back to the last selected link, which may be off the page entirely.

In a long page, I sometimes type text that I remember to be near a link's context, then TAB a few times to get to the link itself.

"In a long page, I sometimes type text that I remember to be near a link's context, then TAB a few times to get to the link itself."
Yes that's a very good point, since sometimes you can't reliably search for a link directly.
I would also like to have this feature, but to answer your question, I didn't find it in the current cvs version.

In particular, this feature is very handy for userid and password fields; I can hit  -> /me: <- and it will select (in Mozilla) the 'me:' in 'username:' .  I then strike TAB, and it pops me into the username field.  Similarly for d: -> password: .

So it says this was fixed, what version of KDE will have this functionality then?

Hackeron: It will be in KDE 3.3.

sorry for keep bringing up new feature requests for type-ahead but I have another idea :)

when typing a string I want to search for, and it is not found, it should emit a sound (maybe configurable in the kde system configuration panel), and not just writing "link not found" in the status bar. Also firefox does it this way, and really helps when searching.

@MaxAuthoriy: Type ahead-find will now give a little beep (just like Firefox) if a search can't be found.

thanks a lot Arend :)

By the way, to complete the intuitivity of type-ahead-find, it should also follow firefox's way of behavior when a link/text is not found.

This means, when I want to search for "Beelen" and write "Belen" instead, in konqueror, it shows:
'Link "Ben" not found', but it should say (like firefox): 'Link "Belen" not found', since it is natural, if you type your search string, and here 3 beeps for 3 errors, that you hit backspace 3 times, to correct the string.

It's difficult to explain, but just try to search for a link in firefox and make an error and do the same in konqueror, I think it's more natural to backspace over the error.

It would be great if type ahead was configurable.
For example, I'd like to have an option that hightlights all occurences of the search string on the website, so as to find the place you are looking for more quickly and not having to press F3 to go to the next occurence.
And I agree with what was previously said, the "/" keybinding should be configurable as well.
Other than that, I really like this feature :-)

*** Bug 83078 has been marked as a duplicate of this bug. ***

first, thanks for implementing my wish with the idea of 'backspacing'.

However, somehow the 'beep' does not work. Do you have to configure it in 'System Notifications' in kcontrol? I have at least set 'KDE System Notifications'->'No matching completion was found' to some valid wave-file. Moreover, I have compiled support for the PC speaker in my kernel, so this should work as well, if you emit this kind of a beep.

One (hopefully :) ) last thing:
Would it be - easily - possible, if a link was found and (Ctrl-)Enter was pressed, that the find will stop and don't wait for the 3 seconds timeout? Since I when I browse some forums with the keyboard, I usually search for link, and open it with Ctrl-Enter in the background, than it would be convenient to immediately being able to search for the next link, instead of waiting up to 3 seconds or having to hit 'Esc' before searching for a new string.

IMHO, these are separate enough concepts that they deserve bugs or wishes on their own, especially since the core of the original feature has been checked in.