all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* slow make-frame + face initialization / importing x resources
@ 2007-07-13 17:55 David Reitter
  2007-07-13 23:08 ` Richard Stallman
  0 siblings, 1 reply; 19+ messages in thread
From: David Reitter @ 2007-07-13 17:55 UTC (permalink / raw)
  To: emacs- devel

I wonder if something can be done about the very slow `make-frame'.

Make-frame creates a frame-local copy of each face defined, and when  
you have a couple of faces defined for various modes, just a modest  
number of them (I have 700, defined with color-theme) will slow down  
frame creation to a point where it's just not tolerable any more.

Here's a bit of code to demonstrate the effect (with just "empty'  
faces):

(require 'cl)
(loop for X from 0 to 2000 do
       (make-face (intern (format "face%s" X))))
(let ((ti (current-time)))
   (loop for X from 0 to 10 do
	(make-frame))
   (print (format-time-string "%S" (time-since ti))))

The problem seems to be due to `x-create-frame-with-faces',  
specifically this form:

(dolist (face (delq 'default (face-list)))
       (condition-case ()
	  (progn
	    (face-spec-set face (face-user-default-spec face) frame)
	    (if (memq window-system '(x w32 mac))
		(make-face-x-resource-internal face frame))
	    (internal-merge-in-global-face face frame))
	(error nil)))

Frame creation time improves tremendously when I take out that call  
to `make-face-x-resource-internal'.
Is the import of x-resources necessary on Mac and Windows?
Also, is it necessary to do that every time a frame is created?  
Couldn't they be imported once at startup time?

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-13 17:55 slow make-frame + face initialization / importing x resources David Reitter
@ 2007-07-13 23:08 ` Richard Stallman
  2007-07-14  1:21   ` Stefan Monnier
  2007-07-14  1:55   ` Stefan Monnier
  0 siblings, 2 replies; 19+ messages in thread
From: Richard Stallman @ 2007-07-13 23:08 UTC (permalink / raw)
  To: David Reitter; +Cc: emacs-devel

    Frame creation time improves tremendously when I take out that call  
    to `make-face-x-resource-internal'.
    Is the import of x-resources necessary on Mac and Windows?

I think it has to be done when the frame is created
because there is no chance to do it later.
Any of the faces used could be displayed in that frame
at any time.  And only the inner guts of redisplay will
notice when a face is first used in the frame.

Is it safe to set up the face for the frame
when it is first used in the frame?

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-13 23:08 ` Richard Stallman
@ 2007-07-14  1:21   ` Stefan Monnier
  2007-07-14 22:32     ` Richard Stallman
  2007-07-14  1:55   ` Stefan Monnier
  1 sibling, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2007-07-14  1:21 UTC (permalink / raw)
  To: rms; +Cc: David Reitter, emacs-devel

>     Frame creation time improves tremendously when I take out that call  
>     to `make-face-x-resource-internal'.
>     Is the import of x-resources necessary on Mac and Windows?

> I think it has to be done when the frame is created
> because there is no chance to do it later.

How 'bout doing it earlier: i.e. share faces between all similar frames?


        Stefan

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-13 23:08 ` Richard Stallman
  2007-07-14  1:21   ` Stefan Monnier
@ 2007-07-14  1:55   ` Stefan Monnier
  2007-07-14 20:53     ` David Reitter
  1 sibling, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2007-07-14  1:55 UTC (permalink / raw)
  To: rms; +Cc: David Reitter, emacs-devel

>     Frame creation time improves tremendously when I take out that call  
>     to `make-face-x-resource-internal'.
>     Is the import of x-resources necessary on Mac and Windows?

> I think it has to be done when the frame is created
> because there is no chance to do it later.

What if there are no face specifications in the X resources?

The current code checks every possible X resource setting for every face.
Why not list the resources instead and interpret them?
[ At least in my case it would probbaly be much faster since I shouldn't
have any settings in there]


        Stefan

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-14  1:55   ` Stefan Monnier
@ 2007-07-14 20:53     ` David Reitter
  2007-07-14 21:28       ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: David Reitter @ 2007-07-14 20:53 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: rms, emacs-devel

On 14 Jul 2007, at 02:55, Stefan Monnier wrote:

> The current code checks every possible X resource setting for every  
> face.
> Why not list the resources instead and interpret them?
> [ At least in my case it would probbaly be much faster since I  
> shouldn't
> have any settings in there]

Sounds like a good idea.  Almost all the time is spent on importing  
those X resources. I commented this out and it seems to work just  
fine for me (no X).
On Mac and Windows window systems, is there a reason why X resources  
should be supported in the first place?

Sharing the faces between frames would be good to. Can faces be  
deleted? No? This is probably why more and more faces accumulate over  
time (when you use something like color-theme, e.g.). What is the  
memory footprint of a single frame then?

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-14 20:53     ` David Reitter
@ 2007-07-14 21:28       ` Eli Zaretskii
  2007-07-15  1:29         ` Stefan Monnier
                           ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Eli Zaretskii @ 2007-07-14 21:28 UTC (permalink / raw)
  To: David Reitter; +Cc: emacs-devel

> From: David Reitter <david.reitter@gmail.com>
> Date: Sat, 14 Jul 2007 21:53:38 +0100
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> On Mac and Windows window systems, is there a reason why X resources  
> should be supported in the first place?

I don't understand the question.  The Windows port reads X resources
from the Registry; why shouldn't we support that?

> Sharing the faces between frames would be good to.

What kind of sharing do you have in mind?  Faces are frame-specific,
so changing a face generally affects only the frame for which it is
changed.  If the suggested sharing will defeat this, I don't think
it's a good idea.

> Can faces be deleted? No? This is probably why more and more faces
> accumulate over time (when you use something like color-theme,
> e.g.).

If color-theme blindly adds faces instead of modifying existing ones,
then yes.  Does it actually do that?

> What is the memory footprint of a single frame then?

See struct frame defined on frame.h, but some of its members have
variable length.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-14  1:21   ` Stefan Monnier
@ 2007-07-14 22:32     ` Richard Stallman
  0 siblings, 0 replies; 19+ messages in thread
From: Richard Stallman @ 2007-07-14 22:32 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: david.reitter, emacs-devel

    > I think it has to be done when the frame is created
    > because there is no chance to do it later.

    How 'bout doing it earlier: i.e. share faces between all similar frames?

If there were no such thing as the functions set-face-XYZ, that would
work.  Those functions can be used to specify face attributes in a
single frame.  If you copy the faces from another similar frame, then
you'd get the wrong results if those functions were previously used to
change certain faces in that frame.

It could be that those functions are not a very useful feature
and should be eliminated.  We can ask whether any Lisp packages
outside Emacs really use them.

Another problem case is where you reevaluate an edited defface.
What was right on a similar frame now is not going to be right
in the future.

I am sure it is possible to take account of these things in
implementing new face initialization code.

    The current code checks every possible X resource setting for every face.
    Why not list the resources instead and interpret them?

That is true, but you still face the issues listed above
if you want to copy face attributes from another frame.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-14 21:28       ` Eli Zaretskii
@ 2007-07-15  1:29         ` Stefan Monnier
  2007-07-15 13:50           ` Jan Djärv
  2007-07-15 22:53           ` Richard Stallman
  2007-07-15  8:26         ` Juanma Barranquero
  2007-07-15  9:35         ` David Reitter
  2 siblings, 2 replies; 19+ messages in thread
From: Stefan Monnier @ 2007-07-15  1:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: David Reitter, emacs-devel

>> Sharing the faces between frames would be good to.
> What kind of sharing do you have in mind?  Faces are frame-specific,
> so changing a face generally affects only the frame for which it is
> changed.  If the suggested sharing will defeat this, I don't think
> it's a good idea.

I'm thinking of doing ref-counts and COW, so by default, if the new frame is
similar (e.g. on the same screen with the "same" frame parameters), so the
faces are inherited.  They can later get unshared if needed.

In typical usage patterns most frames are identical w.r.t faces and all
face-modification are applied uniformly to (almost) all frames.  So it should
be a valuable optimization.


        Stefan

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-14 21:28       ` Eli Zaretskii
  2007-07-15  1:29         ` Stefan Monnier
@ 2007-07-15  8:26         ` Juanma Barranquero
  2007-07-15  9:35         ` David Reitter
  2 siblings, 0 replies; 19+ messages in thread
From: Juanma Barranquero @ 2007-07-15  8:26 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: David Reitter, emacs-devel

On 7/14/07, Eli Zaretskii <eliz@gnu.org> wrote:

> The Windows port reads X resources
> from the Registry;

And command line, with -xrm.

             Juanma

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-14 21:28       ` Eli Zaretskii
  2007-07-15  1:29         ` Stefan Monnier
  2007-07-15  8:26         ` Juanma Barranquero
@ 2007-07-15  9:35         ` David Reitter
  2007-07-15 20:10           ` chad brown
                             ` (2 more replies)
  2 siblings, 3 replies; 19+ messages in thread
From: David Reitter @ 2007-07-15  9:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

On 14 Jul 2007, at 22:28, Eli Zaretskii wrote:

>> On Mac and Windows window systems, is there a reason why X resources
>> should be supported in the first place?
>
> I don't understand the question.  The Windows port reads X resources
> from the Registry; why shouldn't we support that?

Does the Windows port also save such settings to the registry, or are  
users meant to write thesis settings there manually?
The Carbon port reads such resources from a special .plist file, but  
it's unclear to me, why. Users would have to manipulate that (XML)  
file externally, and I don't understand how this would be easier or  
more sensible than configuring Emacs through the customization  
or .emacs interfaces.

> What kind of sharing do you have in mind?  Faces are frame-specific,
> so changing a face generally affects only the frame for which it is
> changed.  If the suggested sharing will defeat this, I don't think
> it's a good idea.

Share by default, but copy as soon as the face is changed. Stefan has  
described this in more detail.

> If color-theme blindly adds faces instead of modifying existing ones,
> then yes.  Does it actually do that?

It adds faces for all sorts of modes, whether you use those modes or  
not. That's how I have some 700 faces defined from just a couple of  
themes.
(I use different themes to visually distinguish frames depending on  
the major mode of the buffer that they display.)

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-15  1:29         ` Stefan Monnier
@ 2007-07-15 13:50           ` Jan Djärv
  2007-07-15 14:07             ` David Kastrup
  2007-07-15 22:54             ` Richard Stallman
  2007-07-15 22:53           ` Richard Stallman
  1 sibling, 2 replies; 19+ messages in thread
From: Jan Djärv @ 2007-07-15 13:50 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: David Reitter, Eli Zaretskii, emacs-devel



Stefan Monnier skrev:
>>> Sharing the faces between frames would be good to.
>> What kind of sharing do you have in mind?  Faces are frame-specific,
>> so changing a face generally affects only the frame for which it is
>> changed.  If the suggested sharing will defeat this, I don't think
>> it's a good idea.
> 
> I'm thinking of doing ref-counts and COW, so by default, if the new frame is
> similar (e.g. on the same screen with the "same" frame parameters), so the
> faces are inherited.  They can later get unshared if needed.
> 

What if X resources changed between creation of the first and second frame?

	Jan D.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-15 13:50           ` Jan Djärv
@ 2007-07-15 14:07             ` David Kastrup
  2007-07-15 22:02               ` Jan Djärv
  2007-07-15 22:54             ` Richard Stallman
  1 sibling, 1 reply; 19+ messages in thread
From: David Kastrup @ 2007-07-15 14:07 UTC (permalink / raw)
  To: Jan Djärv; +Cc: David Reitter, Eli Zaretskii, Stefan Monnier, emacs-devel

Jan Djärv <jan.h.d@swipnet.se> writes:

> Stefan Monnier skrev:
>>>> Sharing the faces between frames would be good to.
>>> What kind of sharing do you have in mind?  Faces are frame-specific,
>>> so changing a face generally affects only the frame for which it is
>>> changed.  If the suggested sharing will defeat this, I don't think
>>> it's a good idea.
>>
>> I'm thinking of doing ref-counts and COW, so by default, if the new frame is
>> similar (e.g. on the same screen with the "same" frame parameters), so the
>> faces are inherited.  They can later get unshared if needed.
>>
>
> What if X resources changed between creation of the first and second frame?

What if?  We don't track the changes of X resources in real-time for
the first frame, so what problem is there in not tracking them between
frames?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-15  9:35         ` David Reitter
@ 2007-07-15 20:10           ` chad brown
  2007-07-15 22:08             ` David Reitter
  2007-07-16  1:40           ` Stefan Monnier
  2007-07-16  3:19           ` Eli Zaretskii
  2 siblings, 1 reply; 19+ messages in thread
From: chad brown @ 2007-07-15 20:10 UTC (permalink / raw)
  To: David Reitter; +Cc: Eli Zaretskii, emacs-devel

I believe that the Mac carbon port, at least, reads (pseudo) X  
resources to deal with customization before .emacs; specifically, so  
that windows can be graphically configured before mapped (which can  
result in ugly/annoying flashing, for example).

This points at a possible rethinking of ordering for starting,  
configuration, and window mapping, especially in light of the extra  
versatility of the multi-tty branch.  Of course, I'm not familiar  
with this part of emacs, so maybe the existing methods are already  
adequate, and I'm just ignorant of them.  Hmm...  I'll have to take a  
look at that again.

*chad


On Jul 15, 2007, at 2:35 AM, David Reitter wrote:

> The Carbon port reads such resources from a special .plist file,  
> but it's unclear to me, why. Users would have to manipulate that  
> (XML) file externally, and I don't understand how this would be  
> easier or more sensible than configuring Emacs through the  
> customization or .emacs interfaces.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-15 14:07             ` David Kastrup
@ 2007-07-15 22:02               ` Jan Djärv
  0 siblings, 0 replies; 19+ messages in thread
From: Jan Djärv @ 2007-07-15 22:02 UTC (permalink / raw)
  To: David Kastrup; +Cc: David Reitter, Eli Zaretskii, Stefan Monnier, emacs-devel



David Kastrup skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Stefan Monnier skrev:
>>>>> Sharing the faces between frames would be good to.
>>>> What kind of sharing do you have in mind?  Faces are frame-specific,
>>>> so changing a face generally affects only the frame for which it is
>>>> changed.  If the suggested sharing will defeat this, I don't think
>>>> it's a good idea.
>>> I'm thinking of doing ref-counts and COW, so by default, if the new frame is
>>> similar (e.g. on the same screen with the "same" frame parameters), so the
>>> faces are inherited.  They can later get unshared if needed.
>>>
>> What if X resources changed between creation of the first and second frame?
> 
> What if?  We don't track the changes of X resources in real-time for
> the first frame, so what problem is there in not tracking them between
> frames?

Not a problem, but it is a change of behaviour.  If we do this change, we 
should make sure X resources are read only once.

	Jan D.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-15 20:10           ` chad brown
@ 2007-07-15 22:08             ` David Reitter
  0 siblings, 0 replies; 19+ messages in thread
From: David Reitter @ 2007-07-15 22:08 UTC (permalink / raw)
  To: chad brown; +Cc: Eli Zaretskii, emacs-devel

On 15 Jul 2007, at 21:10, chad brown wrote:

> I believe that the Mac carbon port, at least, reads (pseudo) X  
> resources to deal with customization before .emacs; specifically,  
> so that windows can be graphically configured before mapped (which  
> can result in ugly/annoying flashing, for example).

For what it's worth, here's a patch from Aquamacs which avoids  
flashing/resizing. The initial frame is invisible, and only after the  
site- and user-specific settings are loaded, this frame is made  
visible. (In case of errors, the frame is made visible, too, of course.)





Index: lisp/startup.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/startup.el,v
retrieving revision 1.368
diff -c -r1.368 startup.el
*** lisp/startup.el	15 Jul 2005 14:47:06 -0000	1.368
--- lisp/startup.el	17 Jul 2005 22:07:56 -0000
***************
*** 463,469 ****
   		  (if (string-match "^\\(xterm\\|rxvt\\|dtterm\\|eterm\\)"
   				    term)
   		      (setq default-frame-background-mode 'light)))
! 		(frame-set-background-mode (selected-frame)))))

   	;; Now we know the user's default font, so add it to the menu.
   	(if (fboundp 'font-menu-add-default)
--- 463,472 ----
   		  (if (string-match "^\\(xterm\\|rxvt\\|dtterm\\|eterm\\)"
   				    term)
   		      (setq default-frame-background-mode 'light)))
! 		(frame-set-background-mode (selected-frame))))
!
! 	  ;; time to make the frame visible (Aquamacs)
! 	  (make-frame-visible))

   	;; Now we know the user's default font, so add it to the menu.
   	(if (fboundp 'font-menu-add-default)
***************
*** 721,726 ****
--- 724,732 ----
       (and command-line-args
            (setcdr command-line-args args)))

+   ;; the initial frame is hidden in Aquamacs
+   (setq initial-frame-alist (cons '(visibility . nil) initial-frame- 
alist))
+
     ;; Under X Window, this creates the X frame and deletes the  
terminal frame.
     (when (fboundp 'frame-initialize)
       (frame-initialize))
***************
*** 1730,1735 ****
--- 1736,1744 ----
       ;; keystroke, and that's distracting.
       (when (fboundp 'frame-notice-user-settings)
         (frame-notice-user-settings))
+
+     ;; time to make the frame visible (Aquamacs)
+     (make-frame-visible)

       ;; If there are no switches to process, we might as well
       ;; run this hook now, and there may be some need to do it

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-15  1:29         ` Stefan Monnier
  2007-07-15 13:50           ` Jan Djärv
@ 2007-07-15 22:53           ` Richard Stallman
  1 sibling, 0 replies; 19+ messages in thread
From: Richard Stallman @ 2007-07-15 22:53 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: david.reitter, eliz, emacs-devel

    I'm thinking of doing ref-counts and COW, 

Will your cow orkers offer any help in implementing this?

					      so by default, if the new frame is
    similar (e.g. on the same screen with the "same" frame parameters), so the
    faces are inherited.  They can later get unshared if needed.

If you're willing to redesign that much, I am sure you can make it
work.  While you are at it, you might be able to reduce the number
of levels of data structure that we have for faces.  That would
make things simpler and easier to maintain.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-15 13:50           ` Jan Djärv
  2007-07-15 14:07             ` David Kastrup
@ 2007-07-15 22:54             ` Richard Stallman
  1 sibling, 0 replies; 19+ messages in thread
From: Richard Stallman @ 2007-07-15 22:54 UTC (permalink / raw)
  To: Jan Djärv; +Cc: david.reitter, eliz, monnier, emacs-devel

    What if X resources changed between creation of the first and second frame?

I think Emacs keeps its own list of X resources internally.
(I am not certain -- I never studied the code in xrdb.c carefully.)
So Emacs ought to be able to tell when to consider new values.

With the sort of redesign that Stefan proposed, it is surely possible
to DTRT for any relevant factors there may be.  It was only the amount
of work involved in this that made me hesitate.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-15  9:35         ` David Reitter
  2007-07-15 20:10           ` chad brown
@ 2007-07-16  1:40           ` Stefan Monnier
  2007-07-16  3:19           ` Eli Zaretskii
  2 siblings, 0 replies; 19+ messages in thread
From: Stefan Monnier @ 2007-07-16  1:40 UTC (permalink / raw)
  To: David Reitter; +Cc: Eli Zaretskii, emacs-devel

> The Carbon port reads such resources from a special .plist file, but it's
> unclear to me, why. Users would have to manipulate that (XML) file
> externally, and I don't understand how this would be easier or more
> sensible than configuring Emacs through the customization or
> .emacs interfaces.

I believe the advantage is that those X resource settings are applied before
the first frame is created, whereas those in .emacs are applied afterwards,
leading to transient artifacts.


        Stefan

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: slow make-frame + face initialization / importing x resources
  2007-07-15  9:35         ` David Reitter
  2007-07-15 20:10           ` chad brown
  2007-07-16  1:40           ` Stefan Monnier
@ 2007-07-16  3:19           ` Eli Zaretskii
  2 siblings, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2007-07-16  3:19 UTC (permalink / raw)
  To: David Reitter; +Cc: emacs-devel

> Cc: emacs-devel@gnu.org
> From: David Reitter <david.reitter@gmail.com>
> Date: Sun, 15 Jul 2007 10:35:59 +0100
> 
> Does the Windows port also save such settings to the registry, or are  
> users meant to write thesis settings there manually?

I don't think Emacs saves the settings to the Registry, but maybe I
don't understand the question--what Emacs interface saves X resources
on Unix?

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2007-07-16  3:19 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-13 17:55 slow make-frame + face initialization / importing x resources David Reitter
2007-07-13 23:08 ` Richard Stallman
2007-07-14  1:21   ` Stefan Monnier
2007-07-14 22:32     ` Richard Stallman
2007-07-14  1:55   ` Stefan Monnier
2007-07-14 20:53     ` David Reitter
2007-07-14 21:28       ` Eli Zaretskii
2007-07-15  1:29         ` Stefan Monnier
2007-07-15 13:50           ` Jan Djärv
2007-07-15 14:07             ` David Kastrup
2007-07-15 22:02               ` Jan Djärv
2007-07-15 22:54             ` Richard Stallman
2007-07-15 22:53           ` Richard Stallman
2007-07-15  8:26         ` Juanma Barranquero
2007-07-15  9:35         ` David Reitter
2007-07-15 20:10           ` chad brown
2007-07-15 22:08             ` David Reitter
2007-07-16  1:40           ` Stefan Monnier
2007-07-16  3:19           ` Eli Zaretskii

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.