Changes between Initial Version and Version 1 of Ticket #3732, comment 5


Ignore:
Timestamp:
11/29/16 06:19:13 (5 years ago)
Author:
kuzvesov
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #3732, comment 5

    initial v1  
    1 Thanks for the hint, character classes solved the problem. But anyway, it looks quite unreasonable why keywords specified for one context works in another one. 
    2 And I'm sorry for mixing two bugs into one ticket, my bad. 
     1I'm sorry for mixing two bugs into one ticket, my bad. 
     2 
     3And 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. 
     4 
     5I found that underscore is treated in some special way in character classes, because this construction: 
     6{{{ 
     7keyword \[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_\]_enable yellow 
     8}}} 
     9doesn't work at all, while this one 
     10{{{ 
     11keyword \[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\]_enable yellow 
     12}}} 
     13works 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: 
     14{{{ 
     15keyword \[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\]_\[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\]_enable yellow 
     16}}} 
     17