[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-zile] Syntax Highlighting

From: Reuben Thomas
Subject: Re: [Bug-zile] Syntax Highlighting
Date: Tue, 10 Jan 2012 14:09:33 +0000

On 10 January 2012 09:00, Gary V. Vaughan <address@hidden> wrote:
> So, I've been playing with a syntax highlighting engine in zi.. it currently
> only colors a hardcoded expression for matching lua comments in red, but
> also allows the status bar and minibuffer to by "themed" in different colors.
> I don't really think much of the emacs syntax highlighter, since it is complex
> and doesn't even allow nested modes (like shell code in a configure.ac, or
> more popularly javascript and php embedded in an html file) and as such I'm
> basing the engine on the way TextMate does it... in the first instance because
> writing new modes is a lot easier for TextMate than for Emacs, but also 
> because
> there are a ton of TextMate modes already available that it should be easy to
> write an importer to.

This all sounds exciting. I like the aspect of building on existing
work. One thing I've wondered in the past is whether there'd be anyway
to leverage e.g. GNU highlight in an editor (bearing in mind that
highlight is designed for offline use).

> Before I spend too much time tearing off on this tangent, do you forsee any
> scope for sharing some or all of this functionality with the lua branch 
> proper?

No (because it wouldn't be Emacs-compatible), but I don't see that as
a problem. The Lua branch will shortly become master, and like master,
I don't intend to develop its functionality. What I would like to see
is an underlying editor, Zi, or Zee, or whatever, with various
personalities, one of which is Zile. Since Zile already exists, and
since Zi already has another (rapidly-developing) personality, we have
two personalities to keep us honest.

(An aside: Zile 3.0 was always supposed to be Emacs; a few months ago
I did look into a minimal build of Emacs master, but had some weird
build-system problems. What I want to achieve is a single-file install
of Emacs, which AFAICT is not quite achievable at present. But that's
been my goal for a long time, as you can see from the Zile GSoC page.)

> I can't say off the bat whether it would be easier to collaborate on some kind
> of Emacs lisp font-lock support on lua with the bulk of the highlighting 
> engine
> itself implemented in lua and shared between the zi and lua branches, but it
> seems like we should explore the possibility of doing that so that both 
> branches
> can benefit...

A long time ago I killed off a buggy font-lock implementation in Zile,
and I don't think Zile's really in the market for font-lock. Zi/Zee, a
lightweight powerful extensible editor, is a rather different

> 1. The TextMate highlighting is controlled by a restartable oniguruma(sp?)

Have you noticed that lrexlib has an oniguruma binding? At least in
the short term that might be easier than trying to re-do that.

> I don't know whether it's
>   worth trying too much to shy away from additional dependencies like LPEG
>   if it's possible to make it work without.  Then again, ISTR you think that
>   the best way to get satisfactory performance out of the file buffers is to
>   write them as a lua module in C.

That's right, and if you've been following my recent participation in
gnu-prog-discuss discussion, you'll see that I'm much keener on
improving portability and ease of use of dependencies than on dropping
them. Let's concentrate on re-use, not rewriting!

> shipping it's own lua sources and luastd, so that
>   it can be built easily again?

Again, rather than shipping monolithic sources, I think we should
concentrate on making it easy to build from modular sources, e.g. by
auto-downloading-and-installing missing dependencies, and feeding all
this work back into the relevant GNU tools upstream (via gnulib, for
speed?). Ambitious, but awesome.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]