YAML cannot be overriden like other file formats.
I went through large hurdles to implement docker-compose syntax highlighting. My problem was that I could not override the YAML file format. It seems that the main problem is that the build-in file "filetype_extensions.conf" needs to be edited, to comment out one row: #YAML=*.yaml;*.yml; otherwise it is not possible to override YAML filetype.
How to reproduce : You may see the steps necessary to make the docker-compose work in [https://wiki.geany.org/config/docker-compose%5D(https://wiki.geany.org/confi...), and if you change anything you will either break the syntax highlighting of the docker-compose or of any yaml-file which is not a docker-compose.
I get a nagging suspicion that what is called YAML in the built-in "filetype_extensions.conf" is something that cannot be overriden. Can it be a built-in from Scintilla, which is impossible to override?
You need to "unmap" YAML in *filetype_extensions.conf*. What you should do is in the *user's* `filetype_extensions.conf` add a `YAML=` line that does not include the extensions you want somewhere else.
The technical reason for this is that the system and user's files are merged, with the user's one overriding the system ones. Then, they are currently (this is NOT something to rely one!) matched alphabetically, so the first occurrence wins, and it happens that `YAML` sorts before `YML`. So if you just add the extensions to `YML` but don't remove them from `YAML`, the `YAML` match still wins. Arguably the user's file maybe should be tried first, and the system one only if the user's one didn't match, but for now it's not the case, and you should then make sure to unmap the extensions you want to reuse. It should be as easy as re-defining the offending line for it not to include these extensions.
That was an impressively fast reply!
Can you explain to me why the YAML format remains in the menu, even when I commented it out in the built-in filetype_extensions.conf? This was one reason I suspected some other hardcoded mechanism I can’t override
Skickat från min iPhone
23 juni 2019 kl. 23:48 skrev Colomban Wendling notifications@github.com:
You need to "unmap" YAML in filetype_extensions.conf. What you should do is in the user's filetype_extensions.conf add a YAML= line that does not include the extensions you want somewhere else.
The technical reason for this is that the system and user's files are merged, with the user's one overriding the system ones. Then, they are currently (this is NOT something to rely one!) matched alphabetically, so the first occurrence wins, and it happens that YAML sorts before YML. So if you just add the extensions to YML but don't remove them from YAML, the YAML match still wins. Arguably the user's file maybe should be tried first, and the system one only if the user's one didn't match, but for now it's not the case, and you should then make sure to unmap the extensions you want to reuse. It should be as easy as re-defining the offending line for it not to include these extensions.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
You are correct that YAML is a built-in filetype, and as such can't be removed, but you can make your YML named filetype and map the file extensions to that instead of the YAML filetype as @b4n explained.
Thanks a lot for the replies. I have updated my dockerfile-dockercompose filetype in the wiki from your suggestion, which worked great. It resolved having to change installed files.
CURRENT ISSUE ==============
As I understand, it there are two things that I have missed. I wonder if they can somehow be improved or documented (pardon me if I missed them being documented).
- YAML cannot be removed, and is hard coded as a filetype. Is this really necessary? If necessary, it would be great to document what filetypes are hard-coded and locked. Also, the solution to zero it out (’YAML=' in user config) would be great to point out.
- 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?
SUGGESTION ============
This could be submitted as an additional issue, but I add it in this one if you don’t mind, since they are related.
One thing which I believe would make it even better is the following : Either add the new filetypes that people have put up on the Wiki to the default installation, or make it easy to add them for a novice. Things like the Dockerfiles are in much greater demand today than some of the other INCLUDED file types, but Geany is probably quickly skipped by people developing for Docker, since Dockerfiles don’t work out of the box.
Would it be possible to add a filetype plug-in interface, where missing filetypes are downloaded from some repository or just from an URL. What would be needed for such a function is to place the filetypes.xxx.conf into the user filedefs folder, and to amend the user filetype_extensions.conf. The latter may of course have a minimal change of causing conflicts, but can be resolved manually from the Tools/Configuration files menu
Again, thanks for the prompt replies and the great work you are doing. I really love Geany, and it has been my standard editor for decades.
/Jan
24 juni 2019 kl. 02:45(:17.000) skrev elextr notifications@github.com:
You are correct that YAML is a built-in filetype, and as such can't be removed, but you can make your YML named filetype and map the file extensions to that instead of the YAML filetype as @b4n https://github.com/b4n explained.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/geany/geany/issues/2205?email_source=notifications&email_token=AG7S4VU42IY4KXIPF7JHXY3P4AKJ3A5CNFSM4H2Z2CFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYLLC3Y#issuecomment-504803695, or mute the thread https://github.com/notifications/unsubscribe-auth/AG7S4VX46O46UM2NJLZ7LP3P4AKJ3ANCNFSM4H2Z2CFA.
- YAML cannot be removed, and is hard coded as a filetype. Is this really necessary? If necessary, it would be great to document what filetypes are hard-coded and locked. Also, the solution to zero it out (’YAML=' in user config) would be great to point out.
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](https://www.geany.org/manual/current/index.html#custom-filetypes).
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.
oops, hit comment too soon :)
Either add the new filetypes that people have put up on the Wiki to the default installation, or make it easy to add them for a novice.
Somebody just needs to make one or more PRs.
Would it be possible to add a filetype plug-in interface, where missing filetypes are downloaded from some repository or just from an URL. What would be needed for such a function is to place the filetypes.xxx.conf into the user filedefs folder, and to amend the user filetype_extensions.conf. The latter may of course have a minimal change of causing conflicts, but can be resolved manually from the Tools/Configuration files menu
At the moment the syntax highlighting lexers and the symbol parsers are C++ and C code (respectively) compiled into Geany, so those can't be added at runtime.
It would be possible to make them be loaded as plugins, but its a big job, and will need a lot of hard coded configuration to be changed to be modifyable from the plugin or a configuration file. And somebody has to contribute it.
Regarding order in determining filetype and pattern :
I looked at the linked PR, and found this one : 2166 (https://github.com/geany/geany/pull/2166 https://github.com/geany/geany/pull/2166). That seems to be a solution to the problem I had.
Regarding plug-in system for adding filetypes :
I do not ask you to swap in/out hard coded compiled C++ and C parsers.
I think the use case which I and many others have, is to add a filetype through adding a filetypes.xxx.conf file in the user directory. These are not touching the compiled C++ and C parsers, but they use them.
My thought, which I sensed from the replies were not understood, is that new filetypes do not conflict with the build in syntax highlighters at all. Reason being, that me and many others have created new filetypes that can be manually installed into the user folder, but requires you to realize that they are actually available at the Geany Wiki.
I believe that some mechanism to introduce a new language filetype would be feasible, since the installation procedure would be exactly the same as for manual downloading, putting things in the correct folder and editing filetype_extensions.conf.
My thought was that an easy way to select new languages (filetypes) would benefit Geany with more users.
Thank you for your time and help, and if there is something I can do myself more than adding the docker-compose and editing the Dockerfile filetypes to the Geany Wiki I would gladly help. Problem is that it seems too daunting to learn how to do this.
Thanks again. If you wish you can close this issue. Do you want me to make another issue suggesting this plug-in of new filetypes ?
/Jan
24 juni 2019 kl. 12:12 skrev elextr notifications@github.com:
oops, hit comment too soon :)
Either add the new filetypes that people have put up on the Wiki to the default installation, or make it easy to add them for a novice.
Somebody just needs to make one or more PRs.
Would it be possible to add a filetype plug-in interface, where missing filetypes are downloaded from some repository or just from an URL. What would be needed for such a function is to place the filetypes.xxx.conf into the user filedefs folder, and to amend the user filetype_extensions.conf. The latter may of course have a minimal change of causing conflicts, but can be resolved manually from the Tools/Configuration files menu
At the moment the syntax highlighting lexers and the symbol parsers are C++ and C code (respectively) compiled into Geany, so those can't be added at runtime.
It would be possible to make them be loaded as plugins, but its a big job, and will need a lot of hard coded configuration to be changed to be modifyable from the plugin or a configuration file. And somebody has to contribute it.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/geany/geany/issues/2205?email_source=notifications&email_token=AG7S4VR7YIBIU5PWDQE5MJDP4CMXRA5CNFSM4H2Z2CFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYMOL6Y#issuecomment-504948219, or mute the thread https://github.com/notifications/unsubscribe-auth/AG7S4VXASBWNU2AHDLSVEFDP4CMXRANCNFSM4H2Z2CFA.
github-comments@lists.geany.org