Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109724: Merge from gnulib.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109724: Merge from gnulib.

[Eli Zaretskii]

> +2012-08-21  Paul Eggert  <eggert@cs.ucla.edu>
> +
> +	Merge from gnulib, incorporating:
> +	2012-08-20 extern-inline: support old GCC 'inline'

I wonder if we could agree to wait for a month or so before merging
fresh gnulib changes, unless they fix some very grave bug.  AFAIU,
this issue is still being discussed on the gnulib list, and it's not
inconceivable that more objections will be raised to your original
commit.  This particular commit was pushed to gnulib repo just a few
hours ago.

I don't think it's right to make Emacs an alpha-testing ground for
gnulib in this way.  If nothing else, it makes harder for other people
to develop non-trivial changes, because it proliferates conflicts, and
for no good reason.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109724: Merge from gnulib.

[Paul Eggert]

On 08/21/2012 09:28 AM, Eli Zaretskii wrote:
> this issue is still being discussed on the gnulib list, and it's not
> inconceivable that more objections will be raised to your original
> commit.

The patch I installed is not part of that discussion and
is a simple patch that nobody would object to.

Emacs is not a testing ground for gnulib here -- it's more
the other way around.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109724: Merge from gnulib.

[Juanma Barranquero]

On Tue, Aug 21, 2012 at 10:55 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

> Emacs is not a testing ground for gnulib here -- it's more
> the other way around.

I don't think that makes much sense, but surely that only highlights
my poor English skills.

Do you mean that new Emacs features are first tested in gnulib? :-)

    Juanma

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109724: Merge from gnulib.

[Paul Eggert]

On 08/21/2012 03:03 PM, Juanma Barranquero wrote:
> Do you mean that new Emacs features are first tested in gnulib?

Often they are, but not in this case.  Emacs C code
is written in a style that stresses function calls.
Lessons learned from hacking on Emacs internals
are useful in other GNU packages, and gnulib is a common
way to share this sort of thing.  In this particular case
the arrow of innovation is from Emacs to gnulib, not the other
way around.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109724: Merge from gnulib.

[Eli Zaretskii]

> Date: Tue, 21 Aug 2012 13:55:30 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: emacs-devel@gnu.org
> 
> On 08/21/2012 09:28 AM, Eli Zaretskii wrote:
> > this issue is still being discussed on the gnulib list, and it's not
> > inconceivable that more objections will be raised to your original
> > commit.
> 
> The patch I installed is not part of that discussion and
> is a simple patch that nobody would object to.

It's still prudent to wait a little, IMO.

> Emacs is not a testing ground for gnulib here -- it's more
> the other way around.

That's not my impression.