Ticket #1633 (new enhancement)

Opened 15 years ago

Last modified 4 years ago

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.

Change History

comment:1 Changed 15 years ago by ralesk

  • Cc ralesk@… added

comment:2 Changed 14 years ago by andrew_b

#1984 is a special ticket for syntax.d implementation.

comment:3 Changed 7 years ago by andrew_b

  • Blocked By 1984 added
  • Branch state set to no branch

comment:4 Changed 4 years ago by ossi

this has some conceptual overlap with the discussion we had in #2118.

Note: See TracTickets for help on using tickets.