On Tue, Aug 11, 2009 at 9:04 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
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...).
Especially on the indentation side since it seems they ahre some of
their history.
> Daniel's objections to js2-mode's non-interaction with font-lockI'm not too fond of cc-mode's indentation code and configuration,
> 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.
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).
Agreed. Do you happen to know who other IDEs do about it?
> 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.
> 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.
[ 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.
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.
This said, the set of default faces deserves a rethink as well as some
additions, yes.
What for?
> 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.
[...]
> Vf) No font-lock interface for setting exact style runs
> The problem is that I need a way, in a given font-lock redisplay, toI'm not sure I understand the problem. What's wrong with
> say "highlight the region from X to Y with text properties {Z}".
put-text-property?
Just place in font-lock-keywords a MATCHER that is a function whose code
> 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.
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.
> Vg) Lack of differentiation between mode- and minor-mode styles[...]
> As far as I can tell, the officially supported mechanism forYes, this sucks. It should be replaced by a more declarative interface.
> adding additional font-lock patterns is `font-lock-add-keywords'.
> This either appends or prepends the keywords to the defaults.
Stefan