- changed status to open
Take into account global "files.exclude" setting for finding code
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.
Comments (13)
-
repo owner -
reporter I don't think you need
files.exclude
in that case.This kind of directory will always be in
files.exclude
andsearch.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...
-
repo owner - changed status to on hold
Do you still have trouble with duplicate files when you open a project in VSCode?
-
reporter 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). -
repo owner 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?
-
reporter 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.
-
reporter 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.
- The load project command (via
-
repo owner 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 showsOmniPascal: 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 asMyForm in 'Source\Forms\MyForm.pas'
)? Can you jump into that files with F12? -
reporter 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. -
repo owner 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?
-
reporter 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).
-
repo owner 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?
-
reporter 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 firstF12
, because I remember it to be responsive when I was working "normally"; hereF12
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.
-
- Log in to comment
I have seen this also in other projects. I guess the Delphi IDE and compiler don't get confused by duplicate files because
By now, the search path contains
objectpascal.delphiInstallationPath
and all its subdirectoriesobjectpascal.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.