Help adding a new language & feature request

[Troy Settle]

Found highlightJS as an extension to MediaWiki.  What an awesome tool!

I'm working on adding support for MikroTik's configuration and as far as I've been able to take it, it's pretty decent.  I am, however, running a problem handling repetitive matches.  For example, I'm able to match an IP address with or without a length, but can't see my way to match a hyphenated range or comma separated list:

/ip pool
add name=dhcp_pool1 ranges=192.168.1.2-192.168.1.254

/queue simple
add max-limit=10M/10M name="Test" queue=default/default target=192.168.1.20/32,192.168.1.30/32

My work so far can be seen at https://github.com/tsettle/highlight.js/blob/master/src/languages/mikrotik.js

I'm also wondering what it would take to allow the dynamic loading of style sheets so that different blocks of code could contain different styles.  For example, one might want to use one style for instructional elements while using another for functional code.

Thanks!

[Ivan Sagalaev]

> For example, I'm able to match an
> IP address with or without a length, but can't see my way to match a
> hyphenated range or comma separated list:
>
> /ip pool
> addname=dhcp_pool1ranges=192.168.1.2-192.168.1.254
>
> /queue simple
> addmax-limit=10M/10Mname="Test"queue=default/defaulttarget=192.168.1.20/32,192.168.1.30/32

What do you expect to get as a result? highlight.js has a pre-defined
limited set of highlighting classes it applies
(http://highlightjs.readthedocs.io/en/latest/css-classes-reference.html#stylable-classes)
and there are no such thing as "IP address range" for example.
Individual IP addresses are traditionally highlighted as numbers, but as
you said, you've got it covered already.

> I'm also wondering what it would take to allow the dynamic loading of
> style sheets so that different blocks of code could contain different
> styles.

There's no easy way out of the box, unfortunately… One approach would be
to add different prefixes to class names for different boxes, whereas
currently we apply one prefix globally.

[Troy Settle]

What do you expect to get as a result? highlight.js has a pre-defined
limited set of highlighting classes it applies
(http://highlightjs.readthedocs.io/en/latest/css-classes-reference.html#stylable-classes)
and there are no such thing as "IP address range" for example.
Individual IP addresses are traditionally highlighted as numbers, but as
you said, you've got it covered already.

I think a screen capture would do it more justice:
 

So, my match string is catching the left side of the equal sign and classifying it as an attribute.  Then I want to match the right side.  I'm able to match a single IP address / subnet, but the rest of the text goes without highlighting.  I could match to the end, but I'd prefer to leave the comma or hyphen without highlights (it's an OCD thing).  You can see my language file on github.  I'm sure there is a better way to do it, but that's what I was able to hack together from examples in other language files (notably the DNS and INI language files).

My intention, long term, is to generate language files for other networking equipment and perhaps some configuration files for various network-related services such as iptables, isc-dhcp, xinetd, etc...  I think I'm going to be running into a lot of this.

> I'm also wondering what it would take to allow the dynamic loading of
> style sheets so that different blocks of code could contain different
> styles.

There's no easy way out of the box, unfortunately… One approach would be
to add different prefixes to class names for different boxes, whereas
currently we apply one prefix globally.

Yeah, that's what I was thinking too, not very pretty or portable.  An idea came to me while driving to the office this morning though.  I may dig around and see if it might be possible to bundle the styles into JSON, then inject them at run-time with dynamic class names.  I'm guessing it would require more than a minor change to the underlying code, but I think it could yield some interesting results, especially when pairing a specific language to a specific style might be desirable.

For the time being though, I'm perfectly happy with where it's at right now.

[Ivan Sagalaev]

> I think a screen capture would do it more justice:

It did, thanks :-)

> So, my match string is catching the left side of the equal sign and
> classifying it as an attribute. Then I want to match the right side.
> I'm able to match a single IP address / subnet, but the rest of the text
> goes without highlighting. I could match to the end, but I'd prefer to
> leave the comma or hyphen without highlights (it's an OCD thing).

I'd say it's pretty basic attention to detail, nothing extraordinary. To
implement it you define a general mode that would include IP addresses,
literals and everything else:

{
begin: /=/, end: /\s/, excludeBegin: true, excludeEnd: true,
keywords: {
literal: 'no' // space separated list of literals
}
contains: [
{
begin: /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/, // IP address
className: 'number',
},
]
}

(The `end: /\s/` part assumes there can't be spaces with the value part.)