| 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. |
| | 1 | I'm sorry for mixing two bugs into one ticket, my bad. |
| | 2 | |
| | 3 | 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. |
| | 4 | |
| | 5 | I found that underscore is treated in some special way in character classes, because this construction: |
| | 6 | {{{ |
| | 7 | keyword \[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_\]_enable yellow |
| | 8 | }}} |
| | 9 | doesn't work at all, while this one |
| | 10 | {{{ |
| | 11 | keyword \[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\]_enable yellow |
| | 12 | }}} |
| | 13 | 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: |
| | 14 | {{{ |
| | 15 | keyword \[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\]_\[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\]_enable yellow |
| | 16 | }}} |
| | 17 | |
