something like syntax.d for highlighting

[stronny at celestia dot ru]

From ​Debian bugzilla:

Seems like there is no easy way to add some syntax files to mcedit, as
the only file it parses on startup is
/usr/share/mc/cedit/syntax/Syntax (or ~/.mc/cedit/Syntax, which is not
relevant here). So if some package wants to provide additional
highlighting definitions, the only way to do it is to patch that file,
which is not very nice I think.

So I suggest there should be a directory (say,
/usr/share/mc/cedit/syntax.d) where should reside all *.syntax files,
so if any package wants to add another, it just places it there and
mcedit will find it next time it starts.

It should not be hard to do I think.

[zaytsev]

Please set forwarded bug status in Debian bugzilla when you report them upstream.

[yury_t]

The request is 3 years old. Let's try for another perspective on this:

There's no (easily discernible) way to include one's own Syntax rules in addition to the package's ('system') Syntax rules.

First thing, personal and package's Syntax are mutually exclusive: on Linux, either ~/.config/mc/mcedit/Syntax or /usr/share/mc/syntax/Syntax works, but not both.

Second thing, seems Syntax file cannot be included from another Syntax file. Trying to put into personal Syntax this...

file .\* refer to package's Syntax
include /usr/share/mc/syntax/Syntax

...effects in error on the first 'file' line in package's Syntax.

So: that's not a feature request, actually, that's configs not working as expected.

[andrew_b]

Let's discuss about.

Replying to stronny at celestia dot ru:

From ​Debian bugzilla:

Seems like there is no easy way to add some syntax files to mcedit, as
the only file it parses on startup is
/usr/share/mc/cedit/syntax/Syntax (or ~/.mc/cedit/Syntax, which is not
relevant here). So if some package wants to provide additional
highlighting definitions, the only way to do it is to patch that file,
which is not very nice I think.

Current implementation is simple and fast. In worst case, we read only two files:

1. Scan Syntax in order to find the syntax type. And
2. Read syntax highlighting rules from found xxx.syntax.

So I suggest there should be a directory (say,
/usr/share/mc/cedit/syntax.d) where should reside all *.syntax files,
so if any package wants to add another, it just places it there and
mcedit will find it next time it starts.

Let's consider how it should work.

To add or remove syntax file simply, we need to get rid of Syntax file because we don't want modify it every time. Obviously, in this case the syntax type descriptions should be moved to somewhere. Obviously, into xxx.syntax. Thus, each xxx.syntax file will include a syntax type description in addition to syntax rules.

In this case, when mcedit will start, the following actions will perform:

1. Open directory with a lot of syntax files.
2. Open syntax file file and find syntax type description.
3. If not matched, close file and goto 2 to read process file.
4. If matched, read syntax highlighting rules.
5. Stop.

In the worst case, we have to open all syntax files sequentially until we find proper syntax highlighting rules.

In general, I don't like an idea to read a lot of files at mcedit start time moment.

[zaytsev]

In general, I don't like an idea to read a lot of files at mcedit start time moment.

I'm not sure that I understand the premise. Can't we just read several Syntax files in order (user, system, built-in), and take the first matching xxx.syntax file (includes will be relative to the Syntax file, as it is now)? This means that we will open at most 3 files. It doesn't sound too complicated and the rest stays the same. I have to admit that I didn't get a chance to have a look at the code, so maybe I'm missing something.

[andrew_b]

Replying to zaytsev:

Can't we just read several Syntax files in order (user, system, built-in), and take the first matching xxx.syntax file (includes will be relative to the Syntax file, as it is now)?

No problem. The problem is the simplest way to add/remove syntax files (using package managers or just hands). The modification of Syntax is required in any case.

[ossi]

Replying to zaytsev:

I'm not sure that I understand the premise.

that's not how .d directories work. the idea is to make every syntax definition self-contained, so one can just drop in new files from different sources (packages). i.e., the file match patterns would have to be in the syntax files themselves.

the problem with this is of course that a) you still have to define the preference order somehow and b) that's a helluva lot of files to load just to know the patterns. one can use a cache to avoid actually reading every file, but usually you still need to stat() every file to know its last modification time to maintain cache coherency. to get around this problem, the xdg menu spec requires that _the directory_ containing the modified file(s) needs to be touched as well.

an easier approach for mc upstream is to defer to downstream ... they can assemble the Syntax file from as many pieces as they like, at package (un-)installation time.

[nsauzede]

Hello
I use MC for a long time, but this is my first ticket in this trac

I would like to add syntax for a new file type, vlang V files
The issue is that the file extension (*.v) is the same than Verilog files, for which there is
already a Syntax file (verilog.syntax)

Also, it seems that neither Verilog nor V files, have a specified "first line" format (such as Unix shebang, etc..)

So basically, it seems like I can't add V syntax without shadowing/screwing Verilog syntax.

My question is : how can we define syntaxes, for different file formats which use the same file extension, and no easy "first line" detection ?

[andrew_b]

Replying to nsauzede:

My question is

The bug tracking system is not a proper place for questions.

Your question is not relevant to ticket topic.