Ticket #1984 (new defect)

Opened 9 years ago

Last modified 2 years ago

something like syntax.d for highlighting

Reported by: stronny at celestia dot ru Owned by:
Priority: major Milestone: Future Releases
Component: mc-core Version: version not selected
Keywords: Cc: zaytsev
Blocked By: Blocking: #1633, #1677
Branch state: no branch Votes for changeset:

Description

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.

Change History

comment:1 Changed 9 years ago by zaytsev

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

comment:2 Changed 9 years ago by zaytsev

  • Cc zaytsev added

comment:3 Changed 7 years ago by andrew_b

  • Cc changed from zaytsev, to zaytsev
  • Branch state set to no branch
  • Milestone changed from 4.7 to Future Releases

comment:4 Changed 6 years ago by 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.

comment:5 Changed 2 years ago by andrew_b

  • Blocking 1633 added

comment:6 in reply to: ↑ description Changed 2 years ago by 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.

comment:7 follow-ups: ↓ 8 ↓ 9 Changed 2 years ago by 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.

comment:8 in reply to: ↑ 7 Changed 2 years ago by 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.

comment:9 in reply to: ↑ 7 Changed 2 years ago by 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.

Note: See TracTickets for help on using tickets.