Please, raise your hand if you'd like...

Anders Lund anders at
Fri Mar 11 12:12:34 UTC 2005

On Thursday 10 March 2005 15:09, Adam Treat wrote:
> Hey all, I just blogged this:
> Please, raise your hand if you’d like:
> * Color syntax highlighting in KDevelop’s code completion?


> * Icons in the entry list corresponding to the entry type … ctor, dtor,
> method, member, etc, etc?
> * Some sorting by entry type so all ctor’s come first, dtor’s next, etc,
> etc?

Yes, optionally. We have discussed a way to allow entries from several sources 
as well, so both icons and sorting could come in handy here. The idea is that 
it should be possible for sevral objects to use the completion, so that for 
example kdevelop code completion does not disable word completion etc. + in 
some cases, entries for more sources could be shown all at once maybe.

> * The ability to specify what parts of the entry are “completeable” eg, if
> I’m completing a method decl I don’t necessarily want to key the return
> type?

Doesn't we support that allready? there should be a prefix and a suffix that 
is not completed. The docs in ktexteditor/codecompletioninterface.h says:

 * An item for the completion popup. <code>text</code> is the completed 
 * <code>prefix</code> appears in front of it, <code>suffix</code> appears 
after it.
 * <code>type</code> does not appear in the completion list.
 * <code>prefix</code>, <code>suffix</code>, and <code>type</code> are not 
part of the
 * inserted text if a completion takes place. <code>comment</code> appears in 
a tooltip r
ight of
 * the completion list for the currently selected item. <code>userdata</code> 
can be
 * free formed data, which the user of this interface can use in
 * CodeCompletionInterface::filterInsertString().

> If so, then the following changes will need to be made to KTE Completion
> interfaces:
> * KTE::CompletionEntry needs methods for specifying an icon to go with the
> entry and comparison operator overloads to allow sorting by entry type. It
> also needs some way of specifying that a prefix/postfix should be inserted
> upon completion, but not part of the actual keying.

This can be achieved using the 'userdata', as specified in the docs.

> * KTE::CodeCompletionInterface needs methods for determining if the current
> completion box isvisible and hiding methods.

isCompletionBoxVisible() could be a valid addition. I don't understand why the 
hiding is required.

> The color syntax highlighting could be done in a couple different ways.
> KDevelop could do specify the individual entries in richtext, but the
> interface would have to know that it is doing so and render it accordingly.
> I am working on katepart’s KateCompletionItem (subclasses QListBoxText
> currently) to see if I can get it to render richtext. Another alternative
> is to have the interface entirely responsible for highlighting. Presumably
> katepart could do this, but the highlighting might not be as rich since
> KDevelop knows more about the C++ syntax than Kate. Regardless, I think
> these things would be pretty cool and it’d be nice to have them before KDE
> 4, but I don’t know. Perhaps if enough hands are raised… :)

First, you can't rely on kate in a KTE interface. And you'd have to add a 
class to support it, or create a katedoument to get kate to highlight it, 
which is probably a bit overdo. So my take is that the provider of the tip 
should do this. And maybe the completionentry should use a different form, 
with one property for the richtext data and one for the string to insert - 
unless you'd want to be able to guarantee the prefix/suffix parts of each 
list item to be equally wide, using richtext could deprecate that part of it.

> I think this would be pretty hard to make BC, but you guys would know
> better than me.

Be as BIC as you want, this will be target for 4.0 :)


PS is kdevelop-devel subscribed to kwrite-devel? It would be nice if we could 
keep this discussion in one place, preferably kwrite-devel.
jabber: anderslund at

More information about the KDevelop-devel mailing list