Redesign #2

[maziac]

The current implementation searches all *.asm unstructured, i.e. it does not look for dependencies like 'include'. This also makes the implementation quite messy.

It would b emore structured to define just for sjasmplus (maybe a new vscode extension) and set the main asm file in the settings. Then build a tree of dependent files. Watch all files and re-read if changed. (Would be also faster). Collect all labels. Would be always correct because MODULEs could be understood also above file boundaries.

CompletionProvider: The completion item provider could simply provide all labels. vscode would then only show the ones which fit with the input.

[ped7g]

JFYI: if you do sjasmplus file1.asm file2.asm it assembles them in the order of appearance on the command line "as if" both files were concatenated, i.e. you can "include" some header files without include just by putting them into the same assembling command ahead of the "main" file. (it's not clear from your comment, if you are accounting for this feature, basically you need to be aware how the project is build, i.e. parsing Makefile/etc, which seems to me like too much, so maybe your plugin can have some field where user can list all files forming the single build-unit)

[maziac]

Thanks for the hint. I could also use this (sjasmplus file1.asm file2.asm) for configuration but the problem is that every time you add a file you also have to add it to the asm-code-lens configuration. If you forget it asm-code-lens will show no completion proposals.

Actually I have no real good idea how to go on here, so maybe I never do this redesign. Currently asm-code-lens just greps everything that looks like a label and provides it as completion. The advantage is: there is no configuration needed and it also works without any assembler. The disadvantage is: It might also grep some non-label stuff. (BTW the labels without "." make it here also more difficult to grep :-) )

But it seems it works "good enough" as it is currently, so I don't see any urgent need for the re-design at the moment.

[ped7g]

I personally use something like "main.asm" which does include anything else, so explicit parsing of include directives would work for me well enough.

[maziac]

I close this issue. The current approach (simply grepping all assembler files, unstructured) has the big advantage that it does not depend on a certain assembler. And ASM-Code-Lens is meanwhile used by a lot of x86 users. So I think it's best to keep the current design.