* configure{.in,} question
@ 2010-10-24 17:31 Lars Magne Ingebrigtsen
2010-10-24 19:38 ` Glenn Morris
2010-10-25 19:11 ` Ted Zlatanov
0 siblings, 2 replies; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-10-24 17:31 UTC (permalink / raw
To: emacs-devel
I was going to remove the (BROKEN) from the gnutls conf option in
configure.in, but when I then said "autoconf" (aren't we supposed to
after all configure.in changes?), I got a somewhat big change in the
configure file, with lots gcc changes and stuff:
=== modified file 'configure'
*** configure 2010-10-12 21:03:09 +0000
--- configure 2010-10-24 17:26:15 +0000
***************
*** 5506,5524 ****
fi
! if test x$GCC = xyes && test "x$GCC_LINK_TEST_OPTIONS" != x
! then
! ac_link="$ac_link $GCC_LINK_TEST_OPTIONS"
! fi
!
! if test x$GCC = x && test "x$NON_GCC_LINK_TEST_OPTIONS" != x
! then
! ac_link="$ac_link $NON_GCC_LINK_TEST_OPTIONS"
fi
(bla bla)
Is this just somebody else who forgot to autoconf after previous
changes, or is my local autoconf doing odd things?
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-24 17:31 configure{.in,} question Lars Magne Ingebrigtsen
@ 2010-10-24 19:38 ` Glenn Morris
2010-10-24 19:56 ` Lars Magne Ingebrigtsen
2010-10-25 19:11 ` Ted Zlatanov
1 sibling, 1 reply; 22+ messages in thread
From: Glenn Morris @ 2010-10-24 19:38 UTC (permalink / raw
To: emacs-devel
Lars Magne Ingebrigtsen wrote:
> I was going to remove the (BROKEN) from the gnutls conf option in
> configure.in, but when I then said "autoconf" (aren't we supposed to
> after all configure.in changes?), I got a somewhat big change in the
> configure file, with lots gcc changes and stuff:
Big changes are expected if you use a different version of autoconf to
the previous guy. I try to use the same version always to avoid this.
> ! if test x$GCC = xyes && test "x$GCC_LINK_TEST_OPTIONS" != x
> ! then
> ! ac_link="$ac_link $GCC_LINK_TEST_OPTIONS"
> ! fi
> !
> ! if test x$GCC = x && test "x$NON_GCC_LINK_TEST_OPTIONS" != x
> ! then
> ! ac_link="$ac_link $NON_GCC_LINK_TEST_OPTIONS"
> fi
I did not bother regenerating configure for that change, since it
purely cosmetic.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-24 19:38 ` Glenn Morris
@ 2010-10-24 19:56 ` Lars Magne Ingebrigtsen
2010-10-24 20:07 ` Glenn Morris
0 siblings, 1 reply; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-10-24 19:56 UTC (permalink / raw
To: emacs-devel
Glenn Morris <rgm@gnu.org> writes:
> Big changes are expected if you use a different version of autoconf to
> the previous guy. I try to use the same version always to avoid this.
Hm. This line didn't change when I ran autoconf:
# Generated by GNU Autoconf 2.65 for emacs 24.0.50.
So I guess it's the same thing.
>> ! if test x$GCC = xyes && test "x$GCC_LINK_TEST_OPTIONS" != x
>> ! then
>> ! ac_link="$ac_link $GCC_LINK_TEST_OPTIONS"
>> ! fi
>> !
>> ! if test x$GCC = x && test "x$NON_GCC_LINK_TEST_OPTIONS" != x
>> ! then
>> ! ac_link="$ac_link $NON_GCC_LINK_TEST_OPTIONS"
>> fi
>
> I did not bother regenerating configure for that change, since it
> purely cosmetic.
So... I should just commit this, even though this has nothing to do
with the change I was making in configure.in?
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-24 19:56 ` Lars Magne Ingebrigtsen
@ 2010-10-24 20:07 ` Glenn Morris
2010-10-25 0:57 ` Stephen J. Turnbull
2010-10-25 8:47 ` Julien Danjou
0 siblings, 2 replies; 22+ messages in thread
From: Glenn Morris @ 2010-10-24 20:07 UTC (permalink / raw
To: emacs-devel
Lars Magne Ingebrigtsen wrote:
> Hm. This line didn't change when I ran autoconf:
>
> # Generated by GNU Autoconf 2.65 for emacs 24.0.50.
I don't know why you would get a "somewhat big" diff then, but don't
worry about it. Maybe nobody regenerated configure for a while. Or
sometimes eg Debian seems to have local patches to autoconf so that
their version behaves a bit differently to others with the same
version number.
> So... I should just commit this, even though this has nothing to do
> with the change I was making in configure.in?
Sure. Just describe it as "regenerate configure".
I have wondered whether configure even needs to be in the repository.
Here is something I wrote once but never bothered to send till now:
configure should be included in release tarfiles, but should it be
kept in the repository, or should just configure.in be there?
Problems causes by keeping configure in the repository:
1) Need for developers to regenerate it and check it in.
2) Often leads to large, meaningless diffs. For example, the merge of
the imagemagick branch had a diff of about 2500 lines. 1500 lines of
this were configure, and so totally meaningless.
Different developers using different versions of autoconf to generate
configure often leads to large diffs that bury the real change to
configure.in amongst noise. It's lead to the situation where AC_PREREQ
is artificially high, simply to try to stop this. I don't think this
is a good solution.
3) More problems with merges between branches, I imagine.
4) People in the habit of running autoconf are likely to end up with
conflicts when configure is updated.
5) ... ?
Advantages to keeping configure in the repository:
1) People don't need autoconf installed. I think this is a small
advantage, since autoconf is commonly present and easy to install.
2) The configure script gets more thorough testing (if is generated by
developers with a fixed version of autoconf and people don't
regenerate it).
3) ... ?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-24 20:07 ` Glenn Morris
@ 2010-10-25 0:57 ` Stephen J. Turnbull
2010-10-25 8:38 ` Andreas Schwab
2010-10-25 8:47 ` Julien Danjou
1 sibling, 1 reply; 22+ messages in thread
From: Stephen J. Turnbull @ 2010-10-25 0:57 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
Glenn Morris writes:
> Lars Magne Ingebrigtsen wrote:
>
> > Hm. This line didn't change when I ran autoconf:
> >
> > # Generated by GNU Autoconf 2.65 for emacs 24.0.50.
>
> I don't know why you would get a "somewhat big" diff then,
Because all the line numbers in the following error messages change,
most likely.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 0:57 ` Stephen J. Turnbull
@ 2010-10-25 8:38 ` Andreas Schwab
2010-10-25 14:43 ` Stephen J. Turnbull
0 siblings, 1 reply; 22+ messages in thread
From: Andreas Schwab @ 2010-10-25 8:38 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: emacs-devel
"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> Glenn Morris writes:
> > Lars Magne Ingebrigtsen wrote:
> >
> > > Hm. This line didn't change when I ran autoconf:
> > >
> > > # Generated by GNU Autoconf 2.65 for emacs 24.0.50.
> >
> > I don't know why you would get a "somewhat big" diff then,
>
> Because all the line numbers in the following error messages change,
> most likely.
Which line numbers?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-24 20:07 ` Glenn Morris
2010-10-25 0:57 ` Stephen J. Turnbull
@ 2010-10-25 8:47 ` Julien Danjou
2010-10-25 9:00 ` Andreas Schwab
2010-10-25 9:15 ` Eli Zaretskii
1 sibling, 2 replies; 22+ messages in thread
From: Julien Danjou @ 2010-10-25 8:47 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
On Sun, Oct 24 2010, Glenn Morris wrote:
> I have wondered whether configure even needs to be in the repository.
Me too. Almost all project I know using which are using autoconf do not
store the configure file for obvious reasons you cited.
I really think it's bad practice to store that in the repository.
It's like you were storing .o files. :)
--
Julien Danjou
// ᐰ <julien@danjou.info> http://julien.danjou.info
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 8:47 ` Julien Danjou
@ 2010-10-25 9:00 ` Andreas Schwab
2010-10-25 9:15 ` Eli Zaretskii
1 sibling, 0 replies; 22+ messages in thread
From: Andreas Schwab @ 2010-10-25 9:00 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
Julien Danjou <julien@danjou.info> writes:
> It's like you were storing .o files. :)
Except that it is completely unlike.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 8:47 ` Julien Danjou
2010-10-25 9:00 ` Andreas Schwab
@ 2010-10-25 9:15 ` Eli Zaretskii
2010-10-25 16:06 ` Stefan Monnier
2010-10-25 16:43 ` Glenn Morris
1 sibling, 2 replies; 22+ messages in thread
From: Eli Zaretskii @ 2010-10-25 9:15 UTC (permalink / raw
To: Julien Danjou; +Cc: emacs-devel
> From: Julien Danjou <julien@danjou.info>
> Date: Mon, 25 Oct 2010 10:47:39 +0200
> Cc: emacs-devel@gnu.org
>
> On Sun, Oct 24 2010, Glenn Morris wrote:
>
> > I have wondered whether configure even needs to be in the repository.
>
> Me too. Almost all project I know using which are using autoconf do not
> store the configure file for obvious reasons you cited.
> I really think it's bad practice to store that in the repository.
But doing so makes sure everybody can run the configure script, even
if the version of Autoconf installed on the user's machine has some
bug that affects Emacs.
> It's like you were storing .o files. :)
Not like that at all. Not every generated file should be omitted. We
have other generated files in the repository, take a look at
admin/charsets and admin/unidata. There's nothing wrong with that,
really.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 8:38 ` Andreas Schwab
@ 2010-10-25 14:43 ` Stephen J. Turnbull
2010-10-25 14:58 ` Andreas Schwab
0 siblings, 1 reply; 22+ messages in thread
From: Stephen J. Turnbull @ 2010-10-25 14:43 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
Andreas Schwab writes:
> Which line numbers?
The self-referential ones.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 14:43 ` Stephen J. Turnbull
@ 2010-10-25 14:58 ` Andreas Schwab
2010-10-25 15:41 ` Stephen J. Turnbull
0 siblings, 1 reply; 22+ messages in thread
From: Andreas Schwab @ 2010-10-25 14:58 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: emacs-devel
"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> Andreas Schwab writes:
>
> > Which line numbers?
>
> The self-referential ones.
Can you expand?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 14:58 ` Andreas Schwab
@ 2010-10-25 15:41 ` Stephen J. Turnbull
0 siblings, 0 replies; 22+ messages in thread
From: Stephen J. Turnbull @ 2010-10-25 15:41 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
Andreas Schwab writes:
> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>
> > Andreas Schwab writes:
> >
> > > Which line numbers?
> >
> > The self-referential ones.
>
> Can you expand?
No, I let m4 do that for me.
More to the point. It used to be the case that autoconf (say 2.13)
would embed line number information like this:
#line 1775 "configure"
and those numbers would change if you added or removed code in
configure.in. Evidently I haven't done a diff on configure in over 5
years, but the memory of that pain is still fresh. :-)
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 9:15 ` Eli Zaretskii
@ 2010-10-25 16:06 ` Stefan Monnier
2010-10-25 18:04 ` Eli Zaretskii
2010-10-25 16:43 ` Glenn Morris
1 sibling, 1 reply; 22+ messages in thread
From: Stefan Monnier @ 2010-10-25 16:06 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Julien Danjou, emacs-devel
> Not like that at all. Not every generated file should be omitted. We
> have other generated files in the repository, take a look at
> admin/charsets and admin/unidata. There's nothing wrong with that,
> really.
Actually, storing generated files is always a source of annoyances.
For files that change very rarely, like the unicode char data, this is
not too problematic, but I often end up with problems because of
configure and src/config.in. I worked around most of those problems in
my local branch by "bzr mv"ing those files to a "junk" directory.
Of course, there are yet other generated files which change somewhat
often but that we need for bootstrapping reasons.
This said, I'd be happy to try and move all those generated files to
some auxiliary place, so as to better balance the conflict between "we
want to have them to make installation easier and bootstrap possible"
and "we don't want to store generated files, to avoid conflicts".
We already do that with lisp/loaddefs.el (whose bootstrap version is in
lisp/ldefs-boot.el), but maybe a more generic approach would be
desirable.
Even better would be if Bzr provided support for such things.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 9:15 ` Eli Zaretskii
2010-10-25 16:06 ` Stefan Monnier
@ 2010-10-25 16:43 ` Glenn Morris
1 sibling, 0 replies; 22+ messages in thread
From: Glenn Morris @ 2010-10-25 16:43 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Julien Danjou, emacs-devel
Eli Zaretskii wrote:
> But doing so makes sure everybody can run the configure script, even
> if the version of Autoconf installed on the user's machine has some
> bug that affects Emacs.
If we are aware of such problems, that is a legitimate reason to set
AC_PREREQ in configure.in to avoid those versions of autoconf.
We have done this in the past, although AFAIK the current prereq is
artificially high simply to stop version churn.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 16:06 ` Stefan Monnier
@ 2010-10-25 18:04 ` Eli Zaretskii
2010-10-25 18:37 ` Glenn Morris
2010-10-25 19:34 ` Stefan Monnier
0 siblings, 2 replies; 22+ messages in thread
From: Eli Zaretskii @ 2010-10-25 18:04 UTC (permalink / raw
To: Stefan Monnier; +Cc: julien, emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Julien Danjou <julien@danjou.info>, emacs-devel@gnu.org
> Date: Mon, 25 Oct 2010 12:06:43 -0400
>
> Actually, storing generated files is always a source of annoyances.
> For files that change very rarely, like the unicode char data, this is
> not too problematic, but I often end up with problems because of
> configure and src/config.in.
Including with bzr? What problems are those? Bzr is much better than
CVS in handling conflicts, so much so that I sometimes suspect it
silently did the wrong thing (but it doesn't).
> Even better would be if Bzr provided support for such things.
If you can define the requirements, it might be worth to ask for such
a feature on the Bazaar list. If you get lucky, you could have a POC
plugin in a matter of days.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 18:04 ` Eli Zaretskii
@ 2010-10-25 18:37 ` Glenn Morris
2010-10-25 19:59 ` Stefan Monnier
2010-10-25 19:34 ` Stefan Monnier
1 sibling, 1 reply; 22+ messages in thread
From: Glenn Morris @ 2010-10-25 18:37 UTC (permalink / raw
To: Eli Zaretskii; +Cc: julien, Stefan Monnier, emacs-devel
Eli Zaretskii wrote:
>> I often end up with problems because of configure and
>> src/config.in.
>
> Including with bzr? What problems are those?
If you run autoconf locally (which I think is good practice), and you
did not use the same version as the person who last committed
configure, you WILL get a conflict when you update. Eg
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6428
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6536
I update and build my local copy of Emacs with a script, and I run
`bzr revert --no-backup configure src/config.in'
before `bzr pull/up' (and later `autoconf') to avoid this problem.
> a feature on the Bazaar list. If you get lucky, you could have a POC
> plugin in a matter of days.
But we cannot make everyone who checks out Emacs from bzr use said
plugin.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-24 17:31 configure{.in,} question Lars Magne Ingebrigtsen
2010-10-24 19:38 ` Glenn Morris
@ 2010-10-25 19:11 ` Ted Zlatanov
2010-10-25 19:13 ` Lars Magne Ingebrigtsen
1 sibling, 1 reply; 22+ messages in thread
From: Ted Zlatanov @ 2010-10-25 19:11 UTC (permalink / raw
To: emacs-devel
On Sun, 24 Oct 2010 19:31:10 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
LMI> I was going to remove the (BROKEN) from the gnutls conf option in
LMI> configure.in
You think it's ready for normal use? I'd mark it "experimental."
LMI> but when I then said "autoconf" (aren't we supposed to after all
LMI> configure.in changes?)
IIRC you have to `autoreconf' instead.
Ted
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 19:11 ` Ted Zlatanov
@ 2010-10-25 19:13 ` Lars Magne Ingebrigtsen
2010-10-25 19:16 ` Ted Zlatanov
0 siblings, 1 reply; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-10-25 19:13 UTC (permalink / raw
To: emacs-devel
Ted Zlatanov <tzz@lifelogs.com> writes:
> You think it's ready for normal use? I'd mark it "experimental."
I've used it exclusively for all the TLS connections in Emacs for weeks,
and it works for me...
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 19:13 ` Lars Magne Ingebrigtsen
@ 2010-10-25 19:16 ` Ted Zlatanov
2010-10-25 20:08 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 22+ messages in thread
From: Ted Zlatanov @ 2010-10-25 19:16 UTC (permalink / raw
To: emacs-devel
On Mon, 25 Oct 2010 21:13:11 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> You think it's ready for normal use? I'd mark it "experimental."
LMI> I've used it exclusively for all the TLS connections in Emacs for weeks,
LMI> and it works for me...
Wonderful, that makes 1.5 of us (I only use it half the time due to work
policies).
Ted
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 18:04 ` Eli Zaretskii
2010-10-25 18:37 ` Glenn Morris
@ 2010-10-25 19:34 ` Stefan Monnier
1 sibling, 0 replies; 22+ messages in thread
From: Stefan Monnier @ 2010-10-25 19:34 UTC (permalink / raw
To: Eli Zaretskii; +Cc: julien, emacs-devel
>> Even better would be if Bzr provided support for such things.
> If you can define the requirements, it might be worth to ask for such
> a feature on the Bazaar list. If you get lucky, you could have a POC
> plugin in a matter of days.
IIUC these kinds of problems may/will be helped by things like
"bzr-externals". In any case, as long as it's not in Bzr proper, I'd
rather not make use of it for Emacs's repository.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 18:37 ` Glenn Morris
@ 2010-10-25 19:59 ` Stefan Monnier
0 siblings, 0 replies; 22+ messages in thread
From: Stefan Monnier @ 2010-10-25 19:59 UTC (permalink / raw
To: Glenn Morris; +Cc: julien, Eli Zaretskii, emacs-devel
>>> I often end up with problems because of configure and
>>> src/config.in.
>> Including with bzr? What problems are those?
> If you run autoconf locally (which I think is good practice), and you
> did not use the same version as the person who last committed
> configure, you WILL get a conflict when you update. Eg
Indeed.
>> a feature on the Bazaar list. If you get lucky, you could have a POC
>> plugin in a matter of days.
> But we cannot make everyone who checks out Emacs from bzr use said
> plugin.
Actually, maybe for those files, we could use a merge-helper that just
says "use the most recent file". Of course, since merge helpers are
plugins, that still depends on whether such a merge helper is or will
be included in Bzr proper.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: configure{.in,} question
2010-10-25 19:16 ` Ted Zlatanov
@ 2010-10-25 20:08 ` Lars Magne Ingebrigtsen
0 siblings, 0 replies; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-10-25 20:08 UTC (permalink / raw
To: emacs-devel
Speaking of which, Andreas has just checked in configure made with
autoconf 2.68, so now there's a 4K line diff between anybody using 2.65
and what's in bzr.
If we're still going to have the configure file in bzr, would it be
possible to have the configure file be autogenerated on Savannah (or
somewhere), perhaps as a trigger after checking in configure.in? That
way we won't get 4K line flapping between different autoconf versions,
at least.
--
(domestic pets only, the antidote for overdose, milk.)
larsi@gnus.org * Lars Magne Ingebrigtsen
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2010-10-25 20:08 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-24 17:31 configure{.in,} question Lars Magne Ingebrigtsen
2010-10-24 19:38 ` Glenn Morris
2010-10-24 19:56 ` Lars Magne Ingebrigtsen
2010-10-24 20:07 ` Glenn Morris
2010-10-25 0:57 ` Stephen J. Turnbull
2010-10-25 8:38 ` Andreas Schwab
2010-10-25 14:43 ` Stephen J. Turnbull
2010-10-25 14:58 ` Andreas Schwab
2010-10-25 15:41 ` Stephen J. Turnbull
2010-10-25 8:47 ` Julien Danjou
2010-10-25 9:00 ` Andreas Schwab
2010-10-25 9:15 ` Eli Zaretskii
2010-10-25 16:06 ` Stefan Monnier
2010-10-25 18:04 ` Eli Zaretskii
2010-10-25 18:37 ` Glenn Morris
2010-10-25 19:59 ` Stefan Monnier
2010-10-25 19:34 ` Stefan Monnier
2010-10-25 16:43 ` Glenn Morris
2010-10-25 19:11 ` Ted Zlatanov
2010-10-25 19:13 ` Lars Magne Ingebrigtsen
2010-10-25 19:16 ` Ted Zlatanov
2010-10-25 20:08 ` Lars Magne Ingebrigtsen
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.