Request: new emacs release

Request: new emacs release

[Adrian Robert]

Hi all,

I am sorry to bother the developer list if this is not felt 
appropriate, but I just wanted a user's perspective (not sure how 
typical) to be heard..

I am a long-time emacs user frustrated with the current state and 
worried from the tone of developer discussions here that no release 
will be coming for a long time.  I'm listing my personal list of 
reasons for wanting a new release, FWIW, and not with any intention of 
bashing, just in the spirit of giving feedback from a user 
perspective..


1) Mac OS X

Due to various maintainership incidents, the only option for Panther 
users to obtain a working, non-ancient aqua emacs is to compile the CVS 
"21.3.50" from source.  However due to no release plans being made, 
this is a hit-or-miss affair -- bugs I've observed in recent attempts 
include font-lock "regexp" colorizing not being performed, startup 
failure due to lisp load errors, difficulties getting third-party 
packages to run smoothly, and frequent (1+ per day) crashes.  Even the 
binary packages available on the net, which tend to be from better CVS 
snapshots, still exhibit crashing and other bugs.

XEmacs is not really an option because it only works on OS X under X11 
(and therefore uses ugly font rendering, etc.).

I know there is opposition to making OS X much of a priority in the 
FSF, and I personally wish Apple would lend a hand in some way, but I 
thought it was at least decided to provide a version.  Right now this 
only exists in CVS.


2) Fringe customization

For 4 years now, users wishing to use emacs 21 have had to live with 
the unsuppressable super-wide double-fringe that came with that 
version.  Many times this makes the difference between showing two 
windows size-by-side in a reasonably-sized font and not, and it takes 
real estate from other windows in all cases.  Many others have 
complained about this.

"21.3.50" makes it configurable.  (This was promised for 21.3 and 
didn't make it in.)  Furthermore it updates the buffer window behavior 
to NOT take up an extra line after every 80 column line, using the 
fringe to mark this instead.  This is a bigger deal for people who edit 
code than it may seem.  I've tried compiling a CVS emacs to get the 
21.3.50 behavior, but see above on my luck with hitting CVS on a good 
day..


3) Time passage

It has been 1 year since 21.3.  Aside from the major improvements (Mac 
OS X support and fringe customizability) mentioned above, there must 
have been many other worthwhile things done in this time -- it would be 
nice to have them in a release.  Also, the cleaning out of bugs that 
comes with making a release might improve general development 
efficiency (know there are differing opinions on this)..


best regards,
Adrian Robert

Re: Request: new emacs release

[Stefan Monnier]

I'll just say that in case someone still wonders, I'm 100% in agreement
with Adrian that we should get a new releaqse from the CVS trunk ASAP.
This means code freeze Real-Soon-Now.

> a hit-or-miss affair -- bugs I've observed in recent attempts include
> font-lock "regexp" colorizing not being performed, startup failure due to
> lisp load errors, difficulties getting third-party packages to run smoothly,
> and frequent (1+ per day) crashes.

I use Emacs on Mac OS X almost everyday (though in X11 mode) and don't see
any such things.  Also I haven't seen any bug reports about it.
Without bug reports, there's not much we can do.  Please help us
by becoming a good friend of M-x report-emacs-bug.

> For 4 years now, users wishing to use emacs 21 have had to live with the
> unsuppressable super-wide double-fringe that came with that version.

Maybe you get unlicky because of your font-size, but AFAIK, this
"super-wide" is "one char wide", so the difference with Emacs-20.7 is only
one extra column (there used to be one (right) fringe, now there are two).

> Many times this makes the difference between showing two windows
> size-by-side in a reasonably-sized font and not, and it takes real estate

Going down from 80 to 79 columns should get you back the Emacs-20
frame size.  Admittedly, you'll lose a column.

> from other windows in all cases.  Many others have complained about this.

Oh, yes.  We've heard more than our share.

> "21.3.50" makes it configurable.  (This was promised for 21.3 and didn't
> make it in.)

It was probably promised by someone who thought that 21.3 was going to be
taken from the CVS trunk.

> 3) Time passage
> It has been 1 year since 21.3.

You don't seem to realize that 21.3 is a very minor change from 21.1 and
that during 21.1 and 21.3 there's been many more changes than that.
It's just that they were kept on the CVS trunk and not included in the
release.  So feel free to bump your "1 year of work" to "4 years of work".


        Stefan

Re: Request: new emacs release

[Juanma Barranquero]

On 30 Mar 2004 18:52:49 -0500
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I'll just say that in case someone still wonders, I'm 100% in agreement
> with Adrian that we should get a new releaqse from the CVS trunk ASAP.
> This means code freeze Real-Soon-Now.

The issue has been brought up a few times in past years, and (almost?)
everyone seems to agree that we should do something. Still, no decision
has been ever reached on the account of when/what to release, and whether
a new numbering scheme should be used.

So perhaps we should try to be positive:

 1) Is a "features" (i.e., from trunk) release necessary?

 2) Would it be useful?

 3) Is there any impeding reason?

 4) What would be the inconveniences?

 5) Should we change the numbering scheme?

In my (narrow) view, the answers are:

 1) Not "necessary", because 21.3 is pretty much rock-solid and there
    are (to my knowledge) no showstopper bugs waiting for an urgent
    patch.

 2) Would be useful, in two accounts: on one hand, the 3+ years of new
    developments would be exposed to the public (yeah, I know a few
    download from CVS, but that's not the same as a General Availability
    release) and so more used and more heavily tested; on the other hand,
    because it would help to dispell a certain perceived "staleness" of
    the Emacs project. To some, that seems like not a good reason to act,
    but, as recently witnessed with the Subversion 1.0.0 release,
    "getting out" a new version stirs interest and brings up new users
    and new developers.

 3) Not sure. I know there are a few branches heavily developed, most
    notably the Unicode one, but I'm not sure whether it was ever
    decided that the next features release would (or wouldn't) include
    the Unicode work. In other words, I don't know if there are plans to
    do a 21.4 "new features" from trunk and a 22.1 "full Unicode", or
    just one of them. Personally, I'd branch for 21.4 Real Soon Now and
    bring Unicode to the trunk so it could be on track for a release Not
    That Soon, But Soon Enough.

 4) The main inconvenience, IMO, is diverted resources. Still, I
    (perhaps naïvely) don't see it as a great problem. Measures can be
    taken, as semi-freezing the trunk while 21.4 is in pretest so we can
    focus on the release. I'd even bet the idea of getting ready to
    release so much improvements would have a positive impact on us... :)

 5) I think most developers agree that a new numbering scheme would be
    useful, though there's less agreement on exactly *which* one. I'm
    not going to repeat here the long threads, available in the mailing
    list archives :)

                                                                Juanma

Re: Request: new emacs release

[Piet van Oostrum]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> (SM) wrote:

SM> I'll just say that in case someone still wonders, I'm 100% in agreement
SM> with Adrian that we should get a new releaqse from the CVS trunk ASAP.
SM> This means code freeze Real-Soon-Now.

>> a hit-or-miss affair -- bugs I've observed in recent attempts include
>> font-lock "regexp" colorizing not being performed, startup failure due to
>> lisp load errors, difficulties getting third-party packages to run smoothly,
>> and frequent (1+ per day) crashes.

SM> I use Emacs on Mac OS X almost everyday (though in X11 mode) and don't see
SM> any such things.  Also I haven't seen any bug reports about it.
SM> Without bug reports, there's not much we can do.  Please help us
SM> by becoming a good friend of M-x report-emacs-bug.

I did send in a bug report some 2 weeks ago. I have the impression from
the stack trace that the bug is in the Mac-specific windowing code.
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: Request: new emacs release

[Lars Hansen]

>
>
> 1) Not "necessary", because 21.3 is pretty much rock-solid and there
>    are (to my knowledge) no showstopper bugs waiting for an urgent
>    patch.
>  
>
The rock-solid-ness depends somewhat on how you use Emacs. Emacs (21.2) 
crash for me, if not every day, then at least every week. Although I 
don't know how to confirm it, I think the reason is the missing  GCPRO 
in directory-files and directory-files-and-attributes, a bug that has 
been corrected now.

It may not be a showstopper, but it would be nice with a released Emacs 
without this bug.

Re: Request: new emacs release

[Juanma Barranquero]

On Wed, 31 Mar 2004 12:43:26 +0200
Lars Hansen <larsh@math.ku.dk> wrote:

> The rock-solid-ness depends somewhat on how you use Emacs.

Sure. Note I said "to my knowledge".

> Emacs (21.2) 
> crash for me, if not every day, then at least every week.

Does 21.3 (which was released more than a year ago) crashes too? Or did
you mean to say 21.3?

> It may not be a showstopper, but it would be nice with a released Emacs 
> without this bug.

I agree.


                                                                Juanma

Re: Request: new emacs release

[Lars Hansen]

Juanma Barranquero wrote:

>Does 21.3 (which was released more than a year ago) crashes too? Or did
>you mean to say 21.3?
>
>  
>
I meant 21.2. The systems I use have not been upgraded to 21.3, so I 
don't know for shure that 21.3 would chrash too. But the bug I suspect 
is in 21.3 too.