From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: question about frame local variable Date: Tue, 28 Oct 2003 17:03:36 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200310280803.RAA05883@etlken.m17n.org> References: <200310250049.JAA12659@etlken.m17n.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1067328365 17821 80.91.224.253 (28 Oct 2003 08:06:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 28 Oct 2003 08:06:05 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Oct 28 09:06:03 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AEOrb-0000ee-00 for ; Tue, 28 Oct 2003 09:06:03 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AEOrb-0001su-00 for ; Tue, 28 Oct 2003 09:06:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AEOpu-0003QH-CH for emacs-devel@quimby.gnus.org; Tue, 28 Oct 2003 03:04:18 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AEOpo-0003Of-TD for emacs-devel@gnu.org; Tue, 28 Oct 2003 03:04:12 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AEOpI-00038u-RA for emacs-devel@gnu.org; Tue, 28 Oct 2003 03:04:11 -0500 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AEOpH-00036k-J6; Tue, 28 Oct 2003 03:03:39 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6p2/3.7W-20010518204228) with ESMTP id h9S83bh29671; Tue, 28 Oct 2003 17:03:37 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6/3.7W-20010823150639) with ESMTP id h9S83as11420; Tue, 28 Oct 2003 17:03:37 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id RAA05883; Tue, 28 Oct 2003 17:03:36 +0900 (JST) Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Sun, 26 Oct 2003 06:46:55 -0500) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:17493 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17493 In article , Richard Stallman writes: > It seems that we need the attached patch to make a code like > this (allow scalable fonts only for a specific frame) work > well. > (defun make-frame-allowing-scalable-fonts () > (make-variable-frame-local 'scalable-fonts-allowed) > (let ((frame (make-frame '((name . "SCALABLE"))))) > (modify-frame-parameters frame '((scalable-fonts-allowed . t))) > frame)) > The patch accesses the value of `scalable-fonts-allowed' not > directly by Vscalable_fonts_allowed but via: > is there a bug in handling frame-local bindings for variables > forwarded to C vars? if so, can we fix that bug? I don't know how "frame-local bindings for variables" should be treated in C code. So I can't tell if there's a bug or not. Ideally, I think selecte-frame should change the value of Vscalable_fonts_allowed when that has frame local binding. Then, C code can simply refer to this variable to get the current value. But, apparently, Fselect_frame and do_switch_frame called from it does nothing about such variables. Only via find_symbol_value, C code gets the current value. On the other hand, set_buffer_internal_1 surely pays attention to buffer local variables so that C variables get the current value. --- Ken'ichi HANDA handa@m17n.org