Vim syntax highlighting for ca65 assembly

[thenendo]

Just a note to say that I've posted my home-grown Vim syntax highlighting module for ca65 to github:
https://github.com/maxbane/vim-syntax-asm_ca65

Perhaps others may find it useful. Heh, and now I've just doxed myself on the nesdev forums

[koitsu]

I'd find this *super* useful, except I hate having to maintain a separate ~/.vim/ directory with added syntaxes or plugins. :\

So that said: after some time of it being out there and tested, etc. do you plan on submitting it to Bram so it can be included in vim officially?

[thenendo]

Yeah, would love to submit it for the Vim runtime once it's stable for a bit. Glad to hear it would be useful!

I know what you mean about ~/.vim, though with Tim Pope's Pathogen, I find it reasonable to maintain... and I'm so dependent now on some plugins that will probably never make it into the runtime distribution, like NerdTree.

[koitsu]

One thing that I noticed from perusing the code is that there's inconsistent use of hard tabs vs. spaces throughout the code (sometimes even on the same line), making it difficult to read. The file uses a modeline of ts=8, but it doesn't appear that is actually maintained consistently throughout the file. It looks like (based on some of the other stock syntaxes) that whitespace should be used. :set list is useful here. :-)

Attached is a diff against master which cleans all that up (I find git format-patch confusing, not to mention I couldn't get it to work today for whatever reason, probably user error).

I'd also love to see bge/blt opcode aliases (for bcs/bcc) added since they're so incredibly common, but yeah I know ca65 only enables use of those by default in 65816 mode (which makes absolutely no sense, because those aliases aren't 65816-specific. That's a ca65 annoyance though and not your fault, but still...)

[thenendo]

One thing that I noticed from perusing the code is that there's inconsistent use of hard tabs vs. spaces throughout the code (sometimes even on the same line), making it difficult to read. The file uses a modeline of ts=8, but it doesn't appear that is actually maintained consistently throughout the file. It looks like (based on some of the other stock syntaxes) that whitespace should be used. :set list is useful here.

Attached is a diff against master which cleans all that up (I find git format-patch confusing, not to mention I couldn't get it to work today for whatever reason, probably user error).

Thanks for pointing this out; yeah, I started out by making modifications to the stock asm.vim, which used a mixture of tabs and spaces (shudder), and I neglected to continue doing so consistently. I've now turned everything into spaces, as you suggest.

I'd also love to see bge/blt opcode aliases (for bcs/bcc) added since they're so incredibly common, but yeah I know ca65 only enables use of those by default in 65816 mode (which makes absolutely no sense, because those aliases aren't 65816-specific. That's a ca65 annoyance though and not your fault, but still...)

So here's a bigger question... should this syntax module just support all of ca65's instruction mnemonics for the various CPUs that it supports? How would you feel about a buffer-local variable (e.g., b:asm_ca65_cpu="65c02") that the user can set on a per-file basis (with a modeline or a filetype autocmd) that determines which mnemonics get highlighted?

Also, while persuing the ca65 source code, I noticed that the set of illegal instruction mnemonics supported by ca65 is actually larger than claimed in the documentation. Compare the list starting at line 215 of instr.c to the list in the documentation. Which set do think it makes sense to highlight? Maybe the discrepancy is something to file as in issue with the cc65 project.

[tepples]

instr.c calls $8B (unstable) "ANE", while opcodes02 (cited by the documentation) calls it "XAA". So it's a documentation issue that ought to be reported.

[koitsu]

So here's a bigger question... should this syntax module just support all of ca65's instruction mnemonics for the various CPUs that it supports? How would you feel about a buffer-local variable (e.g., b:asm_ca65_cpu="65c02") that the user can set on a per-file basis (with a modeline or a filetype autocmd) that determines which mnemonics get highlighted

I imagine some would find this useful, but I'm perfectly fine with how it is now. In short, I'd say worry about that if/when (the feature request) presents itself. :-)

Also, while persuing the ca65 source code, I noticed that the set of illegal instruction mnemonics supported by ca65 is actually larger than claimed in the documentation. Compare the list starting at line 215 of instr.c to the list in the documentation. Which set do think it makes sense to highlight? Maybe the discrepancy is something to file as in issue with the cc65 project.

My suggestion would be to not bother with illegal instructions, but that's also because I'm highly biased against them in general. There is also (AFAIK) no "universally agreed-upon" set of mnemonics for those opcodes -- Tepples listed a couple, but there are more than just that. But I suppose it does make sense to implement the names that ca65 uses internally (the docs being wrong should be fixed too, maybe file a ticket on that; I don't know where/how ca65 is maintained at this point as the cc65.org domain says the author gave up maintaining it in 2013 and I couldn't exactly figure out where the "real" home page is now).

If you do implement the illegal instructions per ca65 naming scheme, I would politely suggest making the opcodes some different colour -- red comes to mind (or if it were me, I'd be going with white bolded text on red background).

[tepples]

the docs being wrong should be fixed too, maybe file a ticket on that; I don't know where/how ca65 is maintained at this point as the cc65.org domain says the author gave up maintaining it in 2013 and I couldn't exactly figure out where the "real" home page is now

The real home page is http://cc65.github.io/cc65/

If you do implement the illegal instructions per ca65 naming scheme, I would politely suggest making the opcodes some different colour -- red comes to mind (or if it were me, I'd be going with white bolded text on red background).

I'd recommend putting the most useful ones in one color and less useful ones (those that involve S, (PC>>8)+1, or line noise) in another color.

[thenendo]

If you do implement the illegal instructions per ca65 naming scheme, I would politely suggest making the opcodes some different colour -- red comes to mind (or if it were me, I'd be going with white bolded text on red background).

OK, so for now, I'm highlighting just the illegal opcodes listed in the ca65 documentation, and they receive the "Special" highlight group, which is different than the "Statement" highlight group that the normal mnemonics receive (what color this is rendered as of course depends on your colorscheme)... I thought about using the "Error" highlight group (they are illegal after all!), but decided that's too extreme, as most people expect that to indicate actual syntax errors.

I've also added an auto-indent plugin and a filetype plugin. Since I've now gone beyond the scope of just syntax highlighting, the github repo is now just vim-asm_ca65 rather than vim-syntax-asm_ca65

See the README.md (or github page) for the full feature list.