Re: Please unbundle the custom and widget libraries from qgnus.

Re: Please unbundle the custom and widget libraries from qgnus.

[Jason R Mastaler]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Emacs 20.1 is out, which means that the latest version of both emacsen
> have build-in support for customize.

However, alot of XEmacs 19 users would consider XEmacs 19.16 (which is 
about to be released) the "latest" version, and it doesn't have built
in support for customize I don't think.

   Jason R. Mastaler                      jason@mastaler.com
 

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

Jason R Mastaler <jason@mastaler.com> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
> > Emacs 20.1 is out, which means that the latest version of both emacsen
> > have build-in support for customize.
> 
> However, alot of XEmacs 19 users would consider XEmacs 19.16 (which is 
> about to be released) the "latest" version, and it doesn't have built
> in support for customize I don't think.

Yes, but 19.16 will come with the same Gnus as 19.15, which means that 
Per's article does not apply to it.

Furthermore, we should somehow make it *very* clear that 19.16 is
meant primarily for die-hard 19.x users.  20.2 is there, and works
just fine.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Idle RAM is the Devil's playground.

Re: Please unbundle the custom and widget libraries from qgnus.

[Per Abrahamsen]

Jason R Mastaler <jason@mastaler.com> writes:

> However, alot of XEmacs 19 users would consider XEmacs 19.16 (which is 
> about to be released) the "latest" version, and it doesn't have built
> in support for customize I don't think.

Custom was bundled with XEmacs 19.15, and will also be in XEmacs 19.16.

Re: Please unbundle the custom and widget libraries from qgnus.

[Jan Vroonhof]

Jason R Mastaler <jason@mastaler.com> writes:

> However, alot of XEmacs 19 users would consider XEmacs 19.16 (which is 
> about to be released) the "latest" version, and it doesn't have built
> in support for customize I don't think.

Since XEmacs 19.16 comes bundled with Gnus 5.4 it also has
Customize...

Jan

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

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

> GNU Emacs 19.34 is the last version of GNU Emacs that will be in use
> for a lot of people for a very long time.  Call it "old" if you
> will, but for many, MULE is Pure Evil and they will not use it.  RMS
> has decided that GNU Emacs 20 will not have an option not to compile
> MULE into the code.  Thus, 19.34 is it until such time as Erik
> Naggum's splinter project takes off.

This is all fine, but we are talking about Quassia Gnus here.  Until
they become official, many people will start using Emacs 20.
Furthermore, Lars could put custom distribution to the Gnus site, too.

> Of course, if you want to remove custom dependancies entirely, I am
> all for it. :)

Why?  What do you see wrong with Custom?

-- 
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: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

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

> >>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> >> Of course, if you want to remove custom dependancies entirely, I
> >> am all for it. :)
> 
> Hrvoje> Why?  What do you see wrong with Custom?
> 
> Specifically: the repeated lack of incorporating a simple patch that
> I have provided on numerous occasions, allowing one to completely
> disable colors in Gnus while still retaining faces.

I seem to have missed this patch.  Why don't you customize the Gnus
faces to be colorless?

> This is more of an issue with cus-face than custom.

Then it's an issue with custom (if it indeed is an issue), too.

> Generally: the fact that it takes ten times as long to effect a
> change with custom than with a setq form,

Custom will respect setq forms.  Custom is not defvoo(doo).

> the fact that it does some annoying things to an existing .emacs

Only if you use customize, and explicitely choose `Save for future
sessions' button.  Even so, the XEmacs version doesn't use `.emacs'.

> and the fact that there are at least three incompatable versions of
> it in general circulation.

That is to be remedied soon (or so we hope).

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Unspeakable horrors from outer space paralyze the living and
resurrect the dead!

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

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

> Hrvoje> I seem to have missed this patch.  Why don't you customize the Gnus
> Hrvoje> faces to be colorless?
> 
> Because there are a lot of different faces that Gnus uses, and this is the
> kind of on-off thing that should be easilly accomplished.

