Currently there's very mild support for "asm" as a language type, but [the definition file](https://github.com/geany/geany/blob/master/data/filedefs/filetypes.asm) seems to just be partial support for Intel assembly.
I'd like to have better support for ARM assembly, but I'm not sure if people would be interested in that, or what it should be called, etc.
I think that the existing language definition should be renamed to `intel_asm` and then the new definition should be added as `arm_asm`, or something like that. On the other hand they both have file names with `.s` extensions so the editor would probably not handle that too well.
Thoughts?
You can create a [custom filetype](https://www.geany.org/manual/current/index.html#custom-filetypes) with armish instruction lists similar to the AVR one on the [wiki](https://wiki.geany.org/config/avr_asm).
The custom file types ability is somewhat confusing. Does this completely override a normal language file or does it use a normal language file and then apply the changes listed on top?
Also, the documentation says that custom file types are more limited and doesn't list [keywords] and [stylings] as a thing they can do, but the example linked does use keywords and styles. Is the documentation there simply out of date?
What am I missing out on with a custom filetype compared to an actual language file?
Does this completely override a normal language file or does it use a normal language file and then apply the changes listed on top?
It lets you create own new filetype, based on built-in lexers(highlighting) and parsers(symbols).
Is the documentation there simply out of date?
It's in the regular [filetypes documentation](https://www.geany.org/manual/current/index.html#filetype-configuration).
What am I missing out on with a custom filetype compared to an actual language file?
For something as simple as assembly, probably not much. If the assembly dialect had weird syntax (compared to "traditional" assembly) then some stuff might be mis-highlighted or show up wrong in the symbols sidebar.
The alternative is to write your own lexer in C++ and own tag parser in C and integrate it into the 3 related projects (Scintilla, Ctags and Geany).
Yeah I saw that section too. My question was more that the notes about how Custom Filetype files work say that they have a very limited set of features, and then the example uses more than the limited feature set suggested in the docs. So how limited are they actually?
I suppose either way I won't end up writing a full lexer in C++, so I'll have to use a Custom Filetype. I only work on the project this is related to about once a week, so it might not be right away.
Should I PR the custom filetype to this repo if I get something useful or is the wiki actually preferred?
The example is an example, that doesn't say it uses every feature available. Custom filetypes are mostly limited in that they can't have their own Scintilla lexer or ctags parser.
Custom filetypes should be put on the wiki, especially where you even cast doubts on the popularity yourself :grin:
Right, I'm not saying the example is bad. I'm saying that the docs say "you can only do X, Y, and Z with this", then the working example does _more_ than the docs said was possible. Which was the confusing part XD
But yeah, it's for my GBA development, which is a pretty small field these days.
Should I PR the custom filetype to this repo if I get something useful or is the wiki actually preferred?
If all the expected features work in the custom filetype, it adds value over using the default filetype, and is reasonably popular, it might be worth putting in core. There's no firm policy for what to add, it's just on a case-by-case basis I guess.
...especially where you even cast doubts on the popularity yourself grin...
...it's for my GBA development, which is a pretty small field these days...
I don't know if the dialect used on the GBA is the same with all ARM processors, but if so, it's not very niche. Basically every mobile/tablet has one, and they are used in all kinds of other devices, manufactured by a large array of vendors.
Probably _writing_ ARM assembly directly is niche, but the more common use case of viewing generated assembly is probably as strong a case as for any assembly dialect.
GBA is a standard ARMv4T architecture, which is basically just an older subset of modern ARM. It's all forward compatible, so yeah it'd work with any newer version ARM assembly as well.
https://en.wikipedia.org/wiki/Arm_Holdings#Sales_and_market_share
Yeah, I know how popular the ARM chip is.
It seems like the existing [Asm Lexer](https://github.com/geany/geany/blob/master/scintilla/lexers/LexAsm.cxx) uses the wrong kind of comment characters, the wrong concept of what's a word/wordstart, and is probably wrong in other ways I have yet to discover as well. It doesn't appear to be configurable via the `[lexer_properties]` section at all.
So, I guess I'll need a new lexer.
The lexers are part of the separate [Scintilla project](https://www.scintilla.org/index.html) which has all the docs on how to write them. Note that Geany uses Scintilla 3 not Scintilla 4 so you can't rely on anything thats not backported.
You should get your lexer accepted there first.
Sent in an issue, https://sourceforge.net/p/scintilla/feature-requests/1314/
Until then I'll mostly be able to live without proper comment support by just using a custom list of registers, instructions, and directives.
There's also another assembly lexer in Scintilla (but not used in Geany), I think for Motorola 68K, not sure if that's closer to ARM.
Unfortunately the biggest thing that I can't write myself is that multi-line comments should be supported, and 68k seems to also not have that concept.
I can probably modify `LexAsm.cxx` to get most of the little stuff fixed just fine, but I'll let them reply to the feature request before doing too much there.
I just poked the issue on the Scintilla tracker. Is there any progress here?
@Spivoxity from the comments from the OP above it seems that nothing much can be done until the Scintilla lexer is available so I'm not sure what "progress" you expect, or who you expect to progress it?
I would be happy to fix the issue myself, but don't want to duplicate the efforts of others.
Consulting my notes, it seems to me that the Scintilla lexer for assembly language could fairly simply be generalised so as to allow syntax details to be specified as configuration options. The result should be general enough to cover all variants of Gnu assembler, for example. I am particularly interested in ARM support, where the main issue is that comments start with @.
You might say whether the Geany project would accept such a change in principle, or whether it would have to come via Scintilla? The latter requires more bureaucracy, particularly because (at I understand it) Geany is pegged to a previous release of Scintilla to the current one. Is that right?
Generally Geany just loads Scintilla new releases with minimal changes (mostly related to removing Lexers that are not used). We are not experts in Scintilla internals. So its best to submit the changes to Scintilla. And also that way experts in Scintilla internals can peruse it.
github-comments@lists.geany.org