Re: Change to KTextEditor code completion interface
Hamish Rodda <[email protected]>
| Newsgroups | gmane.comp.kde.devel.quanta |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ quanta-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/quanta-devel
signature.asc
(application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBFUybpH8BtnSmIlUYRAqu0AKCBSLdLEW8r6v75Rrlx0ypJawz81ACgnGmE PrwPc8qUWXArTnPPtiihTC8= =9cF2 -----END PGP SIGNATURE-----