From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nathan Weizenbaum Newsgroups: gmane.emacs.bugs Subject: bug#6203: Frame-local variables break let-binding Date: Tue, 18 May 2010 14:32:43 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001485f90bbef4d21a0486e5145f X-Trace: dough.gmane.org 1274219827 26242 80.91.229.12 (18 May 2010 21:57:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 18 May 2010 21:57:07 +0000 (UTC) Cc: 6203@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 18 23:57:06 2010 connect(): No such file or directory Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OEUmf-0005lC-5C for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 May 2010 23:57:05 +0200 Original-Received: from localhost ([127.0.0.1]:41660 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OEUme-0002l6-HH for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 May 2010 17:57:04 -0400 Original-Received: from [140.186.70.92] (port=40329 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OEUmX-0002kv-FW for bug-gnu-emacs@gnu.org; Tue, 18 May 2010 17:56:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OEUmU-0008Au-10 for bug-gnu-emacs@gnu.org; Tue, 18 May 2010 17:56:57 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48111) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OEUmT-0008Ao-S2 for bug-gnu-emacs@gnu.org; Tue, 18 May 2010 17:56:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OEUPN-00040C-Tr; Tue, 18 May 2010 17:33:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Nathan Weizenbaum Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 May 2010 21:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6203 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6203-submit@debbugs.gnu.org id=B6203.127421837415377 (code B ref 6203); Tue, 18 May 2010 21:33:01 +0000 Original-Received: (at 6203) by debbugs.gnu.org; 18 May 2010 21:32:54 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OEUPF-0003zy-Qt for submit@debbugs.gnu.org; Tue, 18 May 2010 17:32:54 -0400 Original-Received: from mail-gw0-f44.google.com ([74.125.83.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OEUPA-0003zt-LG for 6203@debbugs.gnu.org; Tue, 18 May 2010 17:32:51 -0400 Original-Received: by gwb19 with SMTP id 19so3266553gwb.3 for <6203@debbugs.gnu.org>; Tue, 18 May 2010 14:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=YENqtlWWczLhYGKO92Q4/kbISbm9HcVYt119L6pikhU=; b=XbzE7r4AHkgl96+fYdPFVylwpv7X4BgwI6WEkHIaN/Zlz3j7m9O7E0HvtaPbC7UQbW 789wdw4Xbw6FYJrCSk7JTIkftRGni22ruqyiu3nBmR3HtEcB/OfZU855QRwuIBB7s/rb 6o6KYDBKQ4SEZdwc3BrPlXZnc8NyFPVKlXsXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VR72Wc58OPbQsPIcHXuISm6Q4uiKhcP5XpQmZZwok6hFQ/yWPt3i9eyO3hfUk7ETaB Ebqx4UhUWGiO+C4TascXTZnpGUA3gTaOSGsANPL2qjTBni8uboSrgerNErgeWnGUdHEm lQcc1C4RDUyktfdgEhZYvpIkXf10a4YOMc2r4= Original-Received: by 10.91.39.19 with SMTP id r19mr2876316agj.130.1274218364063; Tue, 18 May 2010 14:32:44 -0700 (PDT) Original-Received: by 10.90.25.9 with HTTP; Tue, 18 May 2010 14:32:43 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 18 May 2010 17:33:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:37028 Archived-At: --001485f90bbef4d21a0486e5145f Content-Type: text/plain; charset=ISO-8859-1 letf and setf are okay as work-arounds, I suppose. The package I use these for is http://github.com/nex3/perspective-el/blob/master/perspective.el. Each frame keeps track of a separate set of workspaces, as well as various other useful variables (the current workspace, previous workspace, etc.). On Tue, May 18, 2010 at 8:29 AM, Stefan Monnier wrote: > > But frame-parameters have to be manually managed with frame-parameter, > no? > > Sounds obvious, doesn't it? > > > Even ignoring compatibility for user-facing configuration, it seems > really > > annoying to have to call frame-parameter and set-frame-parameter all the > > time, especially if you're trying to simulate `let'. > > No, it really doesn't seem particularly annoying: > > (require 'cl) > (letf (((frame-parameter ) 'newvalue)) ) > > the same holds for symbol properties, process properties, window > parameters, terminal parameters, ... > > > Are there at least any plans for a nicer API for working with what used > to > > be frame-local variables? > > BTW, since frame-parameters have been very rarely used and you seem to > use them "extensively", I'm curious: what do you use them for > (i.e. what kind of data do you keep there, and why do you need to > let-(re)bind it)? > > > Stefan > --001485f90bbef4d21a0486e5145f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable letf and setf are okay as work-arounds, I suppose.

The package I use= these for is http://github.com/nex3/perspective-el/blob/master/perspecti= ve.el. Each frame keeps track of a separate set of workspaces, as well = as various other useful variables (the current workspace, previous workspac= e, etc.).

On Tue, May 18, 2010 at 8:29 AM, Stefan Monn= ier <monni= er@iro.umontreal.ca> wrote:
> But frame-parameters have to be manually managed wit= h frame-parameter, no?

Sounds obvious, doesn't it?

> Even ignoring compatibility for user-facing configuration, it seems re= ally
> annoying to have to call frame-parameter and set-frame-parameter all t= he
> time, especially if you're trying to simulate `let'.

No, it really doesn't seem particularly annoying:

=A0 (require 'cl)
=A0 (letf (((frame-parameter <foo>) 'newvalue)) <blabla>)<= br>
the same holds for symbol properties, process properties, window
parameters, terminal parameters, ...

> Are there at least any plans for a nicer API for working with what use= d to
> be frame-local variables?

BTW, since frame-parameters have been very rarely used and you seem t= o
use them "extensively", I'm curious: what do you use them for=
(i.e. what kind of data do you keep there, and why do you need to
let-(re)bind it)?


=A0 =A0 =A0 =A0Stefan

--001485f90bbef4d21a0486e5145f--