Emacs 22.2 release plans

Emacs 22.2 release plans

[Chong Yidong]

Hi folks.  Here is the current plan for the Emacs 22.2 release:

On next Friday, March 7, I'll roll the 22.1.92 pretest tarball.  My
hope is that this will be the final pretest before the 22.2 release,
but that will depend on the bugs.

From this point on, please refrain from making any non-trivial changes
to the Emacs 22 branch.  If you feel the need to make such a change,
please email emacs-devel with your patch and explain why it needs to
be applied.  If in doubt, email emacs-devel anyway (if you like, you
can also email me directly).  I'll make an effort to read all patches.

Manual, docstring, and other "obvious" fixes can be committed
directly.

Furthermore, if you apply a fix to the trunk that you think should be
backported to the Emacs 22 branch after the 22.2 release, please
either (i) email it to me, (ii) make a note in admin/FOR-RELEASE on
the branch, or (iii) keep track of it yourself, so that the fix will
be applied after the release without getting lost.


Thanks!

Re: Emacs 22.2 release plans

[Chong Yidong]

Hi,

As a reminder, I'll be rolling the 22.1.92 pretest on Friday.  If any
of you need to delay the pretest for whatever reason, please send an
email.

Re: Emacs 22.2 release plans

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> Hi,
>
> As a reminder, I'll be rolling the 22.1.92 pretest on Friday.  If any
> of you need to delay the pretest for whatever reason, please send an
> email.


The following paragraph in etc/NEWS seems to be both badly worded,
in the wrong place, and perhaps only intended for the pretest.
In any case, please check it:

* Systems that will not be supported in the future
configure will print a warning and exit for a set of systems that are
believed to not be in use anymore.  The support has not been removed
yet, but configure will need to be edited in order to allow
compilation to proceed on such a system.  If you are using such a
system, please send a message to emacs-devel@gnu.org in order to take
off the list of systems.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs 22.2 release plans

[Glenn Morris]

Kim F. Storm wrote:

> The following paragraph in etc/NEWS seems to be both badly worded,
> in the wrong place, and perhaps only intended for the pretest.
> In any case, please check it:
>
> * Systems that will not be supported in the future
> configure will print a warning and exit for a set of systems that are
> believed to not be in use anymore.  The support has not been removed
> yet, but configure will need to be edited in order to allow
> compilation to proceed on such a system.  If you are using such a
> system, please send a message to emacs-devel@gnu.org in order to take
> off the list of systems.

