unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).