Leaderboard

Andreas Hausladen. Obones and and a few others have been quite active in maintaining JCL/JVCL. Although, there are no recent releases the recommended installation procedure involves using the GitHub master. See https://github.com/project-jedi/jcl for details. JCL/JVCL support all Delphi versions including the most recent ones. There have been tens of commits fixing warnings and minors bugs over the last few months (https://github.com/project-jedi/jcl/commits/master) There are masses of gems in both JCL and JVCL that are still worth using in production code.

Hi Anders, Partially my fault, I initially thought it was the save action until I saw that it wasn't and it was in fact the close. YESSSS!!!!!! All good now. I disabled the 3 LiveBindings libraries and now the save/close all takes around 10 seconds. :-) Having now done that, I seem to recall a similar thing a couple of years ago. Note to self - Disable LiveBindings when any new Delphi comes along. Thanks Anders, and to all the other contributors. Regards, Ian

Sorry. Didn't read your description properly. I thought it was the save that was slow. I've encountered projects that took a long time closing but I can't remember what I did to solve it. I don't know if Live Bindings can affect close performance like they do open. One of my clients has a project where one of the datamodules has almost 200 datasets and thousands of persisted fields. Before I disabled Live Bindings there it took in the neighborhood of 15 minutes to just open this datamodule. Now, with Live Bindings disabled it takes less than a second. Anyway, you can easily get a call stack of the Delphi IDE with Process Explorer. Double click bds.exe, view threads, double click the thread with the highest CPU usage. That should give you (or us, if you post the call stack here) a clue about what it's doing.

LiveBindings are a toy, at best, anyway. So don't worry about disabling them.

Put madExcept in the IDE via a package and then use madTraceProcess to find out what it is doing whilst saving.

Pfft! You did ask for opinions, did you not? For me the use case would be that I'm either looking for TODOs or I'm focused on something else. If I'm looking for TODOs then the existing functionality is just fine. If I'm focused on something else then I'll read the comments anyway and I don't need the extra distraction.

The CPU sitting at 13% probably means that something is using one core at 100%. So I would not subscribe to this view: Have you tried to disable all IDE extensions to check whether it is caused by one of these?

No. With LSP tools like VS Code and many other editors will offer error insight, code completion and some other services for Pascal language. But this: When (if?) these plans become reality other IDEs will be able to offer debugging for Pascal language. IDEA with I-Pascal already supports LLDB. I hope the language support in LLDB will be better than in GDB otherwise debugging experience will resemble one from Lazarus.

As @Markus Kinzler has pointed out with his announcement, there is a revised roadmap for RadStudio available at: https://community.idera.com/developer-tools/b/blog/posts/rad-studio-roadmap-may-2019 Your two cents may find a home right here 😉

Worth watching for insights into the value of a language server:

"...a single Language Server can be re-used in multiple development tools, which in turn can support multiple languages with minimal effort." In theory it would divorce the Delphi language from the Delphi IDE. This would allow for Delphi code completion and other features to be accessed from tools such as VS Code, Eclipse, Sublime Text and anything else implementing the protocol and enable supporting additional languages in the Delphi IDE. In theory. I can't shake the feeling that Embarcadero will find some way to lock things down. But the idea is really great and I've been advocating for this since the concept was first revealed by Microsoft and Red Hat.

Of course, I'd be ecstatic otherwise 😉 Concerning the language server complex, I recommend starting in our very own thread on that subject:

Also post with comments from product management https://community.idera.com/developer-tools/b/blog/posts/may-2019-rad-studio-roadmap-commentary-from-product-management

In case of lack of authority, proceed with slapping until the desired level is achieved. 🙂

Hi, I think it would be fantastic to have a delphi language server. https://langserver.org This would open delphi to many editor and IDE (present and future). What do you think about ? Renaud

I just discovered this project: https://github.com/CWBudde/DWScript-Language-Server

Is it possible to write a language server in Delphi/Pascal, or should it be written in languages such as Java, JavaScript, TypeScript? BTW ErrorInsight was written in J# (correct me if I'm wrong), and it was a bad decision. Well I see the language server plugins for C/C++ written in C++, D plugin written in D, Dart Language Server written in Dart etc...

I agree that an open source Language Server would be desirable. Omnipascal looks great and even offers the ability to compile Delphi projects now. Someone else wrote a form designer prototype for VSCode. Put all the pieces together and we almost have a portable IDE with VSCode. A language server would enable other IDEs to support the ObjectPascal language and enable EMBT to rip out ErrorInsight, and other parsers in the IDE. if they made use of it. If EMBT used an open source language server, the community could evolve and improve it over time rather than relying on EMBT. As a separation of concerns, it would also make it easier to get a cross platform IDE working, or multiple IDEs on different platforms. If you write code on OS/X and target only Apple devices, it would be nice not to require a Windows VM, or a PC as well. A language server might enable the use of XCode (not sure if it uses language servers) for ObjectPascal development. At some point, a language server could enable Delphi developers to just use the command line compilers, and RTL to target their platform of choice with their editor of choice, and UI framework of choice. https://github.com/alefragnani Seems to have done some work along this line.

Given that I doubt we will ever see a fully repaired IDE, the language server would be a boon, were it not for the issue of a form designer. The notion of using a CSS-like solution reminds me of the Regex joke: I had a problem, but solved it with Regex. Now I have three problems.

.dfm and .fmx design is a delphi specificity and for sure will be never managed by LSP. However, I wish that one day we replace the .fmx with a css like. It would be a lot more standard and powerful. But that's another debate.

Yes. Depends of the IDE, but for instance with i-pascal and IntelliJ you can configure the delphi compiler. http://www.siberika.com/img/run/compile.gif

As far as I understood it, if a language has a language server you can load that language in the IDE (if such a feature is supported by the IDE). Like using Visual Studio and it's IDE features but with the Delphi language. Is my assumption correct?

The hard reality is that delphi ide is old and really buggy. If we compare it to Intellij... No comment. Currently, I use the plugin i-pascal for intelliJ (not perfect but far better than delphi for code navigation) Omnipascal is also very good. It is precisely to avoid rewriting a plugin for each IDE that the language server is existing. A delphi langage server will bring with one implementation, a support with majors editors / IDE or next gen web IDE as Eclipse CHE.

If you haven't watched this before it might make it a bit clearer what it means to have modern compiler architecture and what benefits you get from it (like not having to implement everything twice for compiling itself and for tooling):

As far as I understand, this would serve as a "bridge" from Object Pascal code - via "LangServer" - to IDEs that support "LangServer stuff". The page lists example IDEs such as Emacs or VS Code. The latter already has an excellent plug-in OmniPascal.