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

List:       kwrite-devel
Subject:    Re: KTextEditor::SearchInterface
From:       Milian Wolff <mail () milianw ! de>
Date:       2015-04-16 13:11:12
Message-ID: 2741961.gMZ5BmfI8e () milian-kdab2
[Download RAW message or body]

On Friday 20 March 2015 20:28:40 Thomas Friedrichsmeier wrote:
> Hi,
> 
> On Fri, 20 Mar 2015 18:36:14 +0100
> 
> Andreas Cord-Landwehr <cordlandwehr@kde.org> wrote:
> > However, for me it looks like re-implementing something that is
> > already there for Kate, and IMO it seems much more straight forward
> > to simply allow a (minimalistic) search interface for KTextEditor.
> > 
> > I got Sven to be "undecided" about it, other opinions? :)
> 
> providing a multi-window search bar - across several ktexteditor
> windows, but possibly also html windows, etc. - is one of the things
> that I have on the wanna-implement-some-day list for RKWard. Not having
> to worry about the search itself would clearly help. (Now imagine,
> we'll have a generic KSearchBar widget to go with this, one day...)

You "just" need to implement support for Kate plugins in RKWard and then you'd 
get the Kate search plugin for free which supports all this, no? With a 
SearchInterface you'd still need to reimplement the widgets etc. pp. which is 
not necessary with the plugin approach.

> Frankly, I have not even started porting to KF5, yet, and so I may be
> missing important things. Basing this on what I see in KDE 4
> KTextEditor::SearchInterface:
> 
> A feature that looks quite non-trivial:
> - BlockInputRange: I'd hate to have to worry about this.
> (Alternatively, it would be even better, if there simply was an option
> to search inside the current selection - if any -, be that plain, block,
> disjunct, or whatever else ktexteditor will support in the future)
> 
> A thing that would be very useful to have in the API, too, but seems to
> be missing:
> - HighlightAllMatches
> 
> Things that don't seem essential:
> - EscapeSequences
> - WholeWords
> (The calling code could simply translate the search string into an
> appropriate regexp; if that plays nicely with ktexteditor internals, it
> might even be worth basing the API on a QRegExp)

Bye

-- 
Milian Wolff
mail@milianw.de
http://milianw.de
_______________________________________________
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]