Dear Kate developers,

  I did not want to hijack the recent thread by Sebastian and Anders, 
since my comments concern the design rather than the fine tuning of the 
current search approach. Having read [1] back from February, I am rude 
enough to su summarize it as this:

--8<---------8<---------8<---------8<---------8<---------8<---------8<--
Christoph Cullmann:
    Perhaps there should be just two search actions, one opening the  
    searchbar in incremental mode, one in non-incremental mode. Or is
    this a flawed idea?

Anders Lund:
    I think so, why have another shortcut to learn/menu item? We can
    just add a checkbox for it. 
-->8--------->8--------->8--------->8--------->8--------->8--------->8--

  I bring up this subject again because I believe the whole situation 
has changed, and just adding a checkbox for incremental will turn the 
whole of the search functionality into a monster, that is neither 
powerful nor easy to use.

My proposal is, simply put, this one:
    Separate incremental find from non-incremental Search and Replace.


Aren't those just two sides of coin?
  I believe the two are basically different functionality. From a 
technical point of view, they are similar, just a configuration option 
away from each other. From a use case point of view, I would not say 
that.
  Incremental search is, as the name already puts it, a way to searching 
a document, intended for navigating through it. This is what made it 
popular in web browsers. There it is a feature for read-only text, and 
adaptations for other text editors also define this as a simple and 
basic feature [2], separated from Search and Replace.
  Search and Replace, on the other hand, in the form presented in stable 
Kate is a tool to manipulate text or query it with complex expressions, 
usually with the intent to change it.


Why separate them?
  I have seen in the Alpha versions of Kate and the recent discussions 
that integrating the two options could lead to crippling of features 
and weird usability changes. Separating them could solve these issues:

1. Search and replace history
   It seems quite hard to implement search history with incremental 
search, and I do not see that feature implemented in Kate right now. 
Losing this will also lose a lot of comfort in search, and especially 
replace actions.

2. Speed up search, esp. in regular expressions
  Discussed quite often, incremental search costs some real bucks, 
especially when enabled with regular expressions, not speaking about 
the multi-line version. Separation would stop the need to manually 
disable "incremental" _before_ typing a complex query (or a simple 
query on a big document).

3. Selection as default for search query
  Discussions about whether the current text selection should be default 
search query seem to have ended with "it's a problem with incremental 
search, as it could happen that the selection is not a result of its 
own search action." -- This argument would be vain.

4. Search in text selection
  While there were valuable comments made about having two modes of 
selection for "Search in Selection" (one for limiting the search area 
and one for displaying the results), the whole reason for change was 
that the search will automatically, and it will break when doing it 
incrementally. This reason will be gone when the (old) behaviour is 
back to "press Enter to start query".
  Changing to new ways for selection search could be implemented later.


Implementation?
  Choose yourself :-) My imagination looks like this: Implement one very 
basic incremental find bar (Firefox style), and one complex search 
query panel, as a window or a bar. The two could exclude each other, so 
you can switch between them.

I hope I did not step on anyones toes bringing this subject up again, 
but I believe it needs to be addressed and I was yet not around in 
February.

Sorry for length,

Robert

[1] http://thread.gmane.org/gmane.comp.kde.devel.kwrite/11559
[2] MS Visual Studio, SharpEdit, UltraEdit are three editors I found via
    Google that use incremental search, all as extra menus.
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel