michaliskambi
commented
1 year ago Thank you very much for this message -- the knowledge that you're active, and welcoming merge requests, is most valuable info to me.
Sorry for writing a long reply below :) I wanted to make sure I address your points. And some of my test conclusions on https://github.com/michaliskambi/elisp/tree/master/lsp have been chaotic/wrong, sorry about that too. I have improved them now after retesting things carefully, with both LSP servers (and Lazarus IDE) to have a clearer idea of the differences/similarities.
<less important information you may want to skip>
Background why I'm testing LSP servers:
-
We are exploring the idea to "bundle" Castle Game Engine ( https://castle-engine.io/ ) download with a compiler + IDE, to make starting with the engine as easy as possible for new people (even if they don't come with Pascal knowledge, they don't know about FPC, they don't have their favourite Pascal IDE etc.). CGE downloads are already "bundled" with FPC ( https://castle-engine.io/wp/2022/10/16/cge-downloads-now-come-bundled-with-latest-stable-version-of-fpc/ ).
The next step (planned sometime after CGE 7.0 release, at the beginning of 2023) is bundling CGE with "best Pascal IDE". What is "best Pascal IDE"? I see 2 candidates, A. Lazarus IDE or B. Visual Studio Code. The latter (VS Code) seems now a better candidate. It is just a powerful text editor, without the burden of Lazarus form designer (which we don't need in CGE, as we have own editor using CGE components for 2D and 3D games), without a multi-form Lazarus UI by default (without Lazarus Anchor Docking), well-known outside of Pascal too, with good UI, accepting command-line options to e.g. jump to file+line+column.
But for this, we need to enable in VS Code a code completion for Pascal that is comparable with Lazarus.
I was happy to learn that Pascal LSP servers (both your fork and Ryan Joseph) can be configured to provide this.
-
I also come from a more selfish point of view, which is that I'm a long-time Emacs user :) It was great to finally have intelligent Pascal code completion (in contrast to "unintelligent, dictionary completion") in Emacs, thanks to both LSP servers.
So now I know we can have
- an LSP server that works great with Pascal,
- and in particular with Castle Game Engine,
- and I can use it with Emacs,
- and I can recommend to "new users of CGE" to use VS Code + with the same LSP server ... and this makes me most happy :)
</less important information you may want to skip>
TODO: Make it aware of even LCL units? Seems like it cannot find any LCL unit, despite setting Lazarus dir.
That should not happen, I don't have that issue on any of my machines.
Testcase:
-
editing https://github.com/michaliskambi/pascal-language-server-genericptr/blob/castle-master/references.pas
-
e.g. go to line 91, https://github.com/michaliskambi/pascal-language-server-genericptr/blob/castle-master/references.pas#L91 , after
StartSrcCode:=CodeToolBoss.LoadFile(Filename,false,false);assignment -
type
Startand try to complete.Your LSP server (well, my fork on https://github.com/castle-engine/pascal-language-server ) will fail to complete anything, answering that
Laz_AVL_Treecannot be found.Ryan Joseph's LSP server will also fail to complete anything, without any message. (So actually it is a bit worse.)
Lazarus IDE is better: it can do code completion, so it evidently finds
Laz_AVL_Tree(since we confirmed it would fail to do code completion when units are missing). -
Removing
Laz_AVL_Tree, your LSP server reports it cannot findLazFileUtils. ThenCTUnitGraph, and thenCodeCache. Code completion starts to work only once I hackusesclause to be this:uses { RTL } SysUtils, Classes, { CodeTools } URIParser, //CodeToolManager, //CodeCache, {CTUnitGraph,} { LazUtils } //LazFileUtils, Laz_AVL_Tree, { LSP } lsp, basic, general;It will not compile of course with this
usesclause, since I removed all LCL units, but I can completeStartidentifier now :) -
I tested above both with VS Code and Emacs integration of LSP.
So, both LSP servers are equal here. But Lazarus IDE is able to be better -- maybe because it parses LPI / LPK. I don't know the internals of CodeTools, can they be augmented with this knowledge easily.
To be frank, this is not critical to my usage. In Castle Game Engine we don't rely in LPI / LPK to compile applications, and we can use bare FPC (with CGE project definition in CastleEngineManifest.xml files).
TODO: extremely fragile when unit on uses clause not found
I know about that, but I think that is just how CodeTools works.
Confirmed and agreed. My previous statement (that it's a specific issue of your fork) was an error. Testing, confirms that both LSP servers (your's and Ryan Joseph) are equally "fragile" to missing units on uses clauses, and actually Lazarus IDE is equally "fragile". So it is a problem in CodeTools, outside of LSP servers.
<details>
What I did for testing:
-
I opened CGE unit https://github.com/castle-engine/castle-engine/blob/master/examples/creature_behaviors/code/gamestatemenu.pas .
-
I tested my forks that add simple CGE support ( https://github.com/michaliskambi/pascal-language-server-genericptr , https://github.com/castle-engine/pascal-language-server ) -- this just results in adding a bunch of
-Fuxxx,-Fixxxto FPC options. I tested also Lazarus IDE 2.2.2. -
If I edit the
TStateMenu.Startto sayButand try to complete...begin inherited; ButtonPlay.OnClick := {$ifdef FPC}@{$endif} ClickPlay; ButtonQuit.OnClick := {$ifdef FPC}@{$endif} ClickQuit; // Hide "Quit" button on mobile/console platforms, where users don't expect such button ButtonQuit.Exists := ApplicationProperties.ShowUserInterfaceToQuit; But end;-> this works great. It says to me that it can complete
ButtoButtonPlayorButtonQuit. -
But if I now mess up the
usesclause, adding there non-existent name...uses CastleApplicationProperties, CastleWindow, GameStatePlay, Foobar;-> now completion completely fails.
Butcannot be completed to anything. Which is a shame, it would be better IMHO if CodeTools would just ignore the missingFoobarin theusesclause.Testing your fork with Emacs lsp-pascal, it is explicit about the reason:
Company: backend company-capf error "Wrong type argument: list-or-vector-p, #s(hash-table size 1 test equal rehash-size 1.5 rehash-threshold 0.8125 data ("items" [#s(hash-table size 2 test equal rehash-size 1.5 rehash-threshold 0.8125 data ("label" "Line 45: unit not found: Foobar" "insertText" ""))]))" with args (candidates Butt)Testing Ryan Joseph fork -- it is silent about the reason, but there are no completions for
But. So it also fails, just without any useful message, which is actually worse.Testing Lazarus IDE -- it fails, clearly saying that it cannot find
Foobarunit.
</details>
Ryan Joseph advantages: Passes extra FPC params from LSP initialization options. This is a clean way to pass FPC options from any LSP client.
That feature would be trivial to add, it was just not needed until now. Feel free to open a MR.
Happy to hear you're open to this.
I'll be experimenting to see whether I prefer in long-term to pass to LSP server "FPC options" or a single "Castle Game Engine path". The latter (single CGE path) is easier to use -- it means you just set 1 path -- though it is a CGE-specific customization then.
Doesn't read stuff from Lazarus config, doesn't need Lazarus config location -- it seems better to not read it if we don't need it
That may be a misunderstanding. My fork does not need the Lazarus config, either. It can use it, which is purely for convenience. But you can also specify all of the paths manually, either by sending initializationOptions or by setting environment variables.
Thank you, and I agree after understanding this feature. It's an extra feature in your fork, not a disadvantage.
I have updated https://github.com/michaliskambi/elisp/tree/master/lsp to reflect my new knowledge.
I propose to limit this issue's scope now to resolve: why Lazarus IDE is better at finding LCL units (like Laz_AVL_Tree) than both LSP servers. I'm interested can this be improved (and it if implies the need to read LPI / LPK in LSP server, or something else).
Isopod
Hi, I saw that you forked my LSP fork. I just wanted to address a few points you made here:
That should not happen, I don't have that issue on any of my machines.
I know about that, but I think that is just how CodeTools works. The same thing happens in the Lazarus IDE: Whenever there's a missing unit and you try to invoke code completion, instead of showing you candidates, the editor jumps to the erroneous line.
That should work already. I suspect that there is a problem with your config if it can't find LCL units.
That feature would be trivial to add, it was just not needed until now. Feel free to open a MR.
That is true. My fork hasn't been very active lately for two reasons: 1. It already does 95% of what I need. 2. I'm not doing any Pascal development at the moment. However, that does not mean that development has to stop. Others are welcome to contribute. It is open source for a reason. I'd be happy to review any merge requests.
That may be a misunderstanding. My fork does not need the Lazarus config, either. It can use it, which is purely for convenience. But you can also specify all of the paths manually, either by sending initializationOptions or by setting environment variables.
It would surprise me since both forks use CodeTools under the hood. However, I'll admit I don't know much about CodeTools and the documentation is sparse to non-existent. If there is anything I could do differently, I would love to know.
Again, I'm open to contributions. Even if it is just a bug report. Please don't be shy to open an issue if you find a problem or have a suggestion.