Georgge Bakh

A bit of static analysis should be enough in that case.

I have no idea what is the difference for an IDE are units included in .dpr or not. But what is the purpose of including in uses clause of a .dpr units which are not actually used in that file? What if a unit become shared between projects (i.e. become a library)? Should it be removed from .dpr?

Again, I didn't stated that it's simple. I know that dealing with broken code is hard. But it should be a code tools developer problem. Not users.

I didn't say that dependency cycles are a good thing. I trying to avoid them myself. But it is not always possible due to lack of a bigger visibility scope than unit. But I still think that code tools should not break or slow down with unit dependency cycles. And I know what I'm talking about as writing pascal code tools is my current pet project.

Honestly, I see no reason why these things should cause slowing down or breaking of code tools. Code tools must work regardless of code style used.

I think you can do it right here. Also there is a Facebook group "delphi developer" and a section at russian firemonkey community: http://fire-monkey.ru/forum/77-ищу-подрядчика/

For development it's still free even for commercial organizations. https://www.oracle.com/technetwork/java/javase/overview/oracle-jdk-faqs.html But you always can install free version (Oracle's OpenJDK) from here: http://jdk.java.net/

Some time ago I sold shareware games (written on Pascal btw) and used Plimus to receive international payments via cards. Now its site redirects to bluesnap.com and seems this company does the same thing even cheaper. And there are many other companies which you can use to receive payments. Most of them can provide all necessary papers for companies/corporations.

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.

I-Pascal v2.0 has been released. What is I-Pascal? It's a Pascal language support plugin for IntelliJ IDEA. Integration with Delphi and Free Pascal Compiler. The main goal of the project is to provide modern code editing and inspection tool for Pascal language. Dependency cycles ready. In the new release: Completion options from not used yet units (with automatic modification of uses clause) Completion itself is improved and not is comparable to one for Java Delphi 10.3 inline declarations syntax support. Highlighting, find usage, renaming etc. No inherited destructor call inspection Project site: http://siberika.com/ Installation instructions: http://siberika.com/install.htm Source code: https://github.com/casteng/i-pascal

Just uploaded a new version. Now it supports "introduce variable" refactoring, parameter to field binding and other features. Change log with animation: http://siberika.com/whatsnew.htm

I think IDE should support version control systems integration. Delphi has it at some basic level. I use IntelliJ IDEA as Pascal IDE and do most Git operations within the IDE as it comes with very good integration of various VCS including Git.

Yes, when someone from "outer world" comes to Delphi ecosystem IDE is the first thing to be discouraged with. Because there are many serious problems indeed. It's a good idea to take an existing high quality and extensible IDE and use it as a base for new Pascal IDE. I think it's much better than try to extend Delphi IDE with plugins. The base platform should be designed with many things in mind: indexing, threading, data integrity, real time code analysis, cross platform to name a few. UI is also an important (and often underestimated!) part. On the other side I see no reason to recreate a form designer. It's good enough in Delphi (or Lazarus). What's about a language server - it's good to have to bring Pascal support to many editors at once, but it's not a way for first-class IDE.

Did you know that this Java IDE can do the same thing for Pascal code too? After installing a plugin for Pascal support of course.

I-Pascal highlights unused local identifiers in real time. Whole project can be inspected as well by "Analyze->Inspect Code..." menu option. It really can save some time preventing bugs getting into the code on early stage. So I think this is a must have feature for a modern IDE.

Is it just an ordinary identifier usages list?

With dependency management done right libraries will become simpler, easier to maintain and of course more uniform.

I'd say in Free Pascal as such tool should be crossplatform and work for FPC too.

Very good initiative! The absence of dependency manager is a big problem of Pascal ecosystem. Not only CI scenarios suffers from it but library developers - there is no option to make a library dependent on another library as it become too complicated for most people to install and use it. So most libraries have *commons.pas units which contains pretty same purpose routines and classes. I thought about it a lot and the only reason why I not started such a project is that I believe it should be a community effort. Or we'll end up with another package manager without packages and users. I'm familiar with Maven from Java ecosystem and it does it's job well. Some quick thoughts: I see no much sense binding it to a particular IDE or even compiler. Let it work for FPC too! Components and packages are good but libraries are also good and much easier to manage. I think such a tools should have a command line based core with plugins for IDEs when needed. In that case CI server will be able to build project from scratch as it should be. Simple workflow - a project config file at input and a directory structure with library/package files at output. A package can be identified with an ID - something domain name-like works good here and partially solves problems with copyright etc. Please no GUIDs here! To identify a dependency seems to enough: (ID, version, compiler/platform, type) type is source or binary (dcu/ppu). Therefore, to use a library it's needed to create a config file and run the tool. After it ends its work there is a ready to use directory structure with all needed files and maybe even compiler config file with paths.

Seems that using the new language feature breaks the parser. And all functionality which depends on it become broken as well. Use I-Pascal for code editing/refactoring until Delphi will catch up. Inline declarations are supported although I don't like this feature.

Delphi as a platform has it's strong points (VCL, debugger, language, ...) but its IDE is not the one. It lacks capabilities of modern IDEs for code analyzing and editing. These features can save a lot of time. Fortunately there are alternatives which can be used together with Delphi: VSCode and IDEA both supports Pascal.

Did you uninstall/install again the IDE? When I first installed 10.3 CE it always (almost) hung on opening any project. After uninstall and install again the problem gone. I think it's worth to be included in manual.:)

Not advocating dependency cycles but sometimes these are justified. For example when a big subsystem is separated to several units. These units will probably need each other as it's still a single subsystem and there is no higher level grouping for units with appropriate visibility rules. And of course it's not a reason for any of IDE features not to work.

For example, some third unit3 used TClass1 from the unit1 from which we moving TClass1 to unit2. In order to keep the code correct we need to update unit3 accordingly.

Will all code which used the entity also be updated automatically?