Custom filetypes are customisations using existing filetype capabilities so no coding is needed.

Couple of problems with your attempts,

1. you create a `filetypes.awk`, but as the manual says about [custom filetypes](https://www.geany.org/manual/current/index.html#custom-filetypes) the file should be `filetypes.Xxx.conf` where Xxx is a case sensitive filetype name. The `filetypes.xxx` ones are built-in and need code support within Geany. Perhaps look at the existing custom ones such as `filetypes.Scala.conf` and see how they relate to the underlying build-in filetype, eg Scala to C. 2. you added `*.awk` to perl, which as I said elsewhere tells Geany that awk files are perl, not what you wanted. The original addition defining a new `Awk` filetype to extension mapping is the right one, but without the `Awk` matching a filename as above being right it won't work, as you found. 3. The `[groups]` stuff tells Geany where to put the custom filetype in the stuffed to the gills filetypes menu, probably needed.

There is a `filetypes.perl` but no `filetypes.Perl.conf` because Perl is a __built-in filetype__, that is it is a base filetype, hard coded into Geany, and not dependent on any other filetype. Its not a custom filetype that depends on another built-in filetype.

For each hardcoded filetype, Geany has code that looks for a `filetypes.xxx` as the filetype is used by a file, but for custom filetypes it searches for all `filetypes.*.conf` files at startup and creates filetypes for each one it finds, so nothing needs to be coded in Geany. The custom filetypes files have a different form from the built-in ones so the built-in ones are not found again by that search since they are in the same directory.

Not sure what `filetypes.conf` is for, I can't find anywhere that Geany reads it, but looking at its history it seems to be intended to be a template for built-in filetypes, maybe, but its not clear??? Anyhow as its not loaded (AFAICT) and not referenced in the documentation so just forget it until someone else can explain its usage (anybody?).

I have looked in filetypes.perl for some hint as to which lexer it uses

Perl is built-in so the lexer choice is hard coded, so nothing is needed in the filetypes file, same for tags parsers. For Perl the lexer [is this](https://github.com/geany/geany/blob/master/scintilla/lexilla/lexers/LexPerl....). The easiest way of telling which lexer/parser a built-in uses should be the filename in this directory, or in the ctags parsers directory.

Lexers come from the [Lexilla](https://github.com/ScintillaOrg/lexilla) and unfortunately their documentation is their code, so properties and numbers of keyword lists need to be gleaned from their code, or for custom filetypes by reading the base filetype file which _should_ be updated if needed every time the lexer is updated.

# Edit these in the colorscheme .conf file instead

See [here](https://github.com/geany/geany-themes)

Before colour schemes were invented the mapping between lexical entities and styles was in the filetypes files, where the comment is, now the filetypes files map lexical entities to named styles and the colour scheme file maps named styles to colours. The intention is that similar entities in all languages would map to the same named colour so users of multiple filetypes would get similar colouring, and colour schemes wouldn't have to have mappings for each filetype, but of course anybody can (mis)configure it in their custom filetype file for their language or the user override for the builtin filetype file.

which .conf I should perhaps start with?

The manual suggests copying the builtin filetype file and adding the `lexer_filetype` and `tag_parser` keys whose value is the builtin filetype name. That will copy the right number of keyword lists and lexical element to named style mappings, but they will override any changes that happen in the builtin in future Geany releases. Or as explained [here](https://www.geany.org/manual/current/index.html#reading-styles-from-another-...) you can get them from the builtin, and then only change ones you actually need to, thats probably preferable.

Custom styles, colour schemes, and various other changes have happened over a long period of time, not all at once, and manual updating is done by the people doing the changes, who totally understand their change, so are brief in the manual and only note their part and not the whole. Also contributors do not always speak English as a first language so again they are brief.

A full tutorial or howto on creating custom filetypes and configuring the filetypes system would be good, but Geany is a totally volunteer project, nobody is paid to do anything, and nobody can be forced to do anything, and so most contributions are things people are capable of, are interested in, or find useful for themselves. So far nobody has seen fit to contribute such a document or to improve the manual.

Generally looks ok.

In your `filetypes.Awk.conf` you are missing the `[keywords]` header from before `primary=....` so thats likely why it doesn't work.

The `filetypes.awk` will be ignored and is useless, you can delete it.

Is `@load` a valid Perl keyword? Remember the lexer is still Perl. I didn't look at its code, but it almost certainly does not use the wordchars list for deciding whats a legal keyword, at least most lexers don't let Geany set that. I think `@something` is a variable in Perl, but its been a long time.

Just a hint, to see what style number the lexer assigns to characters you can add to the status bar template in various preferences (%Y IIRC but RTFineM for details).

And that's the problem; the manual merely gives hints, without revealing much e.g. [https://www.geany.org/manual/current/#statusbar-templates%5D(https://www.gea...) . So going to Edit > Preferences > Various > interface.statusbar_template and changing text 'scope' to 'cope' and [Apply] ... does nothing (and I believe that I have followed the manual's instructions - I tried both [Apply] and [OK] buttons); it just ignores my change, which it sets back to what it was, even after restart. There is no indication or documentation (that I could find, that worked) on how to actually change either the statusbar_template, nor what might be an actual statusbar (is it different?).

I guess that we have differences on what the 'F' of RTFM stands for.

So going to Edit > Preferences > Various > interface.statusbar_template and changing text 'scope' to 'cope' and [Apply] ... does nothing (and I believe that I have followed the manual's instructions - I tried both [Apply] and [OK] buttons);

Did you press enter in the field to say editing is complete before you pressed ok?

It is the normal operation of the GTK UI toolkit that Geany uses that fields are changed when you press enter but actioned when you press OK. This is in compliance with the Gnome Human Interface Guidelines that GTK 3 implements. GTK has been evolving from the traditional GTK 2 desktop toolkit paradigm that allows multiple fields to be changed and actioned when "Ok" or "Apply" is clicked and the GTK 4 Gnome guidelines webby paradigm that allows individual fields to be changed and actioned and there is only a "Close" and no "Ok" or "Apply" on the dialog. Unfortunately GTK3 that Geany uses is a bit caught in the middle of that migration and has the above inconvenience.

I guess that we have differences on what the 'F' of RTFM stands for.

Compare to other IDE "manuals", even Eclipse which started out as an IBM commercial project and whose manual is huge, or Vscode which is MS backed. Neither explains basic GUI operation like text field entry (AFAICFind).

Geany is an open source project, feel free to contribute updates to the manual if you feel it is inadequate.

It's crazy, I know, but I was hoping that geany would allow customisation of things like wordchars and keywords. I

Geany is entirely dependent on what the lexers allow.

If only there was some feature like a configuration file for each file extension that allowed that.

The `filetype.xxx.conf` file you have been writing? It has the list of keywords, but its up to lexers what they test the keywords against, IIRC Perl keywords are just letters, so its not surprising that the lexer only accepts that.

The wordchars are used for things like word movements and selections, but can't be forced on lexers, which after all are for a specific language, and most languages don't have "words", they have keywords and identifiers and operators which are a fixed syntax for each language and its not surprising thats what the lexers hard code.

Thats why I keep saying the lexer is only going to be "close enough" when used for another language unless you are very lucky.

Closed #3232 as completed.