None of the built-in filetypes can be excluded, they are built in to the code, so somebody will have to add code to exclude that code based on some other config file. That should be raised as a separate issue, not hidden in this one.

Most current filetypes are built-in, and the way to tell is that built-in ones have configuration files (in the filedefs directory) called filetypes.xxx and custom ones have configuration files called filetypes.xxx.conf as documented here.

Custom filetypes can be excluded by simply removing the conf file (and entries in filetypes.extensions to avoid looking for non-existant filetypes).

The search order for the rules are as pointed out by Colomban a bit random, and it would as Colomban wrote make great sense if the user-setting always overrides the default. Can this be implemented?

The filetypes.extensions is more complex than it seems. In some ways its backwards, it specifies filetypes and lists patterns, but what actually happens is patterns are matched to select the filetype, but since patterns can overlap the only unique key is the filetype name, so that has to be the key.

But the user config file entries replace the system config file entries by the filetype name key, that means you don't have to have all filetypes in your user file, only the ones you want to change, and so other filetypes will still get extension lists upgraded when Geany is upgraded, if you put every filetype in your user file you would never see updates with Geany.

This means that the "effective" mapping is a mixture of user and system entries. I don't think the system keyfile library that does this can indicate if its a user or system entry.

Patterns must be tested one at a time, and at the moment the first match wins, and its not known if thats a user or system entry, and as @b4n said the order that takes place is implementation defined and not documented. There is a PR #2167 to change "first match wins" to "longest match wins" (at the cost of testing all patterns every time) which, if it is accepted, would remove any order dependency.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.