Sass Syntax Support (*.scss, *.sass) - http://sass-lang.com/
Adding a new language to SciTE requires someone to write some code (a lexer) and configure properties. The scintilla.org web site contains documentation about these areas.
I will not be working on this myself.
I've started messing with this (with a view to getting SCSS support in Geany). Before I get too far, is anyone else working on it?
I added SCSS support, along with Less, to Komodo in our own forked version of the CSS lexer.
You can see the results at http://tinyurl.com/8y7fvrv
( http://svn.openkomodo.com/openkomodo/view/openkomodo/trunk/contrib/patches/scintilla/lexers/L exCSS.cxx )
If I were going to implement a Sass lexer, and there are some Komodo users who would welcome
the effor, I would start by writing a separate lexer. The folder would obviously be completely different, and the logic you need to determine whether you're in a selector, property name, or value is
different enough from the brace-based languages. At some point, you could fold the two lexers
back, but I wouldn't do that at the expense of muddying the CSS one.
One of the biggest problems is the ambiguity in determining whether you're in a selector, or
one of the other parts of the language. You can't use names, as any known property or
value name is a valid selector name as well.
I also recommend implementing the CSS3-Selector spec while doing this. Komodo doesn't
offer a way of turning it off in CSS/Less/SCSS, and no one's complained so far.
G'day and thanks for the pointer. I've made a small start by forking the CSS lexer for SCSS/SASS, and it's partially working, but I reckon it'll need some refactoring before I can clean up the last bits. I'll take a good look at what you've done, it'll no doubt clear up some things for me!
Re: CSS3, the current incarnation of LexCSS.cxx seems to have made a pretty good go at it already. You might be interested in revisiting that, although the structure is quite different to yours it seems.
And I agree about having it as a separate lexer; there are some things that are too different about SCSS to have them in a CSS lexer. I'm not yet sure whether I'll have SASS syntax support working (SCSS is my real target), but if it just falls out easily enough then so be it (otherwise someone else can have a crack at that one!)
So I've dropped the separate lexer, and had a stab at incorporating SCSS into the existing CSS lexer as ericp has done. I still have a bit outstanding on it (e.g. there's a bug in nesting, and I don't have nested property support yet) but it's getting there. When the time comes, do I just zip up the modified files and email them somewhere?
My fork of Geany with SCSS support:
Emailing to an individual means that the patch would block on that person. Its better to publish the patch so that any interested party can participate. Placing a zip on a web site or attaching to a feature request works well.
OK, seems to be working, but needs a couple of features added. However, it's good to go; the other features can come later when I have time or someone else feels like adding them.
Example file styles with comment to end
Open the attached file acid.css and scroll down by single lines to see comment style fail to terminate (like http://scintilla.org/csscmt.png\). Opening the file and moving straight to the end (Ctrl+End) shows correct highlighting.
This normally indicates that state is not being managed across multiple calls - some of the needed state is being lost before the problem line is lexed.
../lexers/LexCSS.cxx: In function 'void ColouriseCssDoc(unsigned int, int, int, WordList**, Accessor&)':
../lexers/LexCSS.cxx:112:3: warning: 'comment_mode' may be used uninitialized in this function [-Wuninitialized]
For automatic generation of documentation, the two new properties should be preceded by comments describing their use in a format similar to those in LexPython.cxx.
G'day Neil, thanks for reviewing. I'll have to build SciTE and check that out because that behaviour doesn't occur in Geany. What I do see is that the url() form where no quotes are supplied breaks my single-line comments due to the // in http:// (line 140 in acid.css); something I hadn't factored in :) (I guess we generally quote our URLs here)
I should be able to sort this out sometime later in the week, so hope to get something back to you by Sunday our time (Australia).
G'day Neil, I think that's sorted now; please give it a burl.
sorry, hold off on that... I was testing the wrong compile, not fixed yet :(
G'day Neil, this time :)
A confusing aspect of this code is that the comment says less is not yet implemented but it still has an effect.
If the less support is not yet ready for use then its safer to avoid including it as keeping it makes it more difficult to change compatibly if the less support changes direction.
Fair enough, just replace with bool isLessDocument = false for now. If I or someone else gets around to implementing some of the Less features (beyond nesting and single-line comments) then it can be enabled then. In the meantime, the code should accommodate adding that easily later on.
For clarity, did you want me to remove the comments for Less and set the bool to false, or will you do it at your end?
I prefer to stay synchronized by the original author updating the code. That is, you should remove the comment and property retrieval. If I change code then I often receive updates without the change so have to remember to apply it each time.
G'day Neil, all set so please look again.
G'day Neil, this has been getting a bit of a workout so I've found and fixed a bug in single-line comments (again). I've also added code to better handle data: urls, which were breaking in the lexer (even before I touched it :) )
Also, here's a sample of SCSS; I converted that acid.css file and added some SCSS-specific stuff.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.