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

List:       kwrite-devel
Subject:    Re: Splitting incremental find and general search/replace
From:       Anders Lund <anders () alweb ! dk>
Date:       2007-07-27 18:02:13
Message-ID: 200707272002.14303.anders () alweb ! dk
[Download RAW message or body]

On Friday 27 July 2007, Robert Buchholz wrote:
> 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--

This only concerned the shortcut, as the idea was to add a shortcut that would 
activate a search widget configured for incremental search.

>   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:

Note: The problems only concerns the GUI.

> 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.

This is not a problem at all, we simply doesn't add incremental search patters 
to a history.

> 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).

That is correct. Personally I prefer to search in the commandline (kde 3.x) 
which avoids this problem.

> 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.

I can't se how that is a problem. In the case of an incremental search, the 
pattern entry could be cleared or selected.

> 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.

Part of the above mentioned thread concerns searching the selection, and comes 
up with solutions that would work for incremental search as well.

> 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.

No, we are still safely away from release day :)


-- 
Anders

www: http://www.alweb.dk
jabber: anderslund@jabber.dk
_______________________________________________
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]