I see.  But how did you disable colors before `defface' was used?  I
mean, you must have had an even harder time doing it.  Or not?

> >> This is more of an issue with cus-face than custom.
> 
> Hrvoje> Then it's an issue with custom (if it indeed is an issue), too.
> 
> You're right.  Its been so long since I seriously looked at the code that I
> had forgotten (PGP will munge the "---" lines a bit; sorry):
[...]

This patch looks simple (though a little-bit dirty).  Why didn't Per
accept it?  Now, to get it in GNU Emacs, you must have Stallman's
consent.  I'm prepared to apply it to XEmacs.

> + (defcustom custom-no-colors nil
> +   "Do not use colors.
> + If t, do not use any colors.")

This should probably be `custom-use-colors' with reverse semantics,
but it doesn't matter either way.

> >> Generally: the fact that it takes ten times as long to effect a
> >> change with custom than with a setq form,
> 
> Hrvoje> Custom will respect setq forms.  Custom is not defvoo(doo).
> 
> Agreed... but a dozen or more setq forms for each package that uses
> custom simply to disable colorization without disabling faces is
> still a lose.

What I meant is that, unlike defvoo, defcustom will perfectly respect
your `setq' forms.  `defface' is another matter, since it creates a
face, rather than a variable.

> >> the fact that it does some annoying things to an existing .emacs
> 
> Hrvoje> Only if you use customize, and explicitely choose `Save for
> Hrvoje> future sessions' button.
> 
> Apart from testing purposes, who would do this?

If you don't do this, Customize will not change your `.emacs'.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

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

> >>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> Hrvoje> I see.  But how did you disable colors before `defface' was used?
> Hrvoje> I mean, you must have had an even harder time doing it.  Or not?
> 
> A previous incarnation of the patch.

So, this doesn't qualify as a Custom braindamage.  (which is how we
got to that.)

> Hrvoje> This patch looks simple (though a little-bit dirty).
> 
> It's a two-minute hack; what do you expect? :)

The trouble with it is that it's /ad hoc/.  Suppose you want to add a
similar toggle for something else (e.g. boldness, or font sizes), you
are out of luck.  Or, you can write another patch like this one.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it."                                    -- Donald Knuth

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

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

> >>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> Hrvoje> The trouble with it is that it's /ad hoc/.  Suppose you want to add a
> Hrvoje> similar toggle for something else (e.g. boldness, or font sizes), you
> Hrvoje> are out of luck.  Or, you can write another patch like this one.
> 
> If custom is supposed to be able to easilly customize everything (which is
> apparantly the goal) then it should be able to easilly customize
> everything.  Having to manually change two dozen things, using the custom
> engine, for every package that I use is anything but easy.

Per has published another way to do it, in his message.

> Oh, and by the way, I remembered what I found to be evil about
> custom: once it has set things it is impossible to change them
> without exiting and restarting GNU Emacs.

Huh?  Can you be more specific?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}

Re: Please unbundle the custom and widget libraries from qgnus.

[Per Abrahamsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> >
> > Oh, and by the way, I remembered what I found to be evil about
> > custom: once it has set things it is impossible to change them
> > without exiting and restarting GNU Emacs.
> 
> Huh?  Can you be more specific?

Sounds like meta variables[1], another old discussion which is
completely[2] unrelated to custom.  Most of the `gnus-use-whatever'
variables are meta-variables.

Footnotes: 
[1]  Variables whose value is not used directly by the code, but
instead used for initializing other variables. 

[2]  Although with custom, you could theoretically add a `:set' clause
which would make changes to meta variables to take effect automatically.

Re: Please unbundle the custom and widget libraries from qgnus.

[Per Abrahamsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Why didn't Per accept it?

Because the same functionality was already in Custom with 

	(add-to-list 'default-frame-alist '(display-type . mono))

as I explained at the time.  The difference at the time was that
Makefile mode also checked `display-type' directly, so the above would
turn off colors in both Gnus and Makefile mode, while Mr. Rats patch
only affected those packages whose faces were under control by custom.

However, my judgement at the time was that eventually Makefile mode
would also be customized (and indeed, it have), so adding the extra
complexity of a new user variable, which would only hold temporary
value, and only to a single user, would not be cost effective.

