Take into account global "files.exclude" setting for finding code

[Chadehoc]

In my company, some units exist in two versions under the root directory. One is in a special folder, that is never seen nor compiled (it's a kind of template used by internal tools). Unfortunately, code completion proposes the wrong version's methods (class names are the same).

The directory with the code to be ignored is in my global files.exclude and search.exclude lists (in settings.json). I think that if some directories are listed there (especially files.exclude), they should be ignored as well when searching for code completion items.

[Christopher Wosinski]

I have seen this also in other projects. I guess the Delphi IDE and compiler don't get confused by duplicate files because

• the wrong files are not inside the search path
• or the correct files are added to the project.

By now, the search path contains

• the folder opened in VSCode including all its subdirectories
• the folder defined in objectpascal.delphiInstallationPath and all its subdirectories
• the folders listed in objectpascal.searchPath

That setting is quite good when there are no duplicate files or when you just want to have a look at the sources of a project. There is no need to create a complex configuration to get started working with the sources inside your workspace. That's intended in order to keep the lightweight feeling of VSCode and OmniPascal. But of course, there are downside when projects become complex and contain duplicate files. Today there is no way for OmniPascal to deal with it properly.

In the future it will be possible to open project files. OmniPascal will load the search path from that file in order to implement Delphi's original behaviour as close as possible. I don't think you need files.exclude in that case.

[Chadehoc]

I don't think you need files.exclude in that case.

This kind of directory will always be in files.exclude and search.exclude anyway, because I cannot imagine why one would want to let them exist for other VSCode tools.

The current search path seems quite good to me indeed. I hoped the idea of reusing the existing settings variables (to be excluded from the OmniPascal search path too) was simpler than relying on an OmniPascal specific configuration, or on a dedicated handling of duplicates.

Currently I can live with regularly removing the spurious directory after it gets regenerated...

[Christopher Wosinski]

Do you still have trouble with duplicate files when you open a project in VSCode?

[Chadehoc]

Do you still have trouble with duplicate files when you open a project in VSCode?

Yes, I just tried (updating VsCode and OmniPascal), F12 still brings me to the bad definition file (the one that is excluded from search).

[Christopher Wosinski]

So you used the new load project feature and OmniPascal is still resolving to the wrong units? That's not good. I guess it's working in the Delphi IDE, am I right?

Is it possible to attach the DPROJ file to this ticket and name me the folder of both the correct and the incorrect unit?

[Chadehoc]

So you used the new load project feature

Sorry, you did mention "open a project" but it didn't hit me that it was a new feature! I just reloaded the project as a directory, and tested again.

I will try this load project feature and let you know.

[Chadehoc]

The load project feature works badly for me, or I didn't find how to use it properly. Any way I tried it, F12 does not work any longer at all after loading a project.

Details:

• The load project command (via Ctrl+Shift+P) does nothing, unless I close VsCode and freshly open the folder. Just then, il brings a selection box listing some projects. For example, if I close VsCode and reopen it, in the same configuration the load command does nothing visible.
• It doesn't list those projects that are open in editors (.dproj files).
• I have to freshly open the folder, focus the editor with the .dproj file, and then it appears in the box and I can select it.
• Now, F12 does not work at all, but I cannot check the project was correctly 'opened'. The 'current project' seems to appear nowhere. Ctrl+Shift+P brings the command, but does nothing, not even recall the currently open project. So I'm not sure which part was wrong. Sorry.

[Christopher Wosinski]

The load project command (via Ctrl+Shift+P) does nothing, unless I close VsCode and freshly open the folder. Just then, il brings a selection box listing some projects. For example, if I close VsCode and reopen it, in the same configuration the load command does nothing visible.

I've noticed the project picker doesn't show up all projects until OmniPascal has finished creating an index of all files in the entire search path. That's a bug for sure. Please try this when the project doesn't show all projects:

• Open the task manager
• Look for the CPU usage of OmniPascalServer.exe and wait until it's going down to zero
• Try to load a project again. Does it work now?

It doesn't list those projects that are open in editors (.dproj files)

It should list the projects placed in the current workspace only. For the moment it does not list .dproj files but .dpr and .dpk files.

Now, F12 does not work at all, but I cannot check the project was correctly 'opened'. The 'current project' seems to appear nowhere. Ctrl+Shift+P brings the command, but does nothing, not even recall the currently open project

The status bar shows OmniPascal: No project loaded initially. After a a project has been loaded successfully it displays the name of the current project file. If it still shows OmniPascal: No project loaded then anything has gone wrong. What happens when you open the project's .dpr file after loading the project? Are there red lines marking the project's main units (I'm talking about the uses entries containing a path such as MyForm in 'Source\Forms\MyForm.pas')? Can you jump into that files with F12?

[Chadehoc]

Please try this when the project doesn't show all projects

Yes, that was it. It was very long (minutes) but we have almost 200 projects under that folder. It was by chance that those I was trying to open were found in the end of the process.

The memory use reported for OmniPascalServer.exe is more that 167M in the end.

The status bar shows ...

Ah yes, on the right, I had overlooked this one.

Opening the loaded dpr shows no particular red lines (what do you call "main units" ?) and F12 still doesn't work. But this is a unittest project listing almost 5000 units. Maybe the codebase size goes beyond this feature's capabilities? F12 in folder mode was very quick but had that duplicate units problem.

[Christopher Wosinski]

It was very long (minutes)

Ugh, that's too much. How many files (of any file type) do you have in the search path? Over 100k?. Do you see general speed issues with your HDD?

The memory use reported for OmniPascalServer.exe is more that 167M in the end

Memory consumption is an issue. For the next months we have to accept that. Sorry.

what do you call "main units" ?

I don't know the correct term for it. Here's a sample:

uses
  Forms, // <-- this unit is used in the project
  MainForm in 'Frontend\MainForm.pas' {MainForm}, // <-- this unit is part of the project. 
    //The uses entry contains the path to the .pas file. I call it a "main unit"

F12 still doesn't work. But this is a unittest project listing almost 5000 units

Wow, that's huge project. When you place the cursor in one of those 5000 uses entries and you press F12 then nothing is happening? Could it be that OmniPascalServer.exe is just busy working with such a big file? Maybe it is just responding late?

[Chadehoc]

How many files (of any file type) do you have in the search path? Over 100k?

Well, over 50 Gb and 400000 files (including excluded folders, e.g. binaries, dcu, etc.)... Yes, huge code base, huge projects, and many of them. (On a SSD.)

It may be that the folder-only version of OmniPascal is enough for such cases, since it was quite responsive. Maybe it's not worth working this out for exceptional needs (or just excluding the excluded folders). Also, using VsCode instead of the Delphi IDE was an idea because I'm fed up with the IDE, but it makes sense to use it anyway because debugging is only available there... I'm not sure I'll keep juggling using both.

So you may forget it, unless you want to use my exceptional case as a benchmark opportunity (then you're welcome).

[Christopher Wosinski]

400k files are a lot. I thought to work in a huge project (~100k files in the search path) but that's just awesome.

So you may forget it

No! I want OmniPasal to become the best way for Delphi developers to work with their code base. It will take some time to achieve this goal. I need to work more on performance in huge projects.

However, I have no idea what's going on with F12 after loading a project. The latest release of VSCode displays a message when F12 was unable to find the location saying "No definition found for XXX". Does this message appear when you hit F12 on a unit name after loading a project? Does it appear also without loading a project?

[Chadehoc]

Sorry for the late answer.

• With no project loaded: F12 running shows a grey "Loading..." idle mouse tip. The first attempt takes minutes, but eventually finds the unit (the bad one if I keep the duplicates). If I F12 a inexistent token, I get a "No definition found" blue tip. Following attempts are quick. (I wonder if some background loading takes place before the first F12, because I remember it to be responsive when I was working "normally"; here F12 was my first action after loading the folder.)

• With a loaded project: The "Loading..." tip seems to last forever (meaning more than 1 hour).

No! I want OmniPasal to become the best way for Delphi developers to work with their code base.

Cheers! However, I fear you should have an idea about how to handle debugging in the future. I turned back to the Delphi IDE because I had to be working on both VsCode and IDE anyway, and the inconvenience overcame the benefits of a better editor.