Not a timetable

Not a timetable

[Lars Magne Ingebrigtsen]

Once Emacs 20.3 has been released (which looks like something that's
imminent), I'll be consolidating the FSF changes into Gnus 5.6, create
Gnus 5.7 (which will be included in Emacs 20.4), and then start pgnus.

Since Emacs 20.3 looks like it's going to be usable, and since there
have been quite a lot of nice things introduced in (X)Emacs 20 over
(X)Emacs 19 (lisp-wise), pgnus will ditch support for (X)Emacs 19.
Goodbye `{message,gnus}-functionp'.  Goodbye `nnheader-temp-write'.
Goodbye `gnus-point-at-{b,e}ol'.

Ahh.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Magne Ingebrigtsen

Re: Not a timetable

[Edward J. Sabol]

Excerpts from mail: (13-Aug-98) Not a timetable by Lars Magne Ingebrigtsen
> Once Emacs 20.3 has been released (which looks like something that's
> imminent), I'll be consolidating the FSF changes into Gnus 5.6, create
> Gnus 5.7 (which will be included in Emacs 20.4), and then start pgnus.

So that means Emacs 20.3 will have Gnus 5.5 still? That's kind of
disappointing, what with 5.7 being so close and all.

> pgnus will ditch support for (X)Emacs 19.

I guess it's inevitable, but I'm wistful nevertheless. (I'm still using
19.34, but I'll most likely install 20.3 when it comes out.)

Re: Not a timetable

[Lars Magne Ingebrigtsen]

"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:

> So that means Emacs 20.3 will have Gnus 5.5 still?

Yes.

> That's kind of disappointing, what with 5.7 being so close and all.

Well, Gnus should be properly tested in the Emacs pre-test environment
before release, and there just isn't time.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Not a timetable

[Jan Vroonhof]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> > That's kind of disappointing, what with 5.7 being so close and all.
> 
> Well, Gnus should be properly tested in the Emacs pre-test environment
> before release, and there just isn't time.

But why can they just keep track of Gnu betas in the prereleases just
like XEmacs does?

Jan

Re: Not a timetable

[Lars Magne Ingebrigtsen]

Jan Vroonhof <vroonhof@math.ethz.ch> writes:

> > Well, Gnus should be properly tested in the Emacs pre-test environment
> > before release, and there just isn't time.
> 
> But why can they just keep track of Gnu betas in the prereleases just
> like XEmacs does?

Because I'm the one who does the Gnus things in the Emacs
distributions, and I'm lazy.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Not a timetable

[Lars Magne Ingebrigtsen]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> That is a shame.  Regardless of FSF Emacs 20.3's usability, it will still
> have MULE.  That, in and of itself, is a big reason why many will not be
> downgrading from 19.34.

But 20.2 MBSK works OK.  And Erik may yet release his Emacs 19.2003,
which is an Emacs 20 without MULE and stuff.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Not a timetable

[Jake Colman]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

   Lars> Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
   >> That is a shame.  Regardless of FSF Emacs 20.3's usability, it will still
   >> have MULE.  That, in and of itself, is a big reason why many will not be
   >> downgrading from 19.34.

Doesn't 20.3 make MULE optional?

-- 
Jake Colman                     

Principia Partners LLC                  Phone: (201) 946-0300
Harborside Financial Center               Fax: (201) 946-0320
902 Plaza II                           Beeper: (800) 505-2795
Jersey City, NJ 07311                  E-mail: colman@ppllc.com
                                       E-mail: jcolman@jnc.com
                                          web: http://www.ppllc.com

Re: Not a timetable

[William M. Perry]

Jake Colman <colman@ppllc.com> writes:

> >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
>    Lars> Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
>    >> That is a shame.  Regardless of FSF Emacs 20.3's usability, it will still
>    >> have MULE.  That, in and of itself, is a big reason why many will not be
>    >> downgrading from 19.34.
> 
> Doesn't 20.3 make MULE optional?

  Not really.  It supposedly has the --unibyte flag.  But it is still a
little weird even with that.

-Bill P.

Re: Not a timetable

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
>> That is a shame.  Regardless of FSF Emacs 20.3's usability, it will still
>> have MULE.  That, in and of itself, is a big reason why many will not be
>> downgrading from 19.34.

> But 20.2 MBSK works OK.

Not with TM.  But that isn't really a problem, since pgnus will have
native MIME support. :-)

> And Erik may yet release his Emacs 19.2003, which is an Emacs 20
> without MULE and stuff.

And which probably *will* work with TM, for the simple reason that the 
major release number is 19.

Re: Not a timetable

[Dave Love]

>>>>> "SB" == Steinar Bang <sb@metis.no> writes:

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

 >> But 20.2 MBSK works OK.

 SB> Not with TM.

Didn't I post about <URL:ftp://ftp.dl.ac.uk/pub/fx/emacs/MIME-emu-mbsk>
previously?  (Presumably won't work in 20.3.)

Re: Not a timetable

[François Pinard]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> 
> Lars> Since Emacs 20.3 looks like it's going to be usable, and since there
> Lars> have been quite a lot of nice things introduced in (X)Emacs 20 over
> Lars> (X)Emacs 19 (lisp-wise), pgnus will ditch support for (X)Emacs 19.
> 
> That is a shame.  Regardless of FSF Emacs 20.3's usability, it will still
> have MULE.  That, in and of itself, is a big reason why many will not be
> downgrading from 19.34.

For a while, pretesting for Emacs 20.3, I have `export EMACS_UNIBYTE=1'
in `~/.bash_login', and this makes Emacs pretty usable for me.

But I do not have anymore those ultra-nice displays of Asian characters,
and *that* is a shame.  I do intend to stop using EMACS_UNIBYTE at some time,
but given my humble abilities, I just cannot pretest everything at once.

All this to say that you should not fear Emacs 20.3.  I honestly think it
has a lot of features well worth switching away from Emacs 19.  If MULE
works well, just take it as a gift.  If it creates problem, then stick
EMACS_UNIBYTE in your environment, until MULE gets fully dependable.

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Not a timetable

[François Pinard]

Stainless Steel Rat <ratinox@peorth.gweep.net> écrit:

> "FP" == François Pinard <pinard@iro.umontreal.ca> writes:
> 
> FP> For a while, pretesting for Emacs 20.3, I have `export EMACS_UNIBYTE=1'
> FP> in `~/.bash_login', and this makes Emacs pretty usable for me.
> 
> It is not a matter of usability.  It is a matter of the fact that it
> is impossible to build FSF Emacs 20 without MULE code when MULE is
> neither required nor desired.  [...] But I will not use an Emacs with
> MULE compiled in, and I am not alone on that stance.

A kind of principle, then?  A political statement?  Just bad character? :-)

This is a bit like if I was saying that I do not use colourisation of
articles in Gnus, and intend to refuse to install or use Gnus until there
is an option to produce `.elc' files with all colourisation code removed.
Is that it?  Is there anything else to it?

There are surely a *lot* of programs in which I'm far from using all
features.  I would not refuse to use them on the sole basis they are more
generous than I strictly need.  I hope I'm much more reasonable than that.

If I may, not being alone in a strange attitude does not necessarily make
it good, one also needs sounded reasons to excuse it.  I only guess that
you have other untold reasons for not wanting to use this Emacs version.

				With my regards, of course, :-)

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Not a timetable

[Steinar Bang]

>>>>> François Pinard <pinard@iro.umontreal.ca>:

> Stainless Steel Rat <ratinox@peorth.gweep.net> écrit:

>> It is not a matter of usability.  It is a matter of the fact that it
>> is impossible to build FSF Emacs 20 without MULE code when MULE is
>> neither required nor desired.  [...] But I will not use an Emacs with
>> MULE compiled in, and I am not alone on that stance.

> A kind of principle, then?  A political statement?  Just bad
> character? :-)

I think he got burnt by the first relase, and refuse to stick his hand 
into the fire again.

Re: Not a timetable

[Hrvoje Niksic]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> FP> This is a bit like if I was saying that I do not use colourisation of
> FP> articles in Gnus, and intend to refuse to install or use Gnus until
> FP> there is an option to produce `.elc' files with all colourisation code
> FP> removed.  Is that it?  Is there anything else to it?
> 
> Well, no.  If you wanted to, removing the color-setting code is easilly
> doable: changing the default color setting code to use copy-face a lot is
> the easiest way I can think of to do it.  Hacking custom to think you
> always have a monochrome display is another (and is, in fact, my personal
> favorite :).

Neither of these "remove" the code -- they just disable its execution.
So I don't understand the difference between these hacks and `export
EMACS_UNIBYTE=1' which disables MULE.

> MULE is different.  Even "disabled" it is still there, looming in the
> background, consuming resources that could be used for something useful
> (for whatever definition of "useful" you care for).

I don't think MULE consumes any resources in Unibyte mode.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Silence!" cries Freydag. "I did not call thee in for a consultation!" 
"They are my innards! I will not have them misread by a poseur!"

Re: Not a timetable

[Robert Bihlmeyer]

Hi,

>>>>> On 17 Aug 1998 14:53:53 +0200
>>>>> Hrvoje Niksic <hniksic@srce.hr> said:

 Hrvoje> I don't think MULE consumes any resources in Unibyte mode.

Space. On disk and probably in core (until your system pages it).

	Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>

Re: Not a timetable

[Kai Grossjohann]

>>>>> Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

  > It is not a matter of usability.  It is a matter of the fact that
  > it is impossible to build FSF Emacs 20 without MULE code when MULE
  > is neither required nor desired.

`vi has the Ctrl-d and Ctrl-u commands which I never need.  Therefore
I don't use vi.'

Strange strange.

I think removing all features you don't use from all programs you use
is going to be a lot of work.

If one has emotional reasons for something then one should go ahead
and say so, rather than rationalizing in a way that causes other
people to try to explain the flaws in their logic.

A friend of mine says he doesn't want to use an editor which he can
program and therefore sticks to vi (nvi without the Perl stuff, to be
precise).  I wouldn't dream of trying to discuss with him -- he's
happy and that's fine.  But then he doesn't discuss with me -- I'm
happy and that's fine, too.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Not a timetable

[luis fernandes]

    grossjohann> I think removing all features you don't use from all
    grossjohann> programs you use is going to be a lot of work.

Yes, of course. 

But if those features are the cause of bloat and their existence is a
contentious issue; i.e. some people argue that these features are
essential and others argue that they are useless, then the extra work
to make them optional is worth it because it satisfies both camps.

(I bet there are Emacs purists out there that compile Emacs without X
support.)

Re: Not a timetable

[SL Baur]

luis fernandes <elf@ee.ryerson.ca> writes in ding@gnus.org:

> (I bet there are Emacs purists out there that compile Emacs without X
> support.)

I'm not a purist, but an XEmacs without TTY support is a handy tool on 
a server without X11 libraries.  x?emacs -batch is a whole lot better
than the 4-letter p-word.

Re: Not a timetable

[Dave Love]

>>>>> "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

 Rat> C-d and C-u are not 25-50% of the footprint of vi.

Without wishing to defend MULE, I doubt it represents that fraction of
Emacs 20.3's footprint.

 KG> I think removing all features you don't use from all programs you
 KG> use is going to be a lot of work.

 Rat> I can do it with XEmacs 19 and 20 with autoconf switches.  I can
 Rat> do it with Emacs 19 with autoconf switches.  I can do it with
 Rat> Emacs 20 with autoconf switches, with the exception of MULE.
 Rat> 'nuff said, I think.

You use all the features of Emacs 20.3 apart from MULE, X and POP
variants?  Gosh.

-- 
Mercifully Unibyte's Largely Effective

Re: Not a timetable

[Dave Love]

>>>>> "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

 Rat> The Emacs 20.1 and 20.1 binaries are ~50% larger than the Emacs 19.34
 Rat> binary (Linux/GNU system, GCC 2.7.2).  The memory footprint is comesurately
 Rat> larger.  Most of that code increase is MULE.

 KG> I think removing all features you don't use from all programs you
 KG> use is going to be a lot of work.

 Rat> Only becaue RMS decided to break his own "rules" and incorporated MULE in a
 Rat> fashion that prevents it from being removed.  He could have done it right,
 Rat> witness XEmacs which has MULE as a compile time feature.  He decided not to
 Rat> do it that way.

 Rat> [...]

 DL> You use all the features of Emacs 20.3 apart from MULE, X and POP
 DL> variants?  Gosh.

 Rat> I don't use FSF Emacs 20.anything since I cannot build it without MULE.

Re: Not a timetable

[Dave Love]

>>>>> "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

 Rat> The Emacs 20.1 and 20.1 binaries are ~50% larger than the Emacs 19.34
 Rat> binary (Linux/GNU system, GCC 2.7.2).  

I was thinking of a more relevant footprint like memory.

 Rat> The memory footprint is comesurately larger.

As in 4.8 MB for 19.34 v. 5.9 MB for 20.3 or 5.4 MB for 20.2 MBSK
freshly started under X on Linux as I see?  For a realistic sized
process, the fractional difference between 19 and 20 is considerably
reduced (not obviously important to me).  Gnus is one of the major
contributors to memory footprint in my Emacs, of course.

 Rat> Most of that code increase is MULE.

Probably so FWIW, but unmeasured.

However, arguing about the footprint misses the point of MULE problems
(such as are relevant to Gnus).

 KG> I think removing all features you don't use from all programs you
 KG> use is going to be a lot of work.

 Rat> Only becaue RMS decided to break his own "rules" and
 Rat> incorporated MULE in a fashion that prevents it from being
 Rat> removed.

What "rules", exactly?

 Rat> He could have done it right, witness XEmacs which has MULE as a
 Rat> compile time feature.  He decided not to do it that way.

While I don't like it, I can see reasonable arguments for it being
like that.  Note also that rms has reacted to complaints about the
MULE incarnation in 20.2.  20.3 deserves use.

Re: Not a timetable

[Lars Magne Ingebrigtsen]

Dave Love <d.love@dl.ac.uk> writes:

>  Rat> Only becaue RMS decided to break his own "rules" and
>  Rat> incorporated MULE in a fashion that prevents it from being
>  Rat> removed.
> 
> What "rules", exactly?

RMS has traditionally been quite conservative in doing biiig changes
to the Emacs sources.  The MULE code is, well, absolutely everywhere
-- probably not a single .c and .el file have gone unscathed.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Not a timetable

[Dave Love]

>>>>> "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

 Rat> "DL" == Dave Love <d.love@dl.ac.uk> writes:

 Rat> Remember, MBSK does not eliminate MULE's code or overhead,

I'll take you word for it; I couldn't remember if it changes puresize.

 Rat> The same "rules" that make X and POP and many other features of
 Rat> Emacs optional at compile time.

The `many other features' I know (per template.h) comparable to X are
clash detection and text properties -- POP configuration is for
movemail.  I don't think you could dump 20.3 after turning off text
properties.

[Not that this has anything to do with Gnus other than that there must
be a fair amount of Gnus unexercised in my heap.  Also it's
potentially even less of an issue when Emacs can dynamically load
object code.]

Re: Not a timetable

[Dave Love]

>>>>> "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

 Rat> "DL" == Dave Love <d.love@dl.ac.uk> writes:

 Rat> Remember, MBSK does not eliminate MULE's code or overhead,
 DL> I'll take you word for it; I couldn't remember if it changes puresize.

 Rat> Take Erik Naggum's word for it: it does not.

I mis-read `eliminate' as `eliminate any of'.  It's important to note
that it does zap multibyte MULE Lisp, though, because that provides a
way to check for it -- potentially important for MIMEing.

Re: Not a timetable

[SL Baur]

Dave Love <d.love@dl.ac.uk> writes in ding@gnus.org:

>>>>>> "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
Rat> C-d and C-u are not 25-50% of the footprint of vi.

> Without wishing to defend MULE, I doubt it represents that fraction of
> Emacs 20.3's footprint.

For comparison:  with current XEmacs, I see a 19% binary size increase and
a 16% increase of VM footprint when Mule is compiled in.