Re: Please unbundle the custom and widget libraries from qgnus.

[Karl Anderson]

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

> the fact that it does some annoying things to
> an existing .emacs

Ever since I realized that emacs messes with my .emacs, my .emacs has
been:

;; Load my emacs
(load-library "~/emacs/my-emacs")

Kept it even after I realized that the only messing in years has been
a single (put 'eval-expression 'disabled nil), since I have 11 my-*.el
files anyway.

-- 
Karl Anderson      kra@pobox.com      <URL:http://www.pobox.com/~kra/>

Re: Please unbundle the custom and widget libraries from qgnus.

[Lars Balker Rasmussen]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> [...] MULE is Pure Evil and they will not use it.  RMS has decided that GNU
> Emacs 20 will not have an option not to compile MULE into the code.  Thus,
> 19.34 is it until such time as Erik Naggum's splinter project takes off.

MULE may be pure evil (It may slow down Emacs, but 20 feels faster than
19 anyway), and 19.34 may be "it" for some people, but I sure as hell
wouldn't want to live without the improvements in compile-mode ;-)

Next-error, baby, next-error!
-- 
Lars Balker Rasmussen, Software Engineer, Mjolner Informatics ApS
lbr@mjolner.dk

Re: Please unbundle the custom and widget libraries from qgnus.

[Jason R Mastaler]

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

> 19.34 is it until such time as Erik Naggum's splinter project takes off.

Great.  All we need is a third Emacs project.

   Jason R. Mastaler                      jason@mastaler.com

Re: Please unbundle the custom and widget libraries from qgnus.

[SL Baur]

Jason R Mastaler <jason@mastaler.com> writes:

> Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
>> 19.34 is it until such time as Erik Naggum's splinter project takes off.

> Great.  All we need is a third Emacs project.

We do, actually.  Erik has some interested ideas that deserve to be
tried out.

Re: Please unbundle the custom and widget libraries from qgnus.

[Jason R Mastaler]

SL Baur <steve@xemacs.org> writes:

> > Great.  All we need is a third Emacs project.
> 
> We do, actually.  Erik has some interested ideas that deserve to be
> tried out.

Ideas that can't be contributed to Emacs and/or XEmacs?

   Jason R. Mastaler                      jason@mastaler.com

Re: Yet Another Emacs Project (YAEP)

[Richard Coleman]

> 
> > > Great.  All we need is a third Emacs project.
> > 
> > We do, actually.  Erik has some interested ideas that deserve to be
> > tried out.
> 
> Ideas that can't be contributed to Emacs and/or XEmacs?
> 
>    Jason R. Mastaler                      jason@mastaler.com

I guess that might be possible.

But some of the things that Erik wants to try (in particular
a different way of dealing with multibyte charsets) are at odds
with the direction that (X)Emacs have followed.

At least that's my understanding.

Richard Coleman
coleman@math.gatech.edu

Re: Please unbundle the custom and widget libraries from qgnus.

[Johan Danielsson]

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

> And a bunch more.

Like scrapping a very old and boring program and starting from
scratch.

/Johan

Re: Yet Another Emacs Project (YAEP)

[Richard Coleman]

> 
> > 19.34 is it until such time as Erik Naggum's splinter project takes off.
> 
> Great.  All we need is a third Emacs project.
> 
>    Jason R. Mastaler                      jason@mastaler.com

Well, I generally believe competition of this sort is
a good thing.  It appears that Erik has some ambitious plans
(such as using Unicode and migrating Emacs to a Common Lisp base).

My guess is that either the project will be too ambitious and
never get anywhere -- or be the base for the next generation
of Emacs.

