From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Colin Walters Newsgroups: gmane.emacs.devel Subject: Re: kill ring menu Date: 06 May 2002 23:55:34 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <1020743734.5288.153.camel@space-ghost> References: <1020022891.27106.142.camel@space-ghost> <200204290505.g3T55t006146@aztec.santafe.edu> <1020059236.31789.358.camel@space-ghost> <200204300519.g3U5Js306727@aztec.santafe.edu> <1020320725.27616.54.camel@space-ghost> <200205031825.g43IPuD00768@aztec.santafe.edu> <1020502030.5286.25.camel@space-ghost> <200205051746.g45Hk5P01808@aztec.santafe.edu> <1020662101.5288.76.camel@space-ghost> <87helleq50.fsf@tc-1-100.kawasaki.gol.ne.jp> <1020725723.5138.127.camel@space-ghost> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1020744214 11862 127.0.0.1 (7 May 2002 04:03:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 7 May 2002 04:03:34 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 174wCM-00035D-00 for ; Tue, 07 May 2002 06:03:34 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 174wJo-0001c5-00 for ; Tue, 07 May 2002 06:11:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 174wBy-0004hF-00; Tue, 07 May 2002 00:03:10 -0400 Original-Received: from monk.debian.net ([216.185.54.61] helo=monk.verbum.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 174w9d-0004dQ-00 for ; Tue, 07 May 2002 00:00:45 -0400 Original-Received: from space-ghost.verbum.private (freedom.cis.ohio-state.edu [164.107.60.183]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "space-ghost.verbum.org", Issuer "monk.verbum.org" (verified OK)) by monk.verbum.org (Postfix (Debian/GNU)) with ESMTP id 3D9F87400252 for ; Tue, 7 May 2002 00:00:34 -0400 (EDT) Original-Received: by space-ghost.verbum.private (Postfix (Debian/GNU), from userid 1000) id 322298C6C7B; Mon, 6 May 2002 23:55:34 -0400 (EDT) Original-To: emacs-devel@gnu.org In-Reply-To: X-Mailer: Ximian Evolution 1.0.3 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3657 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3657 On Mon, 2002-05-06 at 21:35, Miles Bader wrote: > You're assuming such `consistency' is a win. Usually consistency is, > but several people have said on this thread that they _like_ the current > `inconsistency.' The rules people follow are not always as simple as > you might wish. Perhaps in this case people see a distinction between > fontifying existing `text files' (like program source) and buffers that > are created by emacs to display some information. I think that distinction is arbitrary; I don't see it at all. Especially when one considers that these "special" buffers could quite legitimately later be extended to be real modes; in that case, are we going to tell our users, "Oh, you have to set `foo-mode-fontification' to be non-nil to get special highlighting"? I don't think so; it's better to make the *interface* via font-lock from the start. > In any case, if it's _really_ desirable to have the single concept of > font-locking control all fontification in buffers (and obviously this is > not clear), then it still seems a bit silly to have font-lock following > non-face properties in the buffer; you could just as easily arrange for > the font-lock `user interface' (e.g., toggling font-lock mode) to be > separate from the font-lock `mechanism' (the part that adds face > properties), and have whatever ad-hoc fontification code you wish follow > the dictates of the former without using the latter. This is *exactly* the way things already work. font-lock in this case just calls the `font-lock-fontify-region' function to do the fontification. Thus, font-lock becomes the "user interface", as you say, and the mode author implements the mechanism. > This is only true if you use `real' font-locking -- e.g., regexps that > match the buffer text -- instead of making font-lock follow text > properties to do its locking. And why is the former "real" font-locking? Fontification based on regular expressions is unreliable when we are dealing with a non-regular language. This is why (or at least I think a major reason why) the maintainers of font-lock added the ability for the major mode author to perform fontification themselves. > You could have _both_ of course, but that > seems silly; if you really want to dynamically update user added text, > you may as well just use traditional font-locking from the start. By "traditional" you mean "based on regexps"? Again, regexp-based font-lock is not reliable. I personally will always try to avoid regexp-based fontification in modes I write. And implementing your own `font-lock-fontify-region' function doesn't mean it has to search for existing text properties; you can perform arbitrary computation. But this is a digression. Again, my point is very simple: I think we should move towards making M-x font-lock-mode, as much as possible, the standard *interface* for enabling and disabling fontification. Whether or not is based on regexps is irrelevant. One other important point; if resource consumption is an issue, we could quite easily split font-lock.el into font-lock-core.el and font-lock.el, or whatever.