Something like this? It should be up near the top (in "Installation
Changes" or a separate section):

"We plan to discontinue support for some older systems in Emacs 23.1.
These systems are still supported in Emacs 22.2, but configure will
not complete without manual intervention.  If you encounter one of
these systems, and believe it should continue to be supported, please
make your voice known at emacs-devel@gnu.org."

Re: Emacs 22.2 release plans

[Kim F. Storm]

Glenn Morris <rgm@gnu.org> writes:

> Something like this? It should be up near the top (in "Installation
> Changes" or a separate section):
>
> "We plan to discontinue support for some older systems in Emacs 23.1.
> These systems are still supported in Emacs 22.2, but configure will
> not complete without manual intervention.  If you encounter one of
> these systems, and believe it should continue to be supported, please
> make your voice known at emacs-devel@gnu.org."

It still find it confusing:

If you need "manual intervention" (such as editing the configure
script) to make Emacs 22 compile on a certain platform, then IMO
the system is _not_ supported on Emacs 22.

So speaking about "plan to discontinue support in 23.1" seems
meaningless when Emacs 22 itself doesn't compile (out of the box) on
that system.


So either you discontinue those systems in 22.2, or you make Emacs 22.2
compile on those systems.  

Breaking "configure" is effective - but IMO not the right place - to
ask people to "make your voice known"...

My suggestion is that configure simply prints the following blurb
at the END of the configure output - so it is clearly visible
to the target users:

--------------- WARNING --------------------------------------
SYSTEM-XXX is considered an potentially obsolete system by the
Emacs development team, so Emacs 22.2 may be the last release
to officially support it.

Since you still use Emacs on such a system, and you want to
continue using future Emacs versions on it, please make
your voice known to the developers at emacs-devel@gnu.org.
--------------------------------------------------------------



-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs 22.2 release plans

[Dan Nicolaescu]

storm@cua.dk (Kim F. Storm) writes:

  > Glenn Morris <rgm@gnu.org> writes:
  > 
  > > Something like this? It should be up near the top (in "Installation
  > > Changes" or a separate section):
  > >
  > > "We plan to discontinue support for some older systems in Emacs 23.1.
  > > These systems are still supported in Emacs 22.2, but configure will
  > > not complete without manual intervention.  If you encounter one of
  > > these systems, and believe it should continue to be supported, please
  > > make your voice known at emacs-devel@gnu.org."
  > 
  > It still find it confusing:
  > 
  > If you need "manual intervention" (such as editing the configure
  > script) to make Emacs 22 compile on a certain platform, then IMO
  > the system is _not_ supported on Emacs 22.
  > 
  > So speaking about "plan to discontinue support in 23.1" seems
  > meaningless when Emacs 22 itself doesn't compile (out of the box) on
  > that system.
  > 
  > 
  > So either you discontinue those systems in 22.2, or you make Emacs 22.2
  > compile on those systems.  
  > 
  > Breaking "configure" is effective - but IMO not the right place - to
  > ask people to "make your voice known"...
  > 
  > My suggestion is that configure simply prints the following blurb
  > at the END of the configure output - so it is clearly visible
  > to the target users:
  > 
  > --------------- WARNING --------------------------------------
  > SYSTEM-XXX is considered an potentially obsolete system by the
  > Emacs development team, so Emacs 22.2 may be the last release
  > to officially support it.
  > 
  > Since you still use Emacs on such a system, and you want to
  > continue using future Emacs versions on it, please make
  > your voice known to the developers at emacs-devel@gnu.org.
  > --------------------------------------------------------------

This is nitpicking...

The problem with warnings is that using

./configure && make 

is quite common, so seeing the warning is almost impossible.

Re: Emacs 22.2 release plans

[Jason Rumney]

Dan Nicolaescu wrote:
> The problem with warnings is that using
>
> ./configure && make 
>
> is quite common, so seeing the warning is almost impossible.
>   

What about using a --force-obsolete option to configure to force it to 
continue past the warning, rather than requiring users to edit the 
configure script themselves?

Re: Emacs 22.2 release plans

[Dan Nicolaescu]

Jason Rumney <jasonr@gnu.org> writes:

  > Dan Nicolaescu wrote:
  > > The problem with warnings is that using
  > >
  > > ./configure && make 
  > >
  > > is quite common, so seeing the warning is almost impossible.
  > >   
  > 
  > What about using a --force-obsolete option to configure to force it to
  > continue past the warning, rather than requiring users to edit the
  > configure script themselves?

Too disruptive for the configure script so close to the release.
And this is designed to force users take an action.
(BTW, Stefan originally wanted this to be #error in src/[ms]/*.h)
This is for stuff that is quite likely dead (things like HPUX running on
m68k).  Why do people all of a sudden care about this???

Re: Emacs 22.2 release plans

[Stefan Monnier]

> What about using a --force-obsolete option to configure to force it to
> continue past the warning, rather than requiring users to edit the
> configure script themselves?

Sounds good,


        Stefan

Re: Emacs 22.2 release plans

[Stefan Monnier]

> The problem with warnings is that using
> ./configure && make 
> is quite common, so seeing the warning is almost impossible.

Agreed.  The warning needs to be louder and force user interaction.


        Stefan

Re: Emacs 22.2 release plans

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

>> The following paragraph in etc/NEWS seems to be both badly worded,
>> in the wrong place, and perhaps only intended for the pretest.
>> In any case, please check it:
>>
>> * Systems that will not be supported in the future
>> configure will print a warning and exit for a set of systems that are
>> believed to not be in use anymore.  The support has not been removed
>> yet, but configure will need to be edited in order to allow
>> compilation to proceed on such a system.  If you are using such a
>> system, please send a message to emacs-devel@gnu.org in order to take
>> off the list of systems.
>
> Something like this? It should be up near the top (in "Installation
> Changes" or a separate section):
>
> "We plan to discontinue support for some older systems in Emacs 23.1.
> These systems are still supported in Emacs 22.2, but configure will
> not complete without manual intervention.  If you encounter one of
> these systems, and believe it should continue to be supported, please
> make your voice known at emacs-devel@gnu.org."

I've checked in a change that moves the entry into the Installation
Changes section and makes it (IMO) slightly clearer:

  ** Deprecated machine types and operating systems
  
  Certain machine types and operating systems have been deprecated.  On
  these systems, configure will print a warning and exit, and you must
  edit the configure script for compilation to proceed.  The deprecated
  systems will not be supported at all in Emacs 23.  We are not aware of
  anyone running Emacs on these systems; if you are, please email
  emacs-devel@gnu.org to take it off the list of deprecated systems.
  
  *** Deprecated machine types
  pmax, hp9000s300, ibm370aix, ncr386, ews4800, mips-siemens, powerpcle,
  and tandem-s2
  
  *** Deprecated operating systems
  bsd386, bsdos2-1, bsdos2, bsdos3, bsdos4, bsd4-1, bsd4-2, bsd4-3,
  usg5-0, usg5-2-2, usg5-2, usg5-3, ultrix4-3, 386bsd, hpux, hpux8,
  hpux9, hpux9shr, hpux10, hpux10-20, aix3-1, aix3-2-5, aix3-2, aix4-1,
  nextstep, ux4800, uxpds, and uxpv

As for changing the configure script to add an option to enable
deprecated builds, it would be fine if someone wants to do it, but I
don't think it's necesary.  I *seriously* doubt anyone's using Emacs
22 on these systems, and anyone who is surely has the expertise to
make the required simple change to the configure script.

Re: Emacs 22.2 release plans

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

>
>   ** Deprecated machine types and operating systems
>   
>   Certain machine types and operating systems have been deprecated.

Good!  That's takes care of my "nitpicking"!

The text now says that those systems are now deprecated in 22.2.

> As for changing the configure script to add an option to enable
> deprecated builds, it would be fine if someone wants to do it, but I
> don't think it's necesary.  I *seriously* doubt anyone's using Emacs
> 22 on these systems, and anyone who is surely has the expertise to
> make the required simple change to the configure script.

I don't see a need to change configure with the updated info in NEWS.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs 22.2 release plans - request for a slight delay.

[Alan Mackenzie]

Hi, Yidong,

It's me again, causing trouble.  ;-(

On Wed, Mar 05, 2008 at 12:25:16PM -0500, Chong Yidong wrote:
> Hi,

> As a reminder, I'll be rolling the 22.1.92 pretest on Friday.  If any
> of you need to delay the pretest for whatever reason, please send an
> email.

I'm asking for a slight delay (perhaps over the weekend?) to fix a
serious bug in C mode, namely:

    Subject: Re: Unbearably slow editing in .h files
    From: martin rudalics <rudalics@gmx.at> (and Stefan)
    Date: Sat, 23 Feb 2008 23:51:34 +0100
    Message-ID: <47C0A376.8080105@gmx.at>

    Visit lisp.h, go to the end of the buffer, and do

    M-x RET c-beginning-of-defun RET

This is horrendously slow (~30 seconds).

I've just had a look at c-beginning-of-defun, and I've narrowed the
fault down to `c-in-knr-argdecl', where the code laboriously trundles
back one paren pair at a time until it finds a "}" (or BOB).  This is
clearly suboptimal in a region with several hundred consecutive
declarations without brace-blocks.  There are ~900 consecutive
paren-pairs in the tail of lisp.h.

Even worse, c-in-knr-argdecl gets called twice, doubling the pain.

Just how many paren/bracket pairs can there be in the K&R region of the
header of a C function?  There is no absolute limit, but such a region
will typically look less extravagant than this:

   int foo (bar, baz, yuk)
       int bar [] ;
       int (*baz) (my_type) ;
       int (*) (void) (*yuk) (void) ;
   {

, which has 7 such pairs.  So perhaps if I put the limit at 32, this
will be safe for any function not appearing in the Obfuscated C
competition or deliberately written to break editors.  :-)

This will probably be a "quick and easy" change, taking, perhaps, an
hour.  However, it's probably worth while doing it calmly and carefully.
;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs 22.2 release plans - request for a slight delay.

[Chong Yidong]

Hi Alan,

> It's me again, causing trouble.  ;-(

It's OK.

> I'm asking for a slight delay (perhaps over the weekend?) to fix a
> serious bug in C mode, namely:
>
>     Visit lisp.h, go to the end of the buffer, and do
>     M-x RET c-beginning-of-defun RET
>
> This is horrendously slow (~30 seconds).
>
> I've just had a look at c-beginning-of-defun, and I've narrowed the
> fault down to `c-in-knr-argdecl', where the code laboriously trundles
> back one paren pair at a time until it finds a "}" (or BOB).  This is
> clearly suboptimal in a region with several hundred consecutive
> declarations without brace-blocks.  There are ~900 consecutive
> paren-pairs in the tail of lisp.h.
>
> So perhaps if I put the limit at 32, this will be safe for any
> function not appearing in the Obfuscated C competition or
> deliberately written to break editors.  :-)
>
> This will probably be a "quick and easy" change, taking, perhaps, an
> hour.  However, it's probably worth while doing it calmly and carefully.
> ;-)

[Alan later sent a patch to me off-list.]

First off, could you check the patch into the trunk?  Thanks.

I would like more information before we decide whether or not to check
it into the branch and/or delay the pretest.

First off, I just did a quick test, and the slowness also occurs in
Emacs 22.1.  It doesn't seem to be slower than in 22.1 (i.e. a
regression), but I didn't time this precisely.  Is there any reason to
believe that the problem has gotten worse since 22.1, e.g. due to
changes to CC mode since the 22.1 release?

Secondly, if memory serves, c-beginning-of-defun is not only used
interactively, but also for font-lock.  Is this correct?  If so, is
there a possibility that quitting from the paren-parsing loop in this
way will screw up font-lock?

Re: Emacs 22.2 release plans - request for a slight delay.

[Alan Mackenzie]

Hi, Yidong,

On Thu, Mar 06, 2008 at 06:19:54PM -0500, Chong Yidong wrote:

> > I'm asking for a slight delay (perhaps over the weekend?) to fix a
> > serious bug in C mode, namely:

> >     Visit lisp.h, go to the end of the buffer, and do
> >     M-x RET c-beginning-of-defun RET

> > This is horrendously slow (~30 seconds).

> > I've just had a look at c-beginning-of-defun, and I've narrowed the
> > fault down to `c-in-knr-argdecl', where the code laboriously trundles
> > back one paren pair at a time until it finds a "}" (or BOB).  This is
> > clearly suboptimal in a region with several hundred consecutive
> > declarations without brace-blocks.  There are ~900 consecutive
> > paren-pairs in the tail of lisp.h.

> > So perhaps if I put the limit at 32, this will be safe for any
> > function not appearing in the Obfuscated C competition or
> > deliberately written to break editors.  :-)

> > This will probably be a "quick and easy" change, taking, perhaps, an
> > hour.  However, it's probably worth while doing it calmly and carefully.
> > ;-)

> [Alan later sent a patch to me off-list.]

I meant to send that to the list, but must have hit 'r' instead of 'g'
(in mutt).  Apologies.

> First off, could you check the patch into the trunk?  Thanks.

Yes, I'll do that this evening (European time).

> I would like more information before we decide whether or not to check
> it into the branch and/or delay the pretest.

> First off, I just did a quick test, and the slowness also occurs in
> Emacs 22.1.  It doesn't seem to be slower than in 22.1 (i.e. a
> regression), but I didn't time this precisely.  Is there any reason to
> believe that the problem has gotten worse since 22.1, e.g. due to
> changes to CC mode since the 22.1 release?

No.  The CC Mode code is the same in Emacs-22 and the trunk.

> Secondly, if memory serves, c-beginning-of-defun is not only used
> interactively, but also for font-lock.  Is this correct?

I think so.  I'll have a closer look later.

> If so, is there a possibility that quitting from the paren-parsing
> loop in this way will screw up font-lock?

Yes, under the following conditions:
(i) only when there is a K&R region (hence, only in C Mode, not C++,
  ObjC, ....);
(ii) only when there are more than N (currently 20) paren/bracket pairs
  in the region (ignoring comments/strings/preprocessor lines). 

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs 22.2 release plans - request for a slight delay.

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

>> Secondly, if memory serves, c-beginning-of-defun is not only used
>> interactively, but also for font-lock.  Is this correct?
>
> I think so.  I'll have a closer look later.
>
>> If so, is there a possibility that quitting from the paren-parsing
>> loop in this way will screw up font-lock?
>
> Yes, under the following conditions:
> (i) only when there is a K&R region (hence, only in C Mode, not C++,
>   ObjC, ....);
> (ii) only when there are more than N (currently 20) paren/bracket pairs
>   in the region (ignoring comments/strings/preprocessor lines). 

Let's delay this till after the 22.2 release.

I'll be rolling the pretest shortly.

Re: Emacs 22.2 release plans - request for a slight delay.

[Alan Mackenzie]

Hi!

On Fri, Mar 07, 2008 at 11:17:55AM -0500, Chong Yidong wrote:

> Let's delay this [speedup fix for C-M-a in C Mode] till after the 22.2
> release.

OK.  Emacs 22.3, maybe?

> I'll be rolling the pretest shortly.

:-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs 22.2 release plans - request for a slight delay.

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

> On Fri, Mar 07, 2008 at 11:17:55AM -0500, Chong Yidong wrote:
>
>> Let's delay this [speedup fix for C-M-a in C Mode] till after the 22.2
>> release.
>
> OK.  Emacs 22.3, maybe?

Yeah.

Re: Emacs 22.2 release plans - request for a slight delay.

[Nick Roberts]

 > >> Let's delay this [speedup fix for C-M-a in C Mode] till after the 22.2
 > >> release.
 > >
 > > OK.  Emacs 22.3, maybe?
 > 
 > Yeah.

I think that there should be some statement of intent that there will
actually be a 22.3 release, even a schedule - six months seems to be the
usual period - for branch releases.  That way, others, e.g., Ken Manheimer
with python.el, are more likely to port their changes to the branch.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs 22.2 release plans - request for a slight delay.

[Alan Mackenzie]

Hi,!

On Thu, Mar 06, 2008 at 06:19:54PM -0500, Chong Yidong wrote:

> > I'm asking for a slight delay (perhaps over the weekend?) to fix a
> > serious bug in C mode, namely:

> >     Visit lisp.h, go to the end of the buffer, and do
> >     M-x RET c-beginning-of-defun RET

> > This is horrendously slow (~30 seconds).

> > I've just had a look at c-beginning-of-defun, and I've narrowed the
> > fault down to `c-in-knr-argdecl', where the code laboriously trundles
> > back one paren pair at a time until it finds a "}" (or BOB).  This is
> > clearly suboptimal in a region with several hundred consecutive
> > declarations without brace-blocks.  There are ~900 consecutive
> > paren-pairs in the tail of lisp.h.

> > So perhaps if I put the limit at 32, this will be safe for any
> > function not appearing in the Obfuscated C competition or
> > deliberately written to break editors.  :-)

> > This will probably be a "quick and easy" change, taking, perhaps, an
> > hour.  However, it's probably worth while doing it calmly and carefully.
> > ;-)

> [Alan later sent a patch to me off-list.]

> First off, could you check the patch into the trunk?  Thanks.

Done, including a patch to cc-mode.texi.

-- 
Alan Mackenzie (Nuremberg, Germany).