His web page (don't have URL handy) has a small discussion of
his plans.

If nothing else, it should be interesting.

Richard Coleman
coleman@math.gatech.edu

Re: Please unbundle the custom and widget libraries from qgnus.

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I suggest qgnus stop bundling these libraries, and instead ask users
> of "old" emacsen to fetch them from:
> 
> 	<URL:http://www.dina.kvl.dk/~abraham/custom/>

I'll remove them from Quassia 0.8.

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

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

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

> Again, I say that a total unbundling is a Bad Idea.  Libraries that a
> package requires should be distributed with that package.  This is nothing
> more than being professional.  Pull them out of the source tree and put
> them in an auxilliary tarball that gets included with the Gnus
> distribution.  If you do not you are going to have a *LOT* of people asking
> the exact same question on gnu.emacs.gnus: "where can I get custom?"

...and the answer will be: "With the latest version of Emacs."

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm a Lisp variable -- bind me!

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

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

> >>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> Hrvoje> ...and the answer will be: "With the latest version of Emacs."
> 
> *sigh* Didn't I just go through this?  GNU Emacs 19.34 is the latest
> version of GNU Emacs for much of the non-Asian world.

GNU Emacs 20.1 is usable for people outside Asia, too.  By the time
Quassia Gnus is released, many more people will use Emacs 20.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Thou Who might be our Father Who perhaps may be in Heaven...
                                                -- Roger Zelazny

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

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

> >>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> Hrvoje> GNU Emacs 20.1 is usable for people outside Asia, too.
> 
> Tell that to Erik Naggum, who is planning on splintering Yet Another GNU
> Emacs specifically because GNU Emacs 20.1 does *NOT* work well for people
> outside of Asia.

I know of Erik's plans.  However, Erik does say that Emacs 20.1 is
usable for people outside Asia, but he does not *want* to use it.  The 
reasons why he doesn't want to use it are explained in his many
articles.

My point is that one should not use MULE as an excuse to stick with
Emacs 19.34b forever (and refusing to acknowledge Custom, etc.)  Is
that what you intend to do?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Speak softly and carry a +6 two-handed sword.

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

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

> Primarilly because MULE breaks ISO Latin-1 which works flawlessly in GNU
> Emacs 19.34 and barely works at all in GNU Emacs 20.1.  Assuming for the
> moment that you are not a developer/tester, which would you prefer to use,
> a version of GNU Emacs that works, or one that manages to limp along and
> occasionally breaks your files?

I don't think MULE breaks ISO Latin-1.  It makes it harder to use,
maybe.  Anyway, you mentioned Erik as an example -- but Erik *is* the
one who calls out to everyone to switch to 20.1.  Even with MULE, it's 
still better than 19.34.  One of the reasons why it's better
(according to Erik) is Custom.

> Hrvoje> My point is that one should not use MULE as an excuse to stick with
> Hrvoje> Emacs 19.34b forever (and refusing to acknowledge Custom, etc.)  Is
> Hrvoje> that what you intend to do?
> 
> But you see, MULE is exactly that.  If Erik's YAGE project fails to pan
> out, and the 19.35 release never appears, there will be many who freeze at
> 19.34 forever, because that is how long it will be before RMS makes MULE a
> compile time option as it is with GNU XEmacs.

I don't think MULE is as bad as that, but you're free to make your own 
choices.  I hope that other package developers will not give up Custom 
because of Stallmans idiotic decisions.


P.S.
`GNU XEmacs' makes me gag.  It's just XEmacs.  Or we fight back with
`FSF Emacs', which makes Stallman gag. :-)

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm a Lisp variable -- bind me!

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

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

> Hrvoje> It makes it harder to use, maybe.  Anyway, you mentioned
> Hrvoje> Erik as an example -- but Erik *is* the one who calls out to
> Hrvoje> everyone to switch to 20.1.  Even with MULE, it's still
> Hrvoje> better than 19.34.  One of the reasons why it's better
> Hrvoje> (according to Erik) is Custom.
> 
> Another one is that it reduces duplicated effort on the development
> front.

True.  But he *does* encourage people to upgrade to 20.1.  So you
cannot use him as a promotor of not doing it.

> The fewer versions of GNU (X)Emacs that are actively supported, the
> easier it is on the developers.  But remember that Erik is also in
> the planning stages of both a GNU Emacs 19.35 release as well as an
> ambitious YAGE project, at least partially because of MULE and the
> stance RMS has taken on it.

Ha!  I'd bet Mule is just the immediate excuse.  In many XEmacs
flamewars Erik has been explaining that he had no problems whatsoever
cooperating with Stallman.  It would be too much to admit that he
doesn't like Stallman's way of handling things.  So he says he doesn't 
like MULE.  As if there weren't many patches that Stallman rejected
because he "didn't like them".

> But this brings up *my* reasons for not "upgrading" from GNU Emacs
> 19.34: code bloat.  Both GNU Emacs 20 and all versions of XEmacs
> have a lot of code dedicated to features for which I have no use,
> "features" I cannot entirely disable at compile time.

This is a good reason not to upgrade.  You could say the same for
Emacs 18.59, for instance -- and you would be equally justified.  But
you must not expect the package developers, and the rest of the users, 
to follow your reasonings.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Idle RAM is the Devil's playground.

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

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

> I do not see the same degree of necessary change to the internals this time
> around.

But you said yourself that you did not see it in the first versions of 
Emacs 19, either.  So things may be better by Emacs 20.19 -- or
however long it takes.

> Aside from MULE, most of the changes are the new and updated
> packages, like Gnus.  Everything else is literally window dressing.

This is, of course, not true.  Look at Erik Naggum's exhaustive
article on the subject.  Or, the NEWS file, for that matter.

> For the time being I forsee no reason why Gnus will not continue to
> work properly on Emacs 19.34, and so I do not see a reason to
> abandon those who for whatever reason are going to continue to use
> it instead of Emacs 20.

Neither do I.  But I do see the reason why Gnus might want to unbundle 
custom.  The Emacs 20 users will have it bundled, and the Emacs 19
users will get it elsewhere.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"A Real Programmer's code can awe with its fiendish brilliance, even
as its crockishness appalls."

Re: Please unbundle the custom and widget libraries from qgnus.

[Jason R Mastaler]

Hrvoje Niksic <hniksic@srce.hr> writes:

> `GNU XEmacs' makes me gag.  It's just XEmacs.  Or we fight back with
> `FSF Emacs', which makes Stallman gag. :-)

If no one likes the term "FSF", why does Gnus use this in it's
message-id's?  Both Emacs and XEmacs.

For example,

Message-ID: <x7lo0lxf55.fsf@mastaler.com>
                        ^^^

   Jason R. Mastaler                      jason@mastaler.com

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

Jason R Mastaler <jason@mastaler.com> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > `GNU XEmacs' makes me gag.  It's just XEmacs.  Or we fight back with
> > `FSF Emacs', which makes Stallman gag. :-)
> 
> If no one likes the term "FSF", why does Gnus use this in it's
> message-id's?

I said that Stallman didn't like the term `FSF Emacs', not the term
`FSF'.

> Message-ID: <x7lo0lxf55.fsf@mastaler.com>
>                         ^^^

Because there is a greater chance that they will be unique.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
4.  Thou shalt not warlorde a sig if it bee the sig of Kibo, nor if
    it bee the sig of the Inner Circle.

Re: Please unbundle the custom and widget libraries from qgnus.

[Alan Shutko]

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

R> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrvoje> GNU Emacs 20.1 is usable for people outside Asia, too.

R> Tell that to Erik Naggum, who is planning on splintering Yet
R> Another GNU Emacs specifically because GNU Emacs 20.1 does *NOT*
R> work well for people outside of Asia.

Tell that to Erik Naggum, who's also been encouraging people to
upgrade to Emacs 20 (by posting answers to questions which work only
in Emacs 20).  He provides a MULE survival kit which makes Emacs 20
work well for people outside of Asia.

(Besides, Emacs 20 works well for US residents, who never cared about
8-bit characters anyway.  8^))

-- 
Alan Shutko <ats@acm.org> - By consent of the corrupted
Don't worry so loud, your roommate can't think.

Re: Gnus 5.5 and MBSK

[Lars Magne Ingebrigtsen]

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

> However, there are two problems, one of which is directly related to Gnus
> 5.5: Gnus 5.5 will probably break if you run it on a GNU Emacs 20 that has
> had the MBSK patches applied.  Why?  Because it breaks the MBSK's Golden
> Rule: NEVER TURN ON MULTIBYTE ENCODING.

When does Gnus 5.5 switch on multibyte encoding?

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

Re: Gnus 5.5 and MBSK

[Lars Magne Ingebrigtsen]

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

> Lars> When does Gnus 5.5 switch on multibyte encoding?
> 
> I have not looked closely at the diffs, but I would guess that it does so
> any time it encounters 8-bit characters. 

Not if you have Mule switched off.

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

Re: Please unbundle the custom and widget libraries from qgnus.

[Kai Grossjohann]

>>>>> On 20 Sep 1997, Stainless Steel Rat said:

  Rat> *sigh* Didn't I just go through this?  GNU Emacs 19.34 is the
  Rat> latest version of GNU Emacs for much of the non-Asian world.
  Rat> GNU Emacs 19.34 does not include a current version of custom.

Lars should write Quassia so it needs Emacs 20 and doesn't run on
19.34, which will put an end to this discussion.

PS: Oh, I think I forgot:  :-)

kai
-- 
I like both kinds of music.

Re: Please unbundle the custom and widget libraries from qgnus.

[Lars Magne Ingebrigtsen]

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

> If you do not you are going to have a *LOT* of people asking the
> exact same question on gnu.emacs.gnus: "where can I get custom?"

I think you may be right, but the GNUS-NEWS file has (as its first
entry) instructions on how to fetch Custom.  If this turns out to be a
major problem, I'll put the Custom files back in into the tarball (in
a separate directory).

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

Re: Please unbundle the custom and widget libraries from qgnus.

[Lars Magne Ingebrigtsen]

Kurt Swanson <ksw@dna.lth.se> writes:

> My suggestion is putting an "echo How to obtain custom..." line into
> the makefile.

I've now made dgnushack check for Custom and then issue instructions
if it can't find it.

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

Re: Please unbundle the custom and widget libraries from qgnus.

[William M. Perry]

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

> Kurt Swanson <ksw@dna.lth.se> writes:
> 
> > My suggestion is putting an "echo How to obtain custom..." line into
> > the makefile.
> 
> I've now made dgnushack check for Custom and then issue instructions
> if it can't find it.

  Have you ever considered using autoconf to create your makefiles for
GNUS?  I've been writing quite a few macros for Emacs/W3's configure.in for 
mucking about with the Emacs someone is trying to use.  I've written
equivalents of the AC_CHECK_LIB macro, so for Emacs/W3 to test whether the
current emacs has a suitable version of the widget library I just do:

AC_EMACS_CHECK_LIB(widget,widget-convert-text,"noecho")
AC_EMACS_CHECK_LIB(wid_edit,widget-convert-text,"noecho")

The 'noecho' stuff is just so routines called by AC_EMACS_CHECK_LIB don't
echo their own 'checking ....' stuff.  There is also AC_EMACS_CHECK_VAR
macro, and AC_EMACS_LISP macro for executing arbitrary lisp.

>From configure.in:

AC_CHECK_CUSTOM
if test "${CUSTOM}" = "no"; then
AC_MSG_WARN(" ")
AC_MSG_WARN(No usable version of the widget/custom libraries have been)
AC_MSG_WARN(detected on your system.  This version of Emacs/W3 requires)
AC_MSG_WARN(features present in newer versions of the widget library.)
AC_MSG_WARN(" ")
AC_MSG_WARN(Please upgrade to the latest version of custom available.)
AC_MSG_WARN(This package is included with Emacs 20.1 and XEmacs 20.3)
AC_MSG_WARN(or from http://www.dina.kvl.dk/~abraham/custom/)
AC_MSG_WARN(" ")
AC_MSG_WARN(You may still continue but you must modify lisp/Makefile)
AC_MSG_WARN(to have the correct WIDGETDIR setting.)
AC_MSG_WARN(" ")
fi

-Bill P.

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

wmperry@aventail.com (William M. Perry) writes:

> AC_MSG_WARN(Please upgrade to the latest version of custom available.)
> AC_MSG_WARN(This package is included with Emacs 20.1 and XEmacs 20.3)
> AC_MSG_WARN(or from http://www.dina.kvl.dk/~abraham/custom/)

The version with 20.2 is good enough too, I think.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Unspeakable horrors from outer space paralyze the living and
resurrect the dead!

Re: Please unbundle the custom and widget libraries from qgnus.

[Per Abrahamsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> wmperry@aventail.com (William M. Perry) writes:
> 
> > AC_MSG_WARN(Please upgrade to the latest version of custom available.)
> > AC_MSG_WARN(This package is included with Emacs 20.1 and XEmacs 20.3)
> > AC_MSG_WARN(or from http://www.dina.kvl.dk/~abraham/custom/)
> 
> The version with 20.2 is good enough too, I think.

It is good enough for Gnus (so is the one in 19.15).  But W3 needs a
fairly recent version.

Re: Please unbundle the custom and widget libraries from qgnus.

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

>   Have you ever considered using autoconf to create your makefiles
> for GNUS?

Yeah, but I don't think we really need it for Gnus. 

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

Re: Please unbundle the custom and widget libraries from qgnus.

[Kai Grossjohann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 517 bytes --]

>>>>> On 21 Oct 1997, François Pinard said:

  François> One thing that we also needed, and for a long while, is
  François> using makeinfo whenever possible to generate the manuals.
  François> Emacs is just too slow at it, and makeinfo is not so bad
  François> anyway :-).  Whatever the trick is, makeinfo should be
  François> used if available on the installing system.

I've been typing "make makeinfo" for a LONG time now and haven't had
any problems with it.

kai
-- 
~/.signature: No such file or directory

To autoconf or not to autoconf (Was Re: Please unbundle the custom and widget libraries from qgnus.)

[William M. Perry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

Kai Grossjohann <grossjohann@charly.cs.uni-dortmund.de> writes:

> >>>>> On 21 Oct 1997, François Pinard said:
> 
>   François> One thing that we also needed, and for a long while, is
>   François> using makeinfo whenever possible to generate the manuals.
>   François> Emacs is just too slow at it, and makeinfo is not so bad
>   François> anyway :-).  Whatever the trick is, makeinfo should be
>   François> used if available on the installing system.
> 
> I've been typing "make makeinfo" for a LONG time now and haven't had
> any problems with it.

  Yes, but you have to go read the makefile to figure that out.  Its not in 
the manual, the .el files, the texi files, nothing. :)

[gnus]find . -type f -print | xargs fgrep -i makeinfo
./texi/Makefile:MAKEINFO=$(EMACS) -batch -q -no-site-file
./texi/Makefile:        $(MAKEINFO) -eval '(find-file "gnus.texi")' $(XINFOSWI)
./texi/Makefile:        $(MAKEINFO) -eval '(find-file "message.texi")' $(XINFOSWI)
./texi/Makefile:makeinfo: 
./texi/Makefile:        makeinfo -o gnus gnus.texi
./texi/Makefile:        makeinfo -o message message.texi

  If you are using autoconf, you can make it automatically choose one or
the other, automatically.  The Emacs/W3 aclocal.m4 has grown quite a bit
over the last few months, and has macros to run arbitrary lisp in the emacs 
you have chosen, and get the return values.  This is how I check for the
existence of widget, custom, package support in XEmacs, etc.

-Bill P.

Re: Please unbundle the custom and widget libraries from qgnus.

[François Pinard]

Kai Grossjohann <grossjohann@charly.cs.uni-dortmund.de> écrit:

> I've been typing "make makeinfo" for a LONG time now and haven't had
> any problems with it.

It works!  Thanks a lot for telling me!  Remains for Gnus to be clever
enough for using it all by itself, when it is available. :-)

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

Re: Please unbundle the custom and widget libraries from qgnus.

[Lars Magne Ingebrigtsen]

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

> One thing that we also needed, and for a long while, is using makeinfo
> whenever possible to generate the manuals.  Emacs is just too slow at it,
> and makeinfo is not so bad anyway :-). 

Ha!  I've got a K6/200, and I want to use it!  I even byte-compile
everything with XEmacs 20 just to make it feel like it has something
to do.

Poor, underutilized CPU.

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

Re: Please unbundle the custom and widget libraries from qgnus.

[Matt Simmons]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Poor, underutilized CPU.
That's why God made the Mersenne(sp?) Prime Search.

Matt

-- 
     Matt Simmons  -  simmonmt@acm.org  -  http://www.netcom.com/~simmonmt
   There is always an easy solution to every human problem -- neat, plausible
			   and wrong.  --H.L. Mencken

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

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

> François Pinard <pinard@iro.umontreal.ca> writes:
> 
> > One thing that we also needed, and for a long while, is using makeinfo
> > whenever possible to generate the manuals.  Emacs is just too slow at it,
> > and makeinfo is not so bad anyway :-). 
> 
> Ha!  I've got a K6/200, and I want to use it!  I even byte-compile
> everything with XEmacs 20 just to make it feel like it has something
> to do.

ROTFL!  I knew XEmacs was good for *something*!

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Idle RAM is the Devil's playground.

Re: Please unbundle the custom and widget libraries from qgnus.

[William M. Perry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > François Pinard <pinard@iro.umontreal.ca> writes:
> > 
> > > One thing that we also needed, and for a long while, is using makeinfo
> > > whenever possible to generate the manuals.  Emacs is just too slow at it,
> > > and makeinfo is not so bad anyway :-). 
> > 
> > Ha!  I've got a K6/200, and I want to use it!  I even byte-compile
> > everything with XEmacs 20 just to make it feel like it has something
> > to do.
> 
> ROTFL!  I knew XEmacs was good for *something*!

  I hope lars is using XEmacs 20.3beta94 with no optimizations, --debug=yes
and --error-checking=all --with-mule :)

-Bill P.

Re: Please unbundle the custom and widget libraries from qgnus.

[Hrvoje Niksic]

wmperry@aventail.com (William M. Perry) writes:

> > ROTFL!  I knew XEmacs was good for *something*!
> 
> I hope lars is using XEmacs 20.3beta94 with no optimizations,
> --debug=yes and --error-checking=all --with-mule :)

He's using 19.15.  Feh...

>From what I hear, early 19.12 betas with error-checking=all and no
optimization were, khm, *interesting* speedwise.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Speak softly and carry a +6 two-handed sword.

Re: Please unbundle the custom and widget libraries from qgnus.

[William M. Perry]

Hrvoje Niksic <hniksic@srce.hr> writes:

> wmperry@aventail.com (William M. Perry) writes:
> 
> > > ROTFL!  I knew XEmacs was good for *something*!
> > 
> > I hope lars is using XEmacs 20.3beta94 with no optimizations,
> > --debug=yes and --error-checking=all --with-mule :)
> 
> He's using 19.15.  Feh...
> 
> From what I hear, early 19.12 betas with error-checking=all and no
> optimization were, khm, *interesting* speedwise.

  I hereby nominate Hrvoje for worlds largest understatement of the last
few years. :)  Ahh, the heady excitement of the early 19.12 alphas!  The
world may never see their like again.

-Bill P.

Re: Please unbundle the custom and widget libraries from qgnus.

[Per Abrahamsen]

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

>  Libraries that a
> package requires should be distributed with that package. 

This is true for static C libraries used by C programs, but very
unprofessional for Emacs packages.  The different is that different
versions of a C library can co-exist in different C programs, but the
equivalent does not hold for Emacs.

> If you do not you are going to have a *LOT* of people asking
> the exact same question on gnu.emacs.gnus: "where can I get custom?"

This is preferable to:

	"I just installed Gnus, and W3 no longer works"

	(the current #1 question on the w3 lists)

	"I just installed Gnus, and the modeline is no longer inverse"

	(I found out that Emacs 20.1 was released by someone sending
	 me this)
	
	Add to that all the unpredictable errors the bundling will
	cause in the future.