On Tue, Aug 11, 2009 at 9:04 AM, Stefan Monnier 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...). 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 >