Bringing espresso-mode and js2-mode closer together would be good
(e.g. by merging them into a single mode with customization options
allowing to choose between different ways to do highlighting, imenu,
etc...).
I've now had a chance to take a quick look at espresso-mode, and it
looks like it's most likely a better choice for inclusion in Emacs, assuming
it works well. I haven't had a chance to use it for actual work yet, but I
will at the earliest opportunity.
js2-mode was a fairly quick/dirty mode wrapped around a parser that was
written to feed an interpreter, not to feed an editing mode. espresso-mode
is clearly designed from the ground up to be a good Emacs mode for JS.
I like the idea of making js2-mode a minor mode that can supply parse
errors and warnings asynchronously if enabled. That's its core strength in
any case. If Daniel's amenable I'd be happy to start working with him in
that direction.
Especially on the indentation side since it seems they ahre some of
their history.
I'm guessing that indentation needs a lot more work to make it
configurable enough to satisfy the needs of companies like mine, where
the coding style guides would specify indentation rules in pixels/points
if they could get away with it.
It would be nice if someone would dive in and enhance cc-engine to
handle _javascript_ constructs. I may give it another go at some point
if nobody else does.
> Daniel's objections to js2-mode's non-interaction with font-lock
> apply equally to the non-interaction with cc-engine's indentation
> configuration system. The indent configuration for _javascript_ should
> share as many settings as practical with cc-mode.
I'm not too fond of cc-mode's indentation code and configuration,
actually, so I don't mind if js2-mode doesn't share anything with it
(tho I won't oppose a change in this respect either).
I'd like to hear more about the objections. I realize it's horribly complex,
but I've looked at other configurable indenters and they always wind up
being too complex for most users as well -- gigantic manuals, custom
minilanguages, the works.
> 3) indentation in "normal" Emacs modes also runs synchronously as
> the user types. Waiting 500-800 msec or more for the parse to
> finish is (I think) not acceptable for indentation. For small
> files the parse time is acceptable, but it would not be generally
> scalable.
Agreed. Do you happen to know who other IDEs do about it?
Yes. Eclipse has a fast, inaccurate parser that runs inline as you type,
and a slow, accurate one that lags behind by a few hundred ms. (They
handle name resolution this way as well, except the fast one runs with
the slow parser, and the slow one can take minutes to hours.)
Eclipse uses the fast/inaccurate parser for both fontification and
indentation. The slower parser is used when (for instance) you want to
reformat a block of code -- something like a cross between indent-region
and fill-region for source code. I'm not an Eclipse user myself, so I'm
not familiar with all the ins and outs, but this is the basic approach they
take.
> Va) Inadequate/insufficient style names
[ Putting on my functional programmer hat here. ]
All you're saying here is that your languages have too many concepts.
Yes, well, of course. But they're not _my_ languages now, are they?
[ Putting on my Emacs maintainer hat again. ]
highlighting should be about helping the user understand his code:
highlighting every character with a different color is the way to
get there.
I'm not 100% sure I follow this statement. Do you mean "not the way"?
You may want to help him find structure (e.g. make
function/method declaration stand out), you may want to help him not get
confused (highlight strings and comments differently), you may want to
attract his attention to weird things (undeclared variables, ...), but
I highly doubt that highlighting function parameters differently from
local variables will help her in any way.
We don't know this, and in fact cannot know it a priori, since there are new
languages appearing all the time. And templates with mixed languages
complicate things further.
I think it's best not to be in the business of dictating or even advising taste.
We should focus on making things flexible enough for people to make the
distinctions they wish to make.
This said, the set of default faces deserves a rethink as well as some
additions, yes.
> languages, not the intersection. There should, for instance, be a
> font-lock-symbol-face for languages with distinguished symbols such
> as Lisp, Scheme and Ruby.
What for?
I meant for quoted symbols -- e.g. I color 'foo, :foo and #'foo differently
in my elisp code. They all have colors from the same region of rgb space,
but they're different enough that I can tell keyword args from function-quoted
symbols with just a glance from far away. I find this helpful. Others' MMV.
> Vf) No font-lock interface for setting exact style runs
[...]
> The problem is that I need a way, in a given font-lock redisplay, to
> say "highlight the region from X to Y with text properties {Z}".
I'm not sure I understand the problem. What's wrong with
put-text-property?
font-lock biffs my properties.
> When I assert that it's not possible, I understand that it's
> _theoretically_ possible. Given a _javascript_ file with 2500 style
> runs, assuming I had that information available at font-lock time, I
> could return a matcher that contains 2500 regular expressions, each
> one of which is tailored to match one and exactly one region in the
> buffer.
Just place in font-lock-keywords a MATCHER that is a function whose code
walks the list of your "runs" (checking which of your runs are within
(point) and LIMIT) and uses add-text-properties on them; and finally
returns nil.
This is different from what Daniel advised, and neither approach is very
well documented (if at all). I will try them both and report back when I can.
> Vg) Lack of differentiation between mode- and minor-mode styles
[...]
> As far as I can tell, the officially supported mechanism for
> adding additional font-lock patterns is `font-lock-add-keywords'.
> This either appends or prepends the keywords to the defaults.
Yes, this sucks. It should be replaced by a more declarative interface.
A simple workaround for now might be to keep pointers to the originals
and the extras in an alist that remembers who added which keywords.
-steve
Stefan