* question about frame local variable @ 2003-10-25 0:49 Kenichi Handa 2003-10-26 11:46 ` Richard Stallman 0 siblings, 1 reply; 15+ messages in thread From: Kenichi Handa @ 2003-10-25 0:49 UTC (permalink / raw) 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: find_symbol_value (Qscalable_fonts_allowed) Is this the correct way? Shall I install it? --- Ken'ichi HANDA handa@m17n.org *** xfaces.c.~1.284.~ Tue Sep 2 08:26:41 2003 --- xfaces.c Fri Oct 24 16:48:04 2003 *************** *** 6162,6174 **** may_use_scalable_font_p (font) const char *font; { ! if (EQ (Vscalable_fonts_allowed, Qt)) return 1; ! else if (CONSP (Vscalable_fonts_allowed)) { Lisp_Object tail, regexp; ! for (tail = Vscalable_fonts_allowed; CONSP (tail); tail = XCDR (tail)) { regexp = XCAR (tail); if (STRINGP (regexp) --- 6162,6177 ---- may_use_scalable_font_p (font) const char *font; { ! Lisp_Object val; ! ! val = find_symbol_value (Qscalable_fonts_allowed); ! if (EQ (val, Qt)) return 1; ! else if (CONSP (val)) { Lisp_Object tail, regexp; ! for (tail = val; CONSP (tail); tail = XCDR (tail)) { regexp = XCAR (tail); if (STRINGP (regexp) *************** *** 6364,6370 **** } /* Try all scalable fonts before giving up. */ ! if (nfonts == 0 && ! EQ (Vscalable_fonts_allowed, Qt)) { int count = SPECPDL_INDEX (); specbind (Qscalable_fonts_allowed, Qt); --- 6367,6374 ---- } /* Try all scalable fonts before giving up. */ ! if (nfonts == 0 ! && ! EQ (find_symbol_value (Qscalable_fonts_allowed), Qt)) { int count = SPECPDL_INDEX (); specbind (Qscalable_fonts_allowed, Qt); ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-10-25 0:49 question about frame local variable Kenichi Handa @ 2003-10-26 11:46 ` Richard Stallman 2003-10-28 8:03 ` Kenichi Handa 0 siblings, 1 reply; 15+ messages in thread From: Richard Stallman @ 2003-10-26 11:46 UTC (permalink / raw) Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-10-26 11:46 ` Richard Stallman @ 2003-10-28 8:03 ` Kenichi Handa 2003-10-30 1:35 ` Kenichi Handa 0 siblings, 1 reply; 15+ messages in thread From: Kenichi Handa @ 2003-10-28 8:03 UTC (permalink / raw) Cc: emacs-devel In article <E1ADjMF-0005OQ-HM@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-10-28 8:03 ` Kenichi Handa @ 2003-10-30 1:35 ` Kenichi Handa 2003-10-30 9:33 ` Gerd Moellmann 0 siblings, 1 reply; 15+ messages in thread From: Kenichi Handa @ 2003-10-30 1:35 UTC (permalink / raw) Cc: gerd.moellmann, rms CCed to Gerd. In article <200310280803.RAA05883@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes: > 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. I found that the above is not enough. It seems that the display engine doesn't issue select-frame; i.e. provided that there are two frames A and B, there is a case that the display engine redisplays A while the selected frame is B. It means that even if we make such variables frame local that affect the redisplaying (font-selection, etc), any frame local bindings are just ignored. Gerd, do you remember this matter? Is my analysis correct? --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-10-30 1:35 ` Kenichi Handa @ 2003-10-30 9:33 ` Gerd Moellmann 2003-10-30 10:46 ` Kenichi Handa 2003-10-30 16:27 ` Stefan Monnier 0 siblings, 2 replies; 15+ messages in thread From: Gerd Moellmann @ 2003-10-30 9:33 UTC (permalink / raw) Cc: rms, emacs-devel Kenichi Handa <handa@m17n.org> writes: > CCed to Gerd. > > In article <200310280803.RAA05883@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes: > > 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. > > I found that the above is not enough. It seems that the > display engine doesn't issue select-frame; i.e. provided > that there are two frames A and B, there is a case that the > display engine redisplays A while the selected frame is B. > > It means that even if we make such variables frame local > that affect the redisplaying (font-selection, etc), any > frame local bindings are just ignored. > > Gerd, do you remember this matter? Is my analysis correct? I think so; it matches what I remember. Local bindings are not supported for all redisplay variables. AFAIR, that has always been the case and isn't new in 21. Where it is supported, I think redisplay looks at frame parameters. (BTW, calling select-frame in redisplay would almost certainly not be the right thing to do, which probably gets obvious when taking a look at what that function does.) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-10-30 9:33 ` Gerd Moellmann @ 2003-10-30 10:46 ` Kenichi Handa 2003-10-30 16:27 ` Stefan Monnier 1 sibling, 0 replies; 15+ messages in thread From: Kenichi Handa @ 2003-10-30 10:46 UTC (permalink / raw) Cc: rms, emacs-devel In article <86k76njcj4.fsf@gerd.free-bsd.org>, gerd.moellmann@t-online.de (Gerd Moellmann) writes: >> I found that the above is not enough. It seems that the >> display engine doesn't issue select-frame; i.e. provided >> that there are two frames A and B, there is a case that the >> display engine redisplays A while the selected frame is B. >> >> It means that even if we make such variables frame local >> that affect the redisplaying (font-selection, etc), any >> frame local bindings are just ignored. >> >> Gerd, do you remember this matter? Is my analysis correct? > I think so; it matches what I remember. Local bindings are not > supported for all redisplay variables. AFAIR, that has always > been the case and isn't new in 21. I see, thank you. > Where it is supported, I think redisplay looks at frame > parameters. Yes, I noticed several Fassq (Qxxx, f->param_alist) in xfaces.c and xdisp.c. I think we must do the similar thing for variables that affect font selection. > (BTW, calling select-frame in redisplay would almost certainly not be > the right thing to do, which probably gets obvious when taking a look > at what that function does.) It seems so. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-10-30 9:33 ` Gerd Moellmann 2003-10-30 10:46 ` Kenichi Handa @ 2003-10-30 16:27 ` Stefan Monnier 2003-10-30 19:33 ` Gerd Moellmann 1 sibling, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2003-10-30 16:27 UTC (permalink / raw) Cc: emacs-devel, rms, Kenichi Handa > (BTW, calling select-frame in redisplay would almost certainly not be > the right thing to do, which probably gets obvious when taking a look > at what that function does.) How about calling a select_frame_internal_for_variables_only ? Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-10-30 16:27 ` Stefan Monnier @ 2003-10-30 19:33 ` Gerd Moellmann 2003-11-10 1:05 ` Kenichi Handa 0 siblings, 1 reply; 15+ messages in thread From: Gerd Moellmann @ 2003-10-30 19:33 UTC (permalink / raw) Cc: emacs-devel, rms, Kenichi Handa Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > > (BTW, calling select-frame in redisplay would almost certainly not be > > the right thing to do, which probably gets obvious when taking a look > > at what that function does.) > > How about calling a select_frame_internal_for_variables_only ? To swap frame-local bindings into C variables, I suppose? That would be the alternative to searching in frame parameters, yes. I guess it's even better than assq, because it's more general, although it might do a little bit more work than strictly necessary. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-10-30 19:33 ` Gerd Moellmann @ 2003-11-10 1:05 ` Kenichi Handa 2003-11-10 10:35 ` Gerd Moellmann 0 siblings, 1 reply; 15+ messages in thread From: Kenichi Handa @ 2003-11-10 1:05 UTC (permalink / raw) Cc: monnier, rms, emacs-devel In article <86oevy1pxp.fsf@gerd.free-bsd.org>, gerd.moellmann@t-online.de (Gerd Moellmann) writes: > Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> > (BTW, calling select-frame in redisplay would almost certainly not be >> > the right thing to do, which probably gets obvious when taking a look >> > at what that function does.) >> >> How about calling a select_frame_internal_for_variables_only ? That seems to be a good idea. But, as I'm quite unfamiliar with how frame-local variables are implemented, I don't know how to write such a funciton. I would very much appreciate if someone else implements it. I found this code in redisplay_window (xdisp.c). /* Really select the buffer, for the sake of buffer-local variables. */ set_buffer_internal_1 (XBUFFER (w->buffer)); Perhaps, we should call select_frame_internal_for_variables_only around there. > To swap frame-local bindings into C variables, I suppose? That would > be the alternative to searching in frame parameters, yes. I guess > it's even better than assq, because it's more general, although it > might do a little bit more work than strictly necessary. I think that "a little bit more work" is negligible because the display engine already does "set-buffer" as above. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-11-10 1:05 ` Kenichi Handa @ 2003-11-10 10:35 ` Gerd Moellmann 2003-11-11 8:38 ` Kenichi Handa 0 siblings, 1 reply; 15+ messages in thread From: Gerd Moellmann @ 2003-11-10 10:35 UTC (permalink / raw) Cc: emacs-devel, monnier, rms Kenichi Handa <handa@m17n.org> writes: > I found this code in redisplay_window (xdisp.c). > > /* Really select the buffer, for the sake of buffer-local > variables. */ > set_buffer_internal_1 (XBUFFER (w->buffer)); > > Perhaps, we should call > select_frame_internal_for_variables_only around there. I think the best place is in redisplay_internal, which redisplays frame by frame. Otherwise, we'd end up doing this for each window on a frame again and again. I can't work on this, but maybe this is helpful: void select_frame_for_redisplay (Lisp_Object frame) { Lisp_Object tail, sym, val; selected_frame = frame; for (tail = XFRAME (frame)->param_alist; CONSP (tail); tail = XCDR (tail)) if (CONSP (XCAR (tail)) && (sym = XCAR (XCAR (tail)), SYMBOLP (sym)) && (sym = indirect_variable (sym), val = SYMBOL_VALUE (sym), (BUFFER_LOCAL_VALUEP (val) || SOME_BUFFER_LOCAL_VALUEP (val))) && XBUFFER_LOCAL_VALUE (val)->check_frame) Fsymbol_value (sym); } This works analogous to what set_buffer does for buffer-local variables (hopefully; I haven't tried anything): For all frame parameters P, check if a frame-local variable P exists. If so, swap P's value in by calling Fsymbol_value. That works because the innards of Fsymbol_value compare the frame recorded in the local value with the currently selected frame. In redisplay_internal, call the function with the frame being displayed, and in an unwind-protect handler (I think there is already one), call it to restore the original selected frame and its values. HTH ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-11-10 10:35 ` Gerd Moellmann @ 2003-11-11 8:38 ` Kenichi Handa 2003-11-12 20:02 ` Richard Stallman 0 siblings, 1 reply; 15+ messages in thread From: Kenichi Handa @ 2003-11-11 8:38 UTC (permalink / raw) Cc: emacs-devel, monnier, rms In article <863ccwjysw.fsf@gerd.free-bsd.org>, gerd.moellmann@t-online.de (Gerd Moellmann) writes: >> Perhaps, we should call >> select_frame_internal_for_variables_only around there. > I think the best place is in redisplay_internal, which redisplays > frame by frame. Otherwise, we'd end up doing this for each window > on a frame again and again. > I can't work on this, but maybe this is helpful: > void > select_frame_for_redisplay (Lisp_Object frame) > { > Lisp_Object tail, sym, val; [...] Thank you very much for the help. I'm now using the attached patch. It seems that frame-local variables are handled correctly. Richard, what do you think about this change. Shall I install it? --- Ken'ichi HANDA handa@m17n.org *** xdisp.c.~1.849.~ Mon Oct 13 11:25:49 2003 --- xdisp.c Tue Nov 11 17:24:48 2003 *************** *** 814,819 **** --- 814,820 ---- static void push_it P_ ((struct it *)); static void pop_it P_ ((struct it *)); static void sync_frame_with_window_matrix_rows P_ ((struct window *)); + static void select_frame_for_redisplay P_ ((Lisp_Object)); static void redisplay_internal P_ ((int)); static int echo_area_display P_ ((int)); static void redisplay_windows P_ ((Lisp_Object)); *************** *** 9542,9547 **** --- 9543,9586 ---- } } \f + + /* Select FRAME to forward the values of frame-local variables into C + variables so that the redisplay routines can access those values + directly. */ + + static void + select_frame_for_redisplay (frame) + Lisp_Object frame; + { + Lisp_Object tail, sym, val; + Lisp_Object old = selected_frame; + + selected_frame = frame; + + for (tail = XFRAME (frame)->param_alist; CONSP (tail); tail = XCDR (tail)) + if (CONSP (XCAR (tail)) + && (sym = XCAR (XCAR (tail)), + SYMBOLP (sym)) + && (sym = indirect_variable (sym), + val = SYMBOL_VALUE (sym), + (BUFFER_LOCAL_VALUEP (val) + || SOME_BUFFER_LOCAL_VALUEP (val))) + && XBUFFER_LOCAL_VALUE (val)->check_frame) + Fsymbol_value (sym); + + for (tail = XFRAME (old)->param_alist; CONSP (tail); tail = XCDR (tail)) + if (CONSP (XCAR (tail)) + && (sym = XCAR (XCAR (tail)), + SYMBOLP (sym)) + && (sym = indirect_variable (sym), + val = SYMBOL_VALUE (sym), + (BUFFER_LOCAL_VALUEP (val) + || SOME_BUFFER_LOCAL_VALUEP (val))) + && XBUFFER_LOCAL_VALUE (val)->check_frame) + Fsymbol_value (sym); + } + + #define STOP_POLLING \ do { if (! polling_stopped_here) stop_polling (); \ polling_stopped_here = 1; } while (0) *************** *** 9607,9613 **** /* Record a function that resets redisplaying_p to its old value when we leave this function. */ count = SPECPDL_INDEX (); ! record_unwind_protect (unwind_redisplay, make_number (redisplaying_p)); ++redisplaying_p; specbind (Qinhibit_free_realized_faces, Qnil); --- 9646,9653 ---- /* Record a function that resets redisplaying_p to its old value when we leave this function. */ count = SPECPDL_INDEX (); ! record_unwind_protect (unwind_redisplay, ! Fcons (make_number (redisplaying_p), selected_frame)); ++redisplaying_p; specbind (Qinhibit_free_realized_faces, Qnil); *************** *** 10021,10026 **** --- 10061,10071 ---- if (FRAME_WINDOW_P (f) || f == sf) { + if (! EQ (frame, selected_frame)) + /* Select the frame, for the sake of frame-local + variables. */ + select_frame_for_redisplay (frame); + #ifdef HAVE_WINDOW_SYSTEM if (clear_face_cache_count % 50 == 0 && FRAME_WINDOW_P (f)) *************** *** 10273,10285 **** /* Function registered with record_unwind_protect in redisplay_internal. Reset redisplaying_p to the value it had before redisplay_internal was called, and clear ! prevent_freeing_realized_faces_p. */ static Lisp_Object ! unwind_redisplay (old_redisplaying_p) ! Lisp_Object old_redisplaying_p; { redisplaying_p = XFASTINT (old_redisplaying_p); return Qnil; } --- 10318,10337 ---- /* Function registered with record_unwind_protect in redisplay_internal. Reset redisplaying_p to the value it had before redisplay_internal was called, and clear ! prevent_freeing_realized_faces_p. It also selects the previously ! selected frame. */ static Lisp_Object ! unwind_redisplay (val) ! Lisp_Object val; { + Lisp_Object old_redisplaying_p, old_frame; + + old_redisplaying_p = XCAR (val); redisplaying_p = XFASTINT (old_redisplaying_p); + old_frame = XCDR (val); + if (! EQ (old_frame, selected_frame)) + select_frame_for_redisplay (old_frame); return Qnil; } ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-11-11 8:38 ` Kenichi Handa @ 2003-11-12 20:02 ` Richard Stallman 2003-11-13 0:42 ` Kenichi Handa 0 siblings, 1 reply; 15+ messages in thread From: Richard Stallman @ 2003-11-12 20:02 UTC (permalink / raw) Cc: gerd.moellmann, monnier, emacs-devel Thank you very much for the help. I'm now using the attached patch. It seems that frame-local variables are handled correctly. Richard, what do you think about this change. Shall I install it? It looks good to me. Please install it. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-11-12 20:02 ` Richard Stallman @ 2003-11-13 0:42 ` Kenichi Handa 2003-11-13 4:14 ` Richard Stallman 0 siblings, 1 reply; 15+ messages in thread From: Kenichi Handa @ 2003-11-13 0:42 UTC (permalink / raw) Cc: gerd.moellmann, monnier, emacs-devel In article <E1AK1Bu-0005CG-J0@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes: > Thank you very much for the help. I'm now using the > attached patch. It seems that frame-local variables are > handled correctly. > Richard, what do you think about this change. Shall I > install it? > It looks good to me. Please install it. I'll install it as soon as savannah is recovered. savannah doesn't respond now. Does someone have information about that? --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-11-13 0:42 ` Kenichi Handa @ 2003-11-13 4:14 ` Richard Stallman 2003-11-13 4:32 ` Kenichi Handa 0 siblings, 1 reply; 15+ messages in thread From: Richard Stallman @ 2003-11-13 4:14 UTC (permalink / raw) Cc: gerd.moellmann, monnier, emacs-devel If there is a problem with Savannah, please write to savannah-hackers@gnu.org. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: question about frame local variable 2003-11-13 4:14 ` Richard Stallman @ 2003-11-13 4:32 ` Kenichi Handa 0 siblings, 0 replies; 15+ messages in thread From: Kenichi Handa @ 2003-11-13 4:32 UTC (permalink / raw) Cc: gerd.moellmann, monnier, emacs-devel In article <E1AK8s2-0002fg-Je@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes: > If there is a problem with Savannah, please write to savannah-hackers@gnu.org. I was actually going to write to them, but before I hit C-c C-c, it started to work again. So, the patch for frame-local variables was already installed. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2003-11-13 4:32 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-10-25 0:49 question about frame local variable Kenichi Handa 2003-10-26 11:46 ` Richard Stallman 2003-10-28 8:03 ` Kenichi Handa 2003-10-30 1:35 ` Kenichi Handa 2003-10-30 9:33 ` Gerd Moellmann 2003-10-30 10:46 ` Kenichi Handa 2003-10-30 16:27 ` Stefan Monnier 2003-10-30 19:33 ` Gerd Moellmann 2003-11-10 1:05 ` Kenichi Handa 2003-11-10 10:35 ` Gerd Moellmann 2003-11-11 8:38 ` Kenichi Handa 2003-11-12 20:02 ` Richard Stallman 2003-11-13 0:42 ` Kenichi Handa 2003-11-13 4:14 ` Richard Stallman 2003-11-13 4:32 ` Kenichi Handa
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.