From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: "Font-lock is limited to text matching" is a myth Date: Thu, 13 Aug 2009 21:22:27 -0400 Message-ID: References: <7b501d5c0908091634ndfba631vd9db6502db301097@mail.gmail.com> <200908101335.24002.danc@merrillprint.com> <87my67s8mr.fsf@randomsample.de> <1249942011.29022.15.camel@projectile.siege-engine.com> <1249955428.29022.186.camel@projectile.siege-engine.com> <9c768dc60908102347v57bdf38ara9fe2179f68c07e4@mail.gmail.com> <9c768dc60908111858n5acf6b9fs43f7fef5c07ad272@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1250212973 25559 80.91.229.12 (14 Aug 2009 01:22:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Aug 2009 01:22:53 +0000 (UTC) Cc: Daniel Colascione , David Engster , Daniel Colascione , Lennart Borgman , Deniz Dogan , emacs-devel@gnu.org, Leo , Miles Bader To: Steve Yegge Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 14 03:22:45 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MblVD-0004hn-2s for ged-emacs-devel@m.gmane.org; Fri, 14 Aug 2009 03:22:43 +0200 Original-Received: from localhost ([127.0.0.1]:35180 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MblVC-0001E9-FI for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 21:22:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MblV7-0001E2-Ss for emacs-devel@gnu.org; Thu, 13 Aug 2009 21:22:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MblV2-0001Dq-DV for emacs-devel@gnu.org; Thu, 13 Aug 2009 21:22:36 -0400 Original-Received: from [199.232.76.173] (port=44972 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MblV2-0001Dn-6Q for emacs-devel@gnu.org; Thu, 13 Aug 2009 21:22:32 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:27023 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MblUz-0008Cs-JH; Thu, 13 Aug 2009 21:22:29 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAOVYhEpFpZNo/2dsb2JhbACBUtJDhBkFh0E X-IronPort-AV: E=Sophos;i="4.43,377,1246852800"; d="scan'208";a="43496415" Original-Received: from 69-165-147-104.dsl.teksavvy.com (HELO pastel.home) ([69.165.147.104]) by ironport2-out.teksavvy.com with ESMTP; 13 Aug 2009 21:22:05 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 3C6837F24; Thu, 13 Aug 2009 21:22:27 -0400 (EDT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114213 Archived-At: >> 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. I have two reasons not to like it: the horribly complex indentation code, and the horribly complex compilation and configuration "stuff" (very non-standard with very dubious benefits). But I don't claim there's something better out there to fulfill the same requirements. > 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. Thanks. That makes a lot of sense. >> [ 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? They're yours in the sense that you care for them and (presumably) use them. >> [ 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"? Yes, the "not" somehow escaped, sorry. >> 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. In Emacs we generally work on a need basis (pretty much like eXtreme Programming advocates, although the relationship doesn't go much further I believe). It's very easy for a major mode to add its own face if the needs comes up. Until now, I haven't come across any language where highlighting function parameters specially would be useful. > 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. We'll have to agree to disagree on this one. >> > 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. That's another problem. If you do it from font-lock-keywords, then it works just fine. >> 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. I believe it is the same as what Daniel advised, actually. It's not well documented simply because there's not much to document: the MATCHER is a function so it can do anything it wants. >> > 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. If you assume that there are no coincidences (same keywords added by different (minor)modes), then as long as each (minor)mode adds and removes his own, then it's not too terrible. But, yes, occasionally it's a pain (when you want to reconstruct the whole thing for one reason or another). Mostly it means that you have to remember what you've added so that you can properly remove it. Stefan