Ticket #1633 (new enhancement)
New syntax and extension configuration
Reported by: | ralesk | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | Future Releases |
Component: | mc-config-ini | Version: | master |
Keywords: | config configuration ext syntax | Cc: | ralesk@… |
Blocked By: | #1984 | Blocking: | |
Branch state: | no branch | Votes for changeset: |
Description
Currently, syntax and ext configuration is done by having a single, long file with many entries in it; if you want to add something, you have to patch this central file and if something changes in upstream, you end up having to port a jillion tiny patches to get it to work again. And upstream does change :)
So, here's a new idea:
Let's split Syntax (as in the central Syntax settings file) and mc.ext into small chunks and put those in separate files into a subdirectory. So for example ext/ in MC's share dir. MC will then slurp those files in alphabetic order, and keep that configuration in memory. For extra coolness: if inotify (or something similar) is available, alter configuration when a file changes.
So, basically if MC doesn't by default have an ext setting for PDF files, I can drop a file called anything into ext/ (common sense would say I'd call it "pdf"), and it would contain the ext rules for PDF files. If I want to override MC's built-in rules, I could either patch the upstream pdf ext file, or drop in something that comes earlier in the alphabet, like 00-pdf. Similarly, if I want to add CSS highligh support, I'll drop a "css" file with the Syntax setup into syntaxrules/ and add a css.syntax to the highlighters/ directory or something.
This has the benefit that a distro, doing distro-specific things or having additions that haven't been accepted to upstream yet, can easily have a bunch of additions in these directories without needing to worry about upstream breaking hundreds of patches; and modifications are also smaller and less prone to break.
Also, the syntax of the Syntax and mc.ext files does not need to get changed and the syntax highlighter rule files (*.syntax) are unaffected by this.
The drawback is, of course, that this needs to be coded and it takes a bit of time to chew through all those files.