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

List:       quanta-devel
Subject:    Re: [quanta-devel] Change to KTextEditor code completion interface
From:       Hamish Rodda <rodda () kde ! org>
Date:       2006-11-09 13:02:31
Message-ID: 200611100002.33956.rodda () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 09 November 2006 18:42, you wrote:
> Hi,
>
> On Thursday 09 November 2006 08:11, Hamish Rodda wrote:
> > Unfortunately in my porting I missed that Quanta was actually using
> > the old interface.
>
> Yes, that part was not really touched since the big changes in KDE4
> begun. Actually I think that it was compiling but not working since
> months.

Yes, I don't think it was completed within katepart to start with.

> > I've started on porting Quanta to the new interface, but I have a few
> > questions:
> >
> > 1) Invocation of code completion.
> > This is now handled in three ways: a) automatic invocation, when the
> > user types specific text b) manual invocation, when the user types a
> > shortcut, and c) 3rd party invocation, eg. if Quanta specifically
> > requests a code completion to be shown.
>
> Exactly.
>
> > Currently you're using your own system to provide invocation, which
> > under the new scheme would be c).  However I'm guessing that you
> > might be interested in using the inbuilt invocation now?  Currently
> > it is implemented with regexps for finding the start and end of the
> > range of text to be completed - the new code needs to know where the
> > text to be completed against starts and finishes.  I was thinking of
> > enabling completion models to supply their own regexps for detecting
> > valid ranges of text to be completed, or even having a virtual
> > function which can be called to provide this detection.
> >
> > Here are the inbuild regexps as they stand at the moment: word
> > start: "\b([_\w]+)$", word end: "^([_\w]*)\b".  I guess they might be
> > a bit too programming-specific in comparison to what you need.
> >
> > Alternatively you could stay with your current system and use option
> > c), but that would limit the ability for other completion providers
> > to peacefully coexist (not that I can really see a good use case for
> > it, but...)
>
> This looks a nice idea. Actually the completion code does a lot of magic
> trying to find out what should be completed (tag, attribute, attribute
> value, function, etc.) and trying to find the beginning of the
> to-be-completed text. I may imagine that providing our own regexps to
> the completion interface and let it do the job would be much cleaner.

Ok, so I can port what's there to a simple case and you can work on it from 
there?

> > 2) actually, it's just the invocation issue now :)
>
> You mean the rest (providing the list with the completion items,
> filtering the result and so) is not changed in the new interface?

No, it's just that I can do the basics of that myself.  You'll have to add in 
the attributes, prefix / postfix etc, but then the filtering, sorting etc 
logic is all within katepart.

Cheers,
Hamish.

PS. I am actually still subscribed, so no need to cc me

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

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel


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