[prev in list] [next in list] [prev in thread] [next in thread]
List: kwrite-devel
Subject: Splitting incremental find and general search/replace functionality
From: Robert Buchholz <rbu () gentoo ! org>
Date: 2007-07-27 16:59:06
Message-ID: 200707271859.07051.rbu () gentoo ! org
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic