Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove suggestion about extensions/syntax-hightlight #39

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

avivace
Copy link
Sponsor Member

@avivace avivace commented Jan 7, 2022

See discussion in #35

@ISSOtm opinions?

@avivace avivace requested a review from ISSOtm January 7, 2022 00:06
@ISSOtm
Copy link
Member

ISSOtm commented Jan 7, 2022

It is rarely the case that highlighters have specific support for Z80, let alone RGBASM.

Then, either there is specific support and it can be overridden (e.g. Sublime or VS Code's language choices), or either element is missing, in which case you should still be getting a fallback, which is still much better than absolutely no highlighting. (Even just dimming comments goes a long way.)

@pinobatch
Copy link
Member

It is rarely the case that highlighters have specific support for Z80, let alone RGBASM.

The use case I imagine is "I use the same user account on the same PC to develop software for Game Boy and software for Master System, ZX Spectrum, MSX, or the Mega Drive audio CPU." In my personal case, it is Master System software. If I install a highlighter for the union of instructions recognized by the Game Boy CPU and instructions recognized by the Master System CPU, where .z80 represents "the entire 8080 family (hence '80') using Zilog syntax (hence 'z')", it's less bad than applying x86 or ARM rules.

Then, either there is specific support and it can be overridden

That's why I filed #35, so that if we do end up keeping "don't use a file extension meaning 'Zilog syntax for 8080 family'", the guide can cite instructions on how to override it in Sublime Text, Visual Studio Code, and GtkSourceView-based editors.

@ISSOtm
Copy link
Member

ISSOtm commented Jan 7, 2022

The use case I imagine is "I use the same user account on the same PC to develop software for Game Boy and software for Master System, ZX Spectrum, MSX, or the Mega Drive audio CPU."

I understood that, but my argument is that it's largely uncommon, and that it is subject to other constraints such as being viewed on GitHub, which has decent support for .asm but none for .z80.

If I install a highlighter for the union of instructions recognized by the Game Boy CPU and instructions recognized by the Master System CPU, where .z80 represents "the entire 8080 family (hence '80') using Zilog syntax (hence 'z')", it's less bad than applying x86 or ARM rules.

Of course, but that 8080-family highlighter may simply have a higher priority for .asm than x86 or ARM. It was certainly the case for me when I was using Gedit.

That's why I filed #35, so that if we do end up keeping "don't use a file extension meaning 'Zilog syntax for 8080 family'", the guide can cite instructions on how to override it in Sublime Text, Visual Studio Code, and GtkSourceView-based editors.

Listing editor-specific instructions doesn't sound like a good idea to me, as we'd have to maintain all of them and possibly add more. Shouldn't a generic mention be sufficient?

@ISSOtm
Copy link
Member

ISSOtm commented Jan 7, 2022

Regardless, while I disagree with removing the paragraph, I agree it should at least be reworded.

@avivace
Copy link
Sponsor Member Author

avivace commented Jan 7, 2022

Regardless, while I disagree with removing the paragraph, I agree it should at least be reworded.

I agree the z80 confusion should be clarified, but the paragraph (in the current status) does it badly:

  • It implies syntax-highlighter will get it right when .asm or .s is used, which is actually not really different from how wrong is the z80 syntax
  • It tells you that you should "help" to not spread a false information . This is out of scope and quite confusing (mostly right, but not quite)

This should just be explained in a clearer way, distinguishing the two concepts, avoiding smiles, etc. Let's just ditch the current version and propose something new

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants