Full support for Multi-root?

[Tolik-Trek]

Hi, again)))
Is there any plan to support this functionality?
References are counted correctly, but hovers do not work between different folders.

[maziac]

Could you be more specific. To my understanding multi-root should be supported.
What is your expectation and what is not working?

[Tolik-Trek]

Could you be more specific. To my understanding multi-root should be supported.
What is your expectation and what is not working?

I'll show you video)))
https://1drv.ms/v/s!AgBSFvvzba7RgfAcojGnUe5AQsGCdg?e=uogHI1

[maziac]

OK, could you maybe paste the full path of the 2 workspaces here.

[Tolik-Trek]

OK, could you maybe paste the full path of the 2 workspaces here.

1:
/Users/tolik/Library/CloudStorage/[email protected]/Мой\ диск/Progs/ASM/GIT/Testings
2:
/Users/tolik/Library/CloudStorage/[email protected]/Мой\ диск/Progs/ASM/GIT/SP_EXE

[maziac]

OK, it seems the there the problem is that reference work through workspace boundaries. That shouldn't be the case.

[maziac]

Could you please try this fix here.
I had to refactor a lot because I found that the vscode code lens providers were not behaving as I thought.
So, also all the other functionality might be affected. I did some testing and for me it looks fine.
But please don't hesitate to report any problem.

asm-code-lens-2.1.0-rc1.vsix.zip

Every workspace folder should only show hovers, references etc. of its own and not from other workspace folders.

[Tolik-Trek]

Every workspace folder should only show hovers, references etc. of its own and not from other workspace folders.

Why?
Conversely, if a directory is added to the workspace, then the labels, hovers, references etc. should be counted and displayed all together, as if all these files from different directories are in the same root directory - Multi-root.

[maziac]

Why? Mainly because I use it that way :-)

I think if you group projects in a workspace you group related projects but not necessarily dependent projects.
When doing assembler you are probably not working with libraries or such things but just with you assembler files that are limited to your project, i.e. folder.

Imagine you would use the same labels in different (not related) projects: why should a label of project A appear in project B?

[Tolik-Trek]

Imagine you would use the same labels in different (not related) projects: why should a label of project A appear in project B?

Because otherwise I would not add folders from other projects to my main project)))

I use it like this:
I have several folders with different projects for one target machine. And there is one shared folder that is used in each project, it is called "shared_includes", it has a bunch of macros, Lua scripts, definitions, bios and dos function names, different ports and system variables - everything that is needed for each project. And this folder is constantly replenished, information is added, something is corrected. And every time after editing, changing these common files in each project is inconvenient and easy to get confused. And if the Multi-root worked as a combination of two different folders into one working one, then this would solve all the problems. Can you make an option to choose how to handle labels if there are several different folders in the project? I really like asm-code-lens, I do not want to refuse it)))

[maziac]

I understand your use case but I'm not sure how to handle that.
Lets assume you have 3 projects:
Project A and B being 2 independent main projects.
Both share code from a Project C. E.g. a workspace folder that just contains macros or subroutines.
The files from C are included in the asm sources of A and B.

Lets say there is a subroutine set_sprite in C.

If asm-code-lens would collect all labels from all folders it would show the the hovers correctly, e.g.
a hover on call set_sprite in A (or B) would show the description of set_sprite.

But I see several problems:

1. references: If you do a "Find all references" on call set_sprite in A it would also show all references to call of set_sprite in B.
   Although I would expect only to see the references for project A.

2. If both, project A and B, define the same label, e.g. very common labels like "main" or "start" or "pause", then there is a clash.
   I.e. 2 same labels with different meanings, different addresses. Probably different descriptions.

The multi root workspace has no concept of dependent projects. I.e. All projects, A to C, are seen on the same level. It is not possible to tell that A and B should be treated differently but C should be treated as common to both.

So even with a setting I would not know how to handle it.

But for your problem:
Have you ever tried to work with symbolic file/folder links?
You could add a symbolic link in each project that uses your shared project. So you wouldn't have to copy anything.

[Tolik-Trek]

But I see several problems:

1. references: If you do a "Find all references" on call set_sprite in A it would also show all references to call of set_sprite in B.
   Although I would expect only to see the references for project A.

If you have two workflows:
1 - A and C
2 - B and C
then you have no problems.
If you want to use A with B and C, then you can turn off the "Find in all Multi-root" option))))

The multi root workspace has no concept of dependent projects. I.e. All projects, A to C, are seen on the same level. It is not possible to tell that A and B should be treated differently but C should be treated as common to both.

So even with a setting I would not know how to handle it.

in the previous version of ASM-CODE-LENS, after activating Multi-root, links are displayed like this:
0 reference | 2 references
Too nice if first number for label in file from project A, and second for label in Multi-root.

But for your problem: Have you ever tried to work with symbolic file/folder links? You could add a symbolic link in each project that uses your shared project. So you wouldn't have to copy anything.

Yes, now i use it, but all my projects in cloud. I coding at home (windows) and at my work (MacOS). MacOS understands google drive's symbolic links (inside cloud), but windows is not, windows sees the *.lnk files...

[maziac]

But I see several problems:

If you have two workflows: 1 - A and C 2 - B and C then you have no problems. If you want to use A with B and C, then you can turn off the "Find in all Multi-root" option))))

What do you mean by workflow?
If A, B and C are in the same workspace I would see the references to B if I use 'find all references' in A. which shouldn't be the case.
If I'd turn off these kind of multi root with some setting then I don't see the references at all.

in the previous version of ASM-CODE-LENS, after activating Multi-root, links are displayed like this: 0 reference | 2 references Too nice if first number for label in file from project A, and second for label in Multi-root.

What about the next problem:
You have project D, D is using labels of project E. All, A to E, are in one workspace.
Now, it happens that E and C use the same label names.
Where to jump to for "Goto definition" if selected in D.

You also silently ignored my 2nd problem :-)
If both, project A and B, define the same label, e.g. very common labels like "main" or "start" or "pause", then there is a clash.
I.e. 2 same labels with different meanings, different addresses. Probably different descriptions.

[Tolik-Trek]

What do you mean by workflow?

if you open one folder with a project, it's just a project. if you open one folder, and then add a folder to this project from another location, then this is a workflow.

If A, B and C are in the same workspace I would see the references to B if I use 'find all references' in A. which shouldn't be the case. If I'd turn off these kind of multi root with some setting then I don't see the references at all.

Multi-root - it's for convenience. If the user tries to use this option to shoot himself in the leg - that's just his problem)))

What about the next problem: You have project D, D is using labels of project E. All, A to E, are in one workspace. Now, it happens that E and C use the same label names. Where to jump to for "Goto definition" if selected in D.

You can jump to first found definition, that's the user's problem if they want to use it that way.

You also silently ignored my 2nd problem :-) If both, project A and B, define the same label, e.g. very common labels like "main" or "start" or "pause", then there is a clash. I.e. 2 same labels with different meanings, different addresses. Probably different descriptions.

May be you can show several different values of all this same labels in hover, or show "error!!!!!111" in hover)))

Why do you think this functionality (multi-root) was added? I think that, just in order to be able to combine two different projects (or a project and a folder with shared files) and work with them as one. The user must understand what it is for and not complain if he himself used it for other purposes.
in the previous version (0 reference | 2 references) was very close to correct behavior.
I communicate with you through Google translator, I'm sorry if my idea is not always clear or something sounds rude or harsh)))

[maziac]

Please note that I moved this issue now into the discussions area.

For anyone else reading this:
The main discussion here is about how asm-code-lens should handle the multi root scenario:
a) (2.1.0 behavior): Each workspace folder is treated separately. Labels form workspace folder A are not seen in workspace folder B.
b) As one big project: all labels from the other workspace folders are seen in each workspace folder.

[maziac]

Ok, so "workflow" is probably a translation error. I guess you mean a vscode "workspace". One workspace contains several projects /workspace folders.

If the user tries to use this option to shoot himself in the leg - that's just his problem)))

Unfortunately not. It's also mine, as I got the (wrong) error reports.

You can jump to first found definition, that's the user's problem if they want to use it that way.

And how to jump to second definition? This would just randomly pick a definition.

May be you can show several different values of all this same labels in hover, or show "error!!!!!111" in hover)))

Does not sound convincing to me.

Why do you think this functionality (multi-root) was added? I think that, just in order to be able to combine two different projects (or a project and a folder with shared files) and work with them as one

I don't think so.
For vscode, projects are organized in folders, that's it. You can combine them to workspaces, e.g. you might combine a client app and a server program in one workspace. That does not mean they share one other project in the workspace.

Anyhow, I will check if I can add some setting.
For the not-working scenarios, that I mentioned, the user could also organize the projects differently.
E.g. for the A, B and C project (with C being the shared one) the user doesn't have to put of all of these in one workspace but could work with 2 workspaces:

• workspace 1: with project A and project C
• workspace 2: with project B and project C

with this setup project A and B would not interfere.

Would this also suit your requirements?

[Tolik-Trek]

Ok, so "workflow" is probably a translation error. I guess you mean a vscode "workspace". One workspace contains several projects /workspace folders.

Yes)

And how to jump to second definition? This would just randomly pick a definition.

counterquestion:
I have one workspace folder with 3 files - core.asm, drv1.asm and drv2.asm. Core have something like that:
IF target_system
include 'drv1.asm'
ELSE
include 'drv2.asm
END

drv1 has EQU with BIOS = #100, drv2 has BIOS = #200
What will show on hover? Where will he jump on click?

Anyhow, I will check if I can add some setting.

Thanks a lot

For the not-working scenarios, that I mentioned, the user could also organize the projects differently. E.g. for the A, B and C project (with C being the shared one) the user doesn't have to put of all of these in one workspace but could work with 2 workspaces:

• workspace 1: with project A and project C
• workspace 2: with project B and project C

with this setup project A and B would not interfere.

Would this also suit your requirements?

YES YES YES YES YES)))))))))))

[maziac]

What will show on hover? Where will he jump on click?

That is a valid point. ASM-Code-Lens does not do any compilation, nor does it go through includes etc.
Actually what I have written before is not correct: it does not randomly pick a definition but it offers both location to the user before it jumps to it.
Here is an example of what would happen:

But if it is in one and the same project it still makes some sense.

The point is (to stay in the picture) project B would be shown as a location for project A although both projects are unrelated.

YES YES YES YES YES)))))))))))

Please give me some time to work this out.

[Tolik-Trek]

Please give me some time to work this out.

Thank you for your hard work and dedication :)

[Tolik-Trek]

Asm code lens is broken in the new VSC update ((((((

[maziac]

All my extensions are broken with 1.74. There is a change in vscode. I'm looking for it.

[maziac]

I looked at the code to see how I could implement this. But there are more problems:
There are e.g. workspace folder options to exclude files.
Different ws folders of project A and B could have different settings.
Which one should be used to exclude files if files are considered for both?

This could be solved by using the exclude settings from A for folder A and exclude settings from B for folder B.
Complicated, but doable.

Then for the "label excludes": same problem here, but here it is not so clear if label excludes from A should work on files from B or if label excludes from A should only work on A.
For the latter case it will become difficult to implement as currently this is not checked when grepping the files but at a later stage, so that it's difficult to filter here.

So, I think I have to disappoint you. The feature is quite difficult to implement and I also believe that it will be hard for the user to understand what is going on if settings get mixed between the workspace folders.
This in turn will result in errors (even if these are "wrong" errors I have to spend valuable lifetime for it).

I guess it is better to "keep it simple". I.e. keep it as it is (i.e. the 2.1.0-rc1 I attached some time ago.)

[Tolik-Trek]

I looked at the code to see how I could implement this. But there are more problems: There are e.g. workspace folder options to exclude files. Different ws folders of project A and B could have different settings. Which one should be used to exclude files if files are considered for both?

I think the best way is to exclude all files from settings A and from settings B for a multi-root workspace.

Then for the "label excludes": same problem here, but here it is not so clear if label excludes from A should work on files from B or if label excludes from A should only work on A. For the latter case it will become difficult to implement as currently this is not checked when grepping the files but at a later stage, so that it's difficult to filter here.

Just like with files. Let's assume that 2 (or more) folders in Multi-root are subfolders of the same workspace root folder and their settings are one settings file, any collisions are cancelled. These rules are simple and easy to understand.

So, I think I have to disappoint you. The feature is quite difficult to implement and I also believe that it will be hard for the user to understand what is going on if settings get mixed between the workspace folders. This in turn will result in errors (even if these are "wrong" errors I have to spend valuable lifetime for it).

😭😭😭😭😭