Fork me on GitHub
News > More Luminous 0.7 ramblings

Source/comments: http://blog.asgaard.co.uk/2012/09/06/more-luminous-0-7-ramblings

More Luminous 0.7 ramblings

6 September 2012, 3:53 pm

As I'm currently killing time from my slightly half-hearted job search while I am learning to drive (which in the UK is a major undertaking), I've been thinking about Luminous 0.7 and what I want it to do.

Firstly, 0.6 was a near-total rewrite about 18 months ago and 0.7 will be nowhere near the same level of change. That's because 0.6.x works pretty well. The core highlighting is awesome, and where it's not awesome, it's because I don't fully understand the language's grammar (see Bash and Ruby, forks/patches are welcome), not because Luminous is inherently crippled. 0.6 moved away from the idea that all languages should be abstracted into one single monolithic lexing algorithm and instead allows lexers to be individually written by hand. It works very well; it doesn't inflate the codebase much and it segregates complexity. It handles those awkward little special cases nicely, on which monolithic highlighters like GeSHi or many of the myriad JavaScript based highlighters struggle or fail entirely*.

I'm very happy with how the architecture has held up so there won't be any surprise changes to the scanning infrastructure. Although obviously, existing scanners will continue to improve incrementally.

I'm not really that interested in adding support for more languages, with the exceptions of SCSS and possibly Razor (a cool .NET templating engine - if you haven't tried it, you're missing out). We cover about 35 or so and you have to get into increasingly esoteric areas to find others. However, contributions will be accepted and writing a scanner often isn't hard.

So 0.7 is aiming to add or improve primarily on the other things that make a difference.

I've previously written about cleaning up the markup so I won't say much about it other than the markup is now clean and minimalist. The core CSS is compiled from SCSS so that's a bit more maintainable too (themes are still straight CSS for ease of editing, and they're so simple anyway...).

I am hoping to have some JavaScript provide something of use via a jQuery plugin exposing an API. Things like highlighting lines dynamically, toggling line numbers, toggling highlighting, etc. It will look something like: $('#luminous').luminous('highlightLine', 1).

Another thing I'm dissatisfied is option setting. Currently, all options are global, so there's no inbuilt notion of having a setting linked to only one highlight call. That works for most options but for a few it might be a little odd. The fix for this is to make the options class more active and expose it to the caller. Then you'll be able to send through an options object in the highlight() call to tell it to apply those certain options to that call only.

There's a fork on GitHub which implements fixing the line numbers to the side regardless of hoz-scrolling. I like this idea a lot. The fork is incompatible with 0.7's markup so I won't be merging it, but I like the idea and something similar may make it into 0.7 if it's practical to do with the new markup (I'm not sure at the moment ... the line numbers are psuedo-elements so it will need some cunning).

So in conclusion there will be a few backwardly incompatible changes, hence the version bump, but mostly I am trying to retain backwards compatibility as much as possible (there will be method overloading, or at least simulated overloading -- PHP doesn't do real overloading, to try to keep most things the same), so if you're just using it straightforwardly and not making any changes of your own then it should just drop straight in.

As ever, the code is on GitHub and you are free to check out the 0.7 branch.

____
* it seems like there is a new JS highlighter out every week. I've checked out a few of them and they are all pretty much the same. CodeMirror is good, the rest, well, I struggle to see why the world needs yet another broken syntax highlighter.