search

13xforever / x86-assembly-textmate-bundle

A bundle for TextMate/Sublime Text providing syntax highlighting for x86 assembly code.
MIT License
82 stars 24 forks source link

vscode Language id is too generic & overlap's with other (different assembly syntaxes) [vscode] #20

Closed osterhoutan closed 3 years ago

osterhoutan commented 3 years ago

The Problem

You have opted to use the very non-descript string asm as the id for the language you are contributing.

But since "asm" is just short for assembly and needless to say there is a different assembly for syntax for every architecture, and often multiple syntax standards for different assemblers/standards.

So it is ambiguous, which is not such a great thing.

I recognize that even if you and everyone else who is using asm as the language id in vscode for their chosen assembly syntax, there would be still be ambiguity in that the file extensions would still have overlap, but this isn't that big of a deal since you can manually change the language of an open file.

Which really only makes the overlap even worse since now the only way to change which extension is offering the language server, is to either only have one of the extensions enabled, or hope that one of the extensions using the contributing the asm language id, allow you to configure which language server to use (not likely). And this is not a good solution since it only allows one to be active per "workspace".

The Solution

Change your language id and name to be more descriptive like x86-nasm-yasm/x86nasmyasm for the id and "x86 Assembly (nasm/yasm)" for the name (might be useful to call it my the common name for the general syntax family (aka intel syntax). So something like intelx86 and "Intel x86 assembly syntax family", or something like that anyway.

It might also be useful to contribute multiple languages (in the same extension) to separate nasm and yasm from each other, but that is far more dependent on your implementation.

And on vscode you don't really need to advertise support for at least gas since it belong to the gnu/at&t assembly syntax family and the support really isn't all that great, since they are very different from the intel syntax family, and there are extensions specifically for them on the platform.

note:

I am leaving similar issues on the repos of other offending extensions, so that this issue can be a thing of the past.

13xforever commented 3 years ago

Should be fixed with version 3.0.0