From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: tomas@tuxteam.de Newsgroups: gmane.emacs.devel Subject: Re: face-remapping patch Date: Thu, 29 May 2008 08:02:27 +0200 Message-ID: <20080529060227.GA6897@tomas> References: <5CB5F5E5-9239-40A8-A3B2-5F49B94E27B7@gmail.com> <85lk1ui3i0.fsf@lola.goethe.zz> <85ej7mi30t.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; x-action=pgp-signed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1212040967 7250 80.91.229.12 (29 May 2008 06:02:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 May 2008 06:02:47 +0000 (UTC) Cc: David Reitter , Miles Bader , Stefan Monnier , Emacs-Devel To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 29 08:03:27 2008 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 1K1bEV-0004iz-0G for ged-emacs-devel@m.gmane.org; Thu, 29 May 2008 08:03:27 +0200 Original-Received: from localhost ([127.0.0.1]:40515 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1bDj-0008B9-Ds for ged-emacs-devel@m.gmane.org; Thu, 29 May 2008 02:02:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1bDe-0008B4-Qx for emacs-devel@gnu.org; Thu, 29 May 2008 02:02:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1bDc-0008Ag-C1 for emacs-devel@gnu.org; Thu, 29 May 2008 02:02:34 -0400 Original-Received: from [199.232.76.173] (port=52853 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1bDc-0008Ad-6L for emacs-devel@gnu.org; Thu, 29 May 2008 02:02:32 -0400 Original-Received: from alextrapp1.equinoxe.de ([217.22.192.104]:49762 helo=www.elogos.de) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K1bDV-0001Qg-Rs; Thu, 29 May 2008 02:02:26 -0400 Original-Received: by www.elogos.de (Postfix, from userid 1000) id 7A06D9005E; Thu, 29 May 2008 08:02:27 +0200 (CEST) Content-Disposition: inline In-Reply-To: <85ej7mi30t.fsf@lola.goethe.zz> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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:97948 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, May 28, 2008 at 10:31:46PM +0200, David Kastrup wrote: >=20 > Sorry, C-c C-c is just too close to C-x C-x. This posting was not > finished. >=20 > David Kastrup writes: [...] > > (make-local-variable VARIABLE &optional locus) > > > > Make VARIABLE have a separate value in the given locus (defaulting to > > the current buffer). > > > > A locus can be a buffer, a frame, a terminal, a window. When there i= s > > more than one locus for which a variable may be local, the value is u= sed > > from the first locus in the list window - buffer - frame - terminal. [...] > Bing. A simple API, easy to understand, easy to use. And > _transparent_. Appealing. Humble suggestion: make the list of possible loci extensible, with the above mentioned being the minimal, "built-in" set. I don't know yet how an interface would look like, but several other classes of loci suggest themselves: major modes, (human) languages, what not. > Now XEmacs specifiers offer something more: you can specify local value= s > for _classes_ of display, like B&W, or reduced color or so. We have > something like that for faces. Hm. Would that not be covered by your proposal? You'd just need a little bit more of indirection. Your locus-local variable (locus=3Dterminal) wou= ldn't be a face itself, but a display class -- which then determines the face. Whether it's worth it -- I don't know. > However, I don't think the price for the generality of specifiers is > worth the complexity in the particular implementation and documentation > state of XEmacs. I did not understand them after trying for a > considerable amount of time, and I am arrogant enough to consider > something which I feel unable to understand as being off the complexity > bell curve for reliable engineering. :-) Still I read your posts carefully. Regards - -- tom=C3=A1s -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIPkbzBcgs9XrR2kYRAgRCAJ4vLVerFAvcn7CgyS+u4sI98B6AIgCdEu0Y px8GI/err2ku9Cb7fKpbelQ=3D =3DOxM9 -----END PGP SIGNATURE-----