<p></p>
<blockquote>
<p dir="auto">Depends what we use the language server for.</p>
</blockquote>
<p dir="auto">Well, apart from the autocomplete which I agree is just so wrong (for C++) that I turn it off in Geany, the other big reason I moved away (for C++) is the styling of a name the same wherever it appears, so if something ever appears as a type its gonna be coloured a type even when used for a function, or a variable no matter if its in a totally different scope.  So I would say that replacing the Scintilla lexer would be a good thing to aspire to ... longer term maybe.</p>
<blockquote>
<p dir="auto">It took just about 15 years to recover from tag manager integration and we are almost there. We should start thinking about what to do in another 15 years :-)</p>
</blockquote>
<p dir="auto">Good idea!!!!! [runs screaming]</p>
<p dir="auto">But synchronous operation is going to be slow, even for autocomplete.  Think of how long it takes to compile one of the big Scintilla C++ files, especially on a RPi, would you wait that long to get the autocomplete list?</p>
<p dir="auto">Why does autocomplete need a full compile? Doesn't need code generation, but needs everything before it and type inference is why, rust and go and others already do static inference, and C++ is starting to (which is why I keep using C++ as an example, it manages to incorporate every problem other static languages could give us, plus some of its own, ahh bless :-) and in theory an LSP server could do dynamic typing of Julia and maybe even Python and similar.  To autocomplete a name with inferred type the "compile" has to happen to find its type, then the member list can be offered.</p>
<p dir="auto">So we want the "compile" to happen while the user is typing so the lookup is fast when they type the <code>-></code>.</p>
<blockquote>
<p dir="auto">there will have to be some JSON parser/serializer (json-glib seems to be a natural choice) in its core that will have to be either bundled or an external dependency - not sure if it's fine or not for Geany, for plugin it would be a easier decision.</p>
</blockquote>
<p dir="auto">JSON is one thing where there are a plethora of libraries, and JSON RPC libraries even.  But yes putting such in a plugin would be "easier" if only Geany would let a plugin replace parts of its functionality.  Maybe a core plugin could keep in sync with Geany during a progressive development, maybe.</p>
<blockquote>
<p dir="auto">The rosy world of LSP autocompletion for me is just an excuse why not improve the scary tag-manager-based scope completion much :-).</p>
</blockquote>
<p dir="auto">Good, keeps the number of PRs labelled <code>tag-manager</code> down. ;-P</p>
<p dir="auto">I havn't tried this PR because I'm not sure how to test it, do you have any solid examples of ctags files, especially one that the existing parser fails on?</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany/pull/3049#issuecomment-994709343">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAIOWJY2K34FYFOYREVYGDLURB5EHANCNFSM5JUGWD2A">unsubscribe</a>.<br />Triage notifications on the go with GitHub Mobile for <a href="https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675">iOS</a> or <a href="https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub">Android</a>.
<img src="https://github.com/notifications/beacon/AAIOWJZ2KQSNWEJAZUVAIFTURB5EHA5CNFSM5JUGWD2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHNFA6XY.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/geany/geany/pull/3049#issuecomment-994709343",
"url": "https://github.com/geany/geany/pull/3049#issuecomment-994709343",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>