[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:       Robert Buchholz <rbu () gentoo ! org>
Date:       2007-07-28 14:09:18
Message-ID: 200707281609.19178.rbu () gentoo ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Thanks for the replies so far. So this is what happens when you start a 
thread here and go away for a day :-)


On Friday, 27. July 2007 20:02, Anders Lund wrote:
> On Friday 27 July 2007, Robert Buchholz wrote:
> > 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.

That is true, but with Kate being a graphical editor, its GUI is one of 
the major components. Its GUI is the place where features (options) are 
born, enabled and removed.


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

Which would mean I have to disable incremental search to save a history. 
That also means there are times when incremental search is disabled. To 
my mind, incremental search is a way to finding a known place in a file 
very fast. Pressing CTRL+F, then tabbing through the options to 
enable "incremental", then tabbing back to the query field and starting 
to enter my query is not a fast way to finding.

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

I do not want to attack you here, but the implication here is that the 
GUI of the graphical editor is so flawed that you need to interface its 
features via CLI. I sure don't hope that is the goal.
Think about making the GUI as attractive to power users like you that 
you do not want to use the CLI interface to Kate anymore :-)


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

Good to know.

Regards,

Robert

[Attachment #5 (application/pgp-signature)]

_______________________________________________
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]