[Ur] urweb-mode.el improvements

Timothy Beyer beyert at fastmail.net
Sun Apr 8 19:04:31 EDT 2012


Hi,

A while ago, Adam requested improvements to the Emacs mode in the thread "[Ur] Calling all Emacs wizards".  Recently I wrote some (unreleased) preliminary improvements to the mode that mostly address two issues that I have with the mode, although the changes to the font coloring are not yet complete.

First, the font coloring issue, which is not ready for release yet:

The way that (urweb-in-xml) is used for the font-lock-defaults breaks syntax highlighting in XEmacs.  In XEmacs, (at far as I can tell) when a font keyword is set to nil, it remains nil for the remainder of the font-lock-defaults, regardless of future attempts to change the face.  GNU Emacs is less fussy about font locking, and recognizes that a nil value could be later assigned a specific face, whereas XEmacs does not.

What I did in an alternate version was a bit more complex, but as a side-effect, might be a bit faster that the way it is currently done, so it could potentially address the slow font locking issue as well.

I check for the "\\([^<>{}]+\\)" last, (with the call to (urweb-in-xml)), which is preceeded a several additional regular expressions that check for cvariable, to ensure that the font-lock-cvariable-face is set properly.

Depending on the way that Emacs performs fontification, this way might be much faster, or much slower.  I haven't done any profiling yet.

Additionally, I have a potentially useful regular expression that could replace basic usages of the "\\([^<>{}]+\\)" match, without using (urweb-in-xml).  The main problem with this is that it can't detect <xml> tags within existing <xml> tags currently, so I'm not sure if (urweb-in-xml) can ever be fully replaced by a regular expression alone.

So far, when I compared several ur files, the way that I do font coloring looks exactly the same as the existing font coloring.  However, I want to make it more efficient and simple before I put it in the issue tracker.

Second, the indentation issue, which is working properly so far:

Currently, the mode does not obey the variable urweb-indent-level.  This has annoyed me when using the sml-mode, as well.  The way that urweb-mode and sml-mode handle indentation is atypical for Emacs modes.

Assuming that I have two space indent, the current behavior of urweb-mode and sml-mode looks like this: 

fun testFunction arg =
    case u of

(4 spaces)

when it should look like this:

fun testFunction arg =
  case u of

(2 spaces)

I was able to fix the indentation problem with a few minor changes, and the changes were not particularly complex.  I could upload that patch in the issue tracker very soon, in fact.  My changes also make the sql indentation follow urweb-indent-level, rather that just 2 spaces.

I think that the designers of sml mode actually had a different intent, which was to indent relative to the start of the word after the keyword (on the previous line), but that is odd, considering that they offer the variable urweb-indent-level/sml-indent-level.

Do you want the indentation to follow urweb-indent-level, or to use the existing method? If you prefer the existing method, then I'd suggest a custom boolean variable urweb-follow-indent-level, which would allow for either method to be used.

Regards,
Tim



More information about the Ur mailing list