From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: frame-local variables weirdness Date: Wed, 17 Oct 2007 10:29:15 -0700 Message-ID: <2bfd4e060710171029g30a62313naf31c5363d85d6ca@mail.gmail.com> References: <858x65lh4m.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1192642181 32567 80.91.229.12 (17 Oct 2007 17:29:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Oct 2007 17:29:41 +0000 (UTC) Cc: lekktu@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 17 19:29:41 2007 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 1IiCi5-00026j-49 for ged-emacs-devel@m.gmane.org; Wed, 17 Oct 2007 19:29:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IiChx-0003xI-Tn for ged-emacs-devel@m.gmane.org; Wed, 17 Oct 2007 13:29:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IiChu-0003v8-4r for emacs-devel@gnu.org; Wed, 17 Oct 2007 13:29:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IiCht-0003tl-5R for emacs-devel@gnu.org; Wed, 17 Oct 2007 13:29:21 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IiChs-0003sw-Pr for emacs-devel@gnu.org; Wed, 17 Oct 2007 13:29:20 -0400 Original-Received: from nf-out-0910.google.com ([64.233.182.187]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IiChr-0006QW-0J for emacs-devel@gnu.org; Wed, 17 Oct 2007 13:29:19 -0400 Original-Received: by nf-out-0910.google.com with SMTP id f5so2092734nfh for ; Wed, 17 Oct 2007 10:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=2IbpNT+v0jxzOjgYYiMLdn8H5o7PyOPmHvHQXMqR/OM=; b=BDvdjaWMEr4ti2rEJc1rzkrXcMVIPMYhyHa8Xc5h7jWOH2c91/RkLE4yJxH2i+ulALf1D5/2G8ZNVnV5cLxiRGJZSET4D+N+TNwxKt+OMslPaZDh/yokhZKG23OvjxSz5uMduX/XOZcvBlGlpehu3Skk74a97c2TBIg3kduWyec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=C3iX9Gjevxny2aJgfp6P40mx7Ek4p6WrMBWYstgWrctzt9ZvPGlFXRfGbB3SfxlB0OQuQsFHfIjB9uOFwZU6OBw9NHJecmA1UGZXyE2nm0RcPCbe8cVt/A4N2HkrplhDRoQh/J0FxmeUaMUJf0wdVLqpgDLhl43PhneCpCLdCm8= Original-Received: by 10.86.84.5 with SMTP id h5mr6995828fgb.1192642155824; Wed, 17 Oct 2007 10:29:15 -0700 (PDT) Original-Received: by 10.86.26.15 with HTTP; Wed, 17 Oct 2007 10:29:15 -0700 (PDT) In-Reply-To: Content-Disposition: inline X-Google-Sender-Auth: d7663643d204ca17 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:81073 Archived-At: FWIW, let me remind you that XEmacs has specifiers, which allow rather flexible mix and match of buffer-local, window-local, and frame-local properties. The point is that specifiers have a separate API, no unmarked magic. This has been a workable compromise for me in those cases where I want to use it (eg, faces, where specifiers implement flexibility very similar to Emacs's defface; XEmacs's faces are implemented as a wrapper around a set of specifiers containing display properties). There are a few other cases where I've enjoyed the flexibility (usually controlling behavior of functions associated with active regions in a display, and in controlling display elements such as toolbars, tabs, and scrollbars). David Kastrup may have an informative opinion, since he found XEmacs's glyph (~ Emacs image) API, uh, "annoying" (and even its author admits it's probably excessively complex and detailed). But I'm not sure whether he objects to the idea of such an API, or merely to XEmacs's implementation in glyphs. On 10/15/07, Stefan Monnier wrote: > > I found the discussion. I see that someone asked for a feature to > > display frame-specific data in the mode line, and I decided this > > general feature (with which the job could be done) was cleaner and > > simpler than a specific feature which could do only that one job. > > That's a reasonable request, and indeed there are situations where we can > lookup a variable but we cannot call a function which could potentially run > arbitrary code. > Maybe that's enough to keep the feature. > > > Since it isn't very useful, we can take it out if we cannot fix it. > > But first let's try to fix it. > > But the above request does not mean we need to be able to mix&match > let-bindings, buffer-local, and frame-local variables. If we disallowed the > buffer-local&frame-local variables, the problem would disappear. This part > of the language is already complex enough as it stands. > > > Stefan > > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-devel >