 |
 |
 |
If you use Visual Studio Code, we have a new manual page for you and an LSP server distributed and tested with Castle Game Engine that provides a perfect Pascal code completion.
Most important link
Read everything here: Visual Studio Code with Castle Game Engine.
What is an “LSP server”
LSP (Language Server Protocol) is a protocol to define code tools functionality (e.g. code completion) in a way independent from the text editor.
- Multiple text editors can act as LSP clients, e.g. VS Code (where the LSP originated), Emacs, Neovim.
-
They can access any LSP server. There are lots of LSP servers, in particular there are a few suitable for Pascal.
What I did
I was having some fun exploring the options and I actually got to work 2 LSP servers targeting Pascal: Philip Zander (Isopod) LSP server and Ryan Joseph (genericptr) LSP server. They both use Lazarus CodeTools underneath.
I then modified them (both) adding some CGE-specific features and testing how to make them perfect. I wanted to have it all — support for VS Code (which I know many people like), Emacs (which is my favorite text editor), out-of-the-box support to complete code using CGE API, working everywhere (I tested both Linux and Windows).
- We had a few conversations with Philip Zander (thank you a lot for all the information how everything works and being open to my PRs!), I made our fork with Castle Game Engine enhancements, I submitted some PRs back: #1, #2, #4.
-
I also made a fork of LSP server from Ryan Joseph and submitted PR #33.
My forks add support for additional configuration using INI file and you can make LSP servers trivially aware of CGE paths this way. The details of my additions are in README files on both LSP servers.
Note: Both the above LSP servers actually come from initial Arjan Adriaanse work (though, after 3 commits, it seems he didn’t maintain it further) on github.com/arjanadriaanse/pascal-language-server.
Finally, I gathered a lot of notes and links about existing options to use LSP with Pascal.
Making it easy to use
As a last step, I made the setup as easy as possible to use:
- Our LSP server is just packaged along with CGE downloads from today. If you download CGE, then you also download an LSP server we advise.
-
I tested it with our bundled FPC. CodeTools need to access newly added
fpc-cgewrapper. -
I documented everything about VS Code integration (LSP server and more) as a nice manual page.
This was a lot of integration work 🙂 And it’s not finished! A lot of pieces can be improved and/or it can be made to work more out-of-the-box. It is possible we’ll have our own Castle Game Engine extension for VS Code one day. It could take care of LSP, help with debugging and running CGE projects from VS Code, maybe more?
Stay tuned 🙂 Do you like this? Please support our work.
Did you try OmniPascal - Open Preview - Visual Studio Marketplace ?
It seems to be a standalone server, rather than extension of Delphi Alexandria or Lazarus
Would you continue the FPC-centered path this would perhaps be a disadvsantage. But now that you seem to be trying to be D/FPC agnostic, then perhaps starting with initially neutral approach would have its benefits?
Thank you, added to TODO to test.
Note that the current Pascal LSP we recommend on Visual Studio Code | Manual | Castle Game Engine is not tied at runtime to Lazarus at all. You don’t need to have Lazarus installed. Internally that Pascal LSP just uses some code from Lazarus CodeTools, but this is something relevant only when you need to recompile that Pascal LSP server. When it’s compiled already (as we provide with CGE precompile
pasls[.exe]binary) you just use it, and it works – it doesn’t require existing Lazarus or Delphi installation.( It still needs to know the units for which it performs completion. So e.g. it needs to know FPC sources, otherwise it will not be able to understand even the most basic Pascal usage of stuff from
SysUtils. I wonder how they solved it with https://www.omnipascal.com – maybe they allow you to point to both Delphi or Lazarus RTL. I’ll test. )BTW, i had to do a little of VSCode + Python and…
I miss TP’s debuger hotkeys.
F4 - run to the current line.
Maybe i am missing the obvious, but i only found a temporary breakpoinr workaround. Meh…
Also it hurts that i can not press F4/F7/F8 (Step Into, Step Over) right out of editor to start debugging.
Well, in Lazarus F7/F8 de facto do not work too. But at least F4 works.
Debugging command line apps… well, breakpoints help, but in Delphi one can just to start immediateky with F7 (and even trace units initialization sections, really miss it in Laz
)
But back to VSCode, seems there is no way to trigger debugger run by “Step Into” and friends
The “temporary breakpoint” ( Use breakpoints in the debugger - Visual Studio (Windows) | Microsoft Learn ), which is breakpoint occuring once, is indeed the closest we have to TP “run to the current line” (F4). I suppose you can extend VS Code to do both operations (“set a temporary breakpoint + run a task”) in one go, see e.g. VSCode Macros - Visual Studio Marketplace – but I didn’t delve into that.
As for step-into / step-over not automatically running the debugger – indeed. I’d propose to ask on VS Code communication channels,
https://github.com/microsoft/vscode/blob/a044e57b0760ed2c16b97db619267c823024dbae/CONTRIBUTING.md
Newest 'visual-studio-code' Questions - Stack Overflow
There’s big community of people using VS Code, and your question isn’t CGE or Pascal specific, so there’s a good chance you’ll get a useful solution from general VS Code community.