Fast code completion

[Kevin Funk]

On Tuesday, 4 February 2020 15:07:41 CET Thomas Schöps wrote:
> A somewhat off-topic comment to the following:
> 
> On 2/3/20 9:37 PM, Milian Wolff wrote:
> > Even today we have many (valid, imo) concerns that code completion
> > isn't fast enough. And this is pretty much the most important feature
> > of KDevelop for me...
> 
> I might be wrong on this or it might be outdated, but when I checked
> some time ago, I had the impression that KDevelop always needs to wait
> for a potential current parse process for a file to finish before
> invoking code completion. This seemed like it heavily increased the
> latency until code completion was available in most cases (i.e., unless
> code completion was triggered for an already-parsed document by pressing
> Ctrl-Space somewhere, for example).
> 
> For a couple of reasons, I decided to write my own IDE (
> https://github.com/puzzlepaint/cide ). Inspired by QtCreator, it keeps
> two libclang translation units (with the same settings) around for each
> file that is edited, and it only (alternatingly) applies parsing to one
> of them at each time. This way, the other translation unit is always
> available for clang_codeCompleteAt(), which seems to run near-instantly
> even for translation units that are not fully up-to-date. Thus, code
> completion is always fast.

This is an interesting approach, indeed. Thanks for sharing!

What makes me a bit sad, is that apparently wasn't more incentive/motivation 
to help out existing code editors, such as Kate or KDevelop, and bring in your 
knowledge and manpower there. What did let you go the NIH route and start with 
CIDE?

From a very brief glance over the CIDE landing page, the IDE looks like a 
stripped down KDevelop, using a KTextEditor-like editor in the center, but 
essentially doesn't take advantage of anything from those two projects? At 
least I don't see any evidence in the root CMakeLists.txt). No matter what: In 
the end you have been and will be re-implementing lots of features either 
KTextEditor or KDevelop have.

I'm really just wondering why we ('we' as in KDE) are apparently that bad at 
attracting or rather retaining new talent?

Regards,
Kevin


> If my observation was right that KDevelop does not do it this way, then
> I think that this might be the #1 change that could help to drastically
> reduce the code completion delay.
> 
> Best regards,
> Thomas


-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20200207/28d19c8c/attachment.sig>