Ticket #3732 (closed defect: wontfix)

Opened 3 years ago

Last modified 3 years ago

mcedit syntax highlighting for rc.conf

Reported by: kuzvesov Owned by:
Priority: minor Milestone:
Component: mcedit Version: 4.8.18
Keywords: mcedit syntax highlighting Cc:
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

I tried to create syntax highlighting rules for freebsd's rc.conf.

And discovered few things:

  1. The include command in ~/.config/mc/mcedit/Syntax doesn't search for files in directory ~/.config/mc/mcedit/. So if I want to add my own syntax highlighting I must either add it right into Syntax file, meaning no include commands, or place syntax files into /usr/local/share/mc/syntax/. Syntax include ~/.config/mc/mcedit/something.syntax doesn't work too, so I must use full paths in include command and local Syntax file appears to be user-specific.
  1. Creating own Syntax file prevents using of system-wide Syntax. If I place in local Syntax command include Syntax, or command include /usr/local/share/mc/syntax/Syntax, or pair of file .\* all + include Syntax then mc complains about first include command in system-wide Syntax file.
  1. It appears that whole option of keyword command doesn't work as it should (or at least, as I think it should work). I started with the following simple syntax file for rc.conf:
    # default context
    context default
        wholechars ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_
        keyword whole *_enable yellow
    
    # comments
    context # \n gray
    
    The result is following
    https://pp.vk.me/c626317/v626317466/3737a/jQTcL60rcvM.jpg
    So it highlights all chars from the beginning of string, no matter that they do not form a whole word. I tried all three options: whole, wholeleft and wholeright, the result is the same.
    (I'll attach the screenshot just for case).

Attachments

2016-11-27 18_24_51-mc [root.localhost]__etc.png (6.3 KB) - added by kuzvesov 3 years ago.
screenshot

Change History

Changed 3 years ago by kuzvesov

screenshot

comment:1 Changed 3 years ago by kuzvesov

I also add that I tried to prevent highlighting of commented out lines using keyword #* gray command, but it seems to be processed before/after the command keyword *_enable command, no matter of command sequence in the syntax file: both

context default
    wholechars ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_
    keyword #* gray
    keyword whole *_enable yellow
context # \n gray

and

context default
    wholechars ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_
    keyword whole *_enable yellow
    keyword #* gray
context # \n gray

produce the same result as shown before.

comment:2 in reply to: ↑ description Changed 3 years ago by andrew_b

Let's don't mix several unrelated bugs in one ticket.

Replying to kuzvesov:

  1. The include command in ~/.config/mc/mcedit/Syntax doesn't search for files in directory ~/.config/mc/mcedit/.
  1. Creating own Syntax file prevents using of system-wide Syntax.

#1984

  1. It appears that whole option of keyword command doesn't work as it should.

Let's this ticket is for this bug only.

comment:3 Changed 3 years ago by mooffie

It doesn't seem to me that there's a problem with the whole keyword here. The * matches any char (except newline), including a #. The start (and end) of a line are considered boundaries too, so your *_enabled is right to start there.

Instead of * you need to use a character class:

keyword \[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_\]_enable yellow

I think [chars] and {chars} are not documented in the manual. So, here, you have an opportunity to contribute a patch documenting it (in a new ticket). Thanks.

comment:4 Changed 3 years ago by zaytsev

(on the run)

\[A-Za-z_\]

?

comment:5 follow-up: ↓ 6 Changed 3 years ago by kuzvesov

I'm sorry for mixing two bugs into one ticket, my bad.

And thanks for the hint, character classes almost solved the problem. But anyway, it looks quite unreasonable why keywords specified for one context works in another one.

I found that underscore is treated in some special way in character classes, because this construction:

keyword \[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_\]_enable yellow

doesn't work at all, while this one

keyword \[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\]_enable yellow

works as expected, but obviously doesn't include underscore sign, so for things like firewall_nat_enable or dhcp_chroot_enable I must repeat that long character class sequence twice:

keyword \[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\]_\[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\]_enable yellow
Last edited 3 years ago by kuzvesov (previous) (diff)

comment:6 in reply to: ↑ 5 Changed 3 years ago by mooffie

Replying to kuzvesov:

I found that underscore is treated in some special way in character classes, because this construction:

keyword \[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_\]_enable yellow

doesn't work at all, while this one

keyword \[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\]_enable yellow

works as expected, but obviously doesn't include underscore sign


(Interestingly, removing the letter 'e' from the class is another way to solve the problem.)

Here's something worth investigating:

MC associates with each context a list of all the letters that may start a keyword. It does this for optimization. So, for example, if a context defines the keywords "if", "then", "else", then context_rule_t.keyword_first_chars would contain "ite".

The problem is, I believe, that MC can't figure out the "first letter" when it's a character class (see syntax.c:edit_read_syntax_rules()). It's a big question why "keyword \[A...Z\]_enable yellow" works at all. We need to find out if it's indeed this first-letter optimization that causes the trouble.

comment:7 Changed 3 years ago by mooffie

OK, folks, I have good news: everything in MC works alright. No bugs here. (Ignore my previous comment.)

It turns out \[chars\] is greedy, as explained in the improved documentation. (This should have been obvious but the 'e' thing threw me off.)

So there's nothing to do. We should close this ticket. As stated in the manual page, extending the syntax capabilities to support regular expressions is not on our agenda.

@kuzvesov: You just can't do what you want. So make "_enabled" alone displayed in bold or some such.

comment:8 Changed 3 years ago by mooffie

  • Status changed from new to closed
  • Resolution set to wontfix

comment:9 Changed 3 years ago by andrew_b

  • Milestone Future Releases deleted
Note: See TracTickets for help on using tickets.