Time to get laughed at....

39 views
Skip to first unread message

Shaun Lipscombe

unread,
Jan 27, 1999, 3:00:00 AM1/27/99
to

This may seem like a ridiculous question, but i'll ask anyway ....

What is MULE? Is it an Emacs clone/implementation?

--
(o_
(o_ (o_ //\
(/)_ (/)_ V_/_ shaun.l...@gasops.co.uk

Erik Naggum

unread,
Jan 27, 1999, 3:00:00 AM1/27/99
to
* Shaun Lipscombe <shaun.l...@no.spam.gasops.co.uk>

| What is MULE? Is it an Emacs clone/implementation?

MUlti-Lingual (Extensions to) Emacs. it used to be a Japanese version of
Emacs that handled the special Japanese needs. then code from MULE was
merged with Emacs, and Emacs stopped working correctly outside of Japan,
which needed the extensions, and USA, where most people only use ASCII.
the rest of the world has outgrown 7-bit character sets, whether they are
singlebyte or multibyte, and use 8-bit bytes, mostly single-byte, but
also multibyte is used some places. MULE handles 7-bit character sets
well, and nothing else. to get proper 8-bit handling, you have to turn
off MULE. the really sad thing is that it wouldn't have cost a lot to
make Emacs continue to work well with 8-bit character sets, but the way
MULE encodes character-set + character-code-in-set instead of an actual
character code that might exist in multiple character sets, makes it very
hard to fix this particular fundamental design flaw. so even though
Emacs could equally easily have moved from 8-bit buffers to 16-bit or
even 24-bit buffers as it could have moved to multibyte encodings of
7-bit characters, which it did, you can't move "sidewise" between these
two options without first removing all the 7-bit junk.

#:Erik
--
SIGTHTBABW: a signal sent from Unix to its programmers at random
intervals to make them remember that There Has To Be A Better Way.

Sven Utcke

unread,
Jan 27, 1999, 3:00:00 AM1/27/99
to
Shaun Lipscombe <shaun.l...@no.spam.gasops.co.uk> writes:

> This may seem like a ridiculous question, but i'll ask anyway ....
>

> What is MULE? Is it an Emacs clone/implementation?

Both. It used to be a seperate implementation of Emacs, targeted for
the asian market: Multi-Lingual Emacs.

It is now this seperate implementation rolled back into Emacs proper:
Multi-Lingual Enhancement

It basically allows you to write in languages where a character is not
necessarily 8 bit, but 16.

However, I think it still doesn't allow you to write from the right to
the left, which makes it somewhat useless... (but maybe that's fixed).

Sven
--
_ _ Lehrstuhl fuer Mustererkennung und Bildverarbeitung
| |_ __ | |__ Sven Utcke
| | ' \| '_ \ phone: +49 761 203 8274 Am Flughafen 17
|_|_|_|_|_.__/ fax : +49 761 203 8262 79110 Freiburg i. Brsg.
mailto:ut...@informatik.uni-freiburg.de www.informatik.uni-freiburg.de/~utcke

Erik Naggum

unread,
Jan 27, 1999, 3:00:00 AM1/27/99
to
* Sven Utcke <ut...@tu-harburg.de>

| It basically allows you to write in languages where a character is not
| necessarily 8 bit, but 16.

sorry to correct this frequent misunderstanding, but only 7-, 14-, and
21-bit characters are handled by MULE. 8-bit characters are handled as
the sum of two sets of 7-bit characters, as opposed to Japanese and the
like, which are handled as the product of two or three 7-bit character
sets. had MULE been 8-bit-based, it would have been possible to make it
work right outside of Japan.

Eli Zaretskii

unread,
Jan 28, 1999, 3:00:00 AM1/28/99
to

On 27 Jan 1999, Sven Utcke wrote:

> However, I think it still doesn't allow you to write from the right to
> the left, which makes it somewhat useless... (but maybe that's fixed).

No, right-to-left direction are not supported, and won't be at least
until Emacs 20.5.

pi...@cs.uu.nl

unread,
Jan 28, 1999, 3:00:00 AM1/28/99
to
>>>>> Erik Naggum <er...@naggum.no> (EN) writes:

EN> MUlti-Lingual (Extensions to) Emacs. it used to be a Japanese version of
EN> Emacs that handled the special Japanese needs. then code from MULE was
EN> merged with Emacs, and Emacs stopped working correctly outside of Japan,
EN> which needed the extensions, and USA, where most people only use ASCII.
EN> the rest of the world has outgrown 7-bit character sets, whether they are
EN> singlebyte or multibyte, and use 8-bit bytes, mostly single-byte, but
EN> also multibyte is used some places. MULE handles 7-bit character sets
EN> well, and nothing else. to get proper 8-bit handling, you have to turn
EN> off MULE.

I am a bit surprised. I use emacs 20.3 / 20.4 pretest quite some time now
and I don't have any problems with 8-bit characters (latin1). So what kind
of problems are there to be expected, or are you referring to the
implementation?
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: Piet.van...@gironet.nl

Kai.Gro...@cs.uni-dortmund.de

unread,
Jan 28, 1999, 3:00:00 AM1/28/99
to
ab...@borpin.demon.co.uk (Brian Orpin) writes:

> What is the preferred solution to prevent MULE from screwing your
> system when (if) you migrate and what specific problems are
> encountered.

Just for the record: I use MULE and I have (almost) no problems with
it. The only difference I really see is that I can now see actual
Japanese names in Gnus...

TM doesn't seem to work, and the more recent version of TM is called
SEMI but doesn't support Gnus any longer. For this, they have created
Semi-Gnus. Thus, it is not simple to use TM with Gnus but avoid using
Semi-Gnus. What I do is to use the development version of Gnus which
groks MIME right out of the box (but is alpha code).

kai
--
Abort this operation? [Abort] [Cancel]

Erik Naggum

unread,
Jan 28, 1999, 3:00:00 AM1/28/99
to
* pi...@cs.uu.nl

| I am a bit surprised. I use emacs 20.3 / 20.4 pretest quite some time
| now and I don't have any problems with 8-bit characters (latin1). So
| what kind of problems are there to be expected, or are you referring to
| the implementation?

the implementation problems have been covered up so you don't directly
experience them, but people report seeing \201 all over the place because
the implementation is incredibly intrusive -- all the code that deals
with Latin 1 characters have to be upgraded to MULE-awareness, and if
this gets fixed, it's because of an incredible amount of code that tries
to hide the seriously flawed decision to support 7-bit character sets
instead of 8-bit character sets. for months, the most frequent changes
to the sources have been to make various code that worked just fine
before MULE but broke, MULE-aware so it once again works as expected. I
fully expect at least another year to pass before the last serious bug
has been fixed the same way, and then there will be small, annoying bugs
forever.

see, Emacs' basic assumption is that a character is a number, and if you
read a character off of a buffer or string, you really get a number that
has to contain enough information to be put back into another buffer or
string without loss of relevant information. this works OK when there is
one character set all over Emacs, and that used to be the case. with a
true character type, one could encode more information in characters than
Emacs does today, and everything would be tremendously easier.

MULE is also based on supporting 7-bit character sets, and although this
can be made to work with tremendous effort, it is unworkable without the
_rest_ of the machinery from ISO 2022, and MULE just fakes that part.
MULE also makes the fundamental mistake of encoding characters internally
as multibyte codes. this was never the way the character set designers
designed them to be handled. (I know, because I have discussed character
set issues in great detatil with the authors of these standards during my
ISO work.) both of these fundamental design flaws will make every new
idea harder to implement and require pervasive changes to support them.
that this "prediction" has proven true for the work that has gone into
making MULE "work" is no coincidence.

Dave Love

unread,
Jan 29, 1999, 3:00:00 AM1/29/99
to
>>>>> "piet" == piet <pi...@cs.uu.nl> writes:

piet> I am a bit surprised. I use emacs 20.3 / 20.4 pretest quite
piet> some time now and I don't have any problems with 8-bit
piet> characters (latin1).

Likewise. (I.e. `(standard-display-european 1)', as in Emacs19.)

piet> So what kind of problems are there to be expected,

Any that are expected should be reported as bugs immediately.


Dave Love

unread,
Jan 29, 1999, 3:00:00 AM1/29/99
to
>>>>> "BO" == Brian Orpin <ab...@borpin.demon.co.uk> writes:

BO> All the talk of what MULE does has put me off upgrading (well
BO> persuading the site admin to upgrade) to Emacs 20.x.

Don't be put off by FUD. Even Erik Naggum previously commended 20.3
to non-MULE users. You might want to wait for the 20.4, though, for
the usual crop of bugfixes unrelated to MULE.

BO> What is the preferred solution to prevent MULE from screwing your
BO> system when (if) you migrate and what specific problems are
BO> encountered.

If you don't want the MULEtilation, operate in unibyte mode (perhaps
unfortunately, not the default). If you use
(standard-display-european 1) in .emacs with Emacs 19, that's
more-or-less it. Alternatively, start with --unibyte or set
EMACS_UNIBYTE in the environment. Set inhibit-eol-conversion if you
like. This should all work through Custom in 20.4 (turn off multibyte
and set the language to Latin-N, say). Refer happily to Zöe, Séan and
Gallic mountains!

People like Kai G seem to operate perfectly OK anyway in the default
multibyte for (presumably) heavy Latin-1.

Ilya Zakharevich

unread,
Jan 30, 1999, 3:00:00 AM1/30/99
to
[A complimentary Cc of this posting was sent to Dave Love
<d.l...@dl.ac.uk>],
who wrote in article <rzq679p...@djlvig.dl.ac.uk>:

> >>>>> "BO" == Brian Orpin <ab...@borpin.demon.co.uk> writes:
>
> BO> All the talk of what MULE does has put me off upgrading (well
> BO> persuading the site admin to upgrade) to Emacs 20.x.
>
> Don't be put off by FUD. Even Erik Naggum previously commended 20.3
> to non-MULE users. You might want to wait for the 20.4, though, for
> the usual crop of bugfixes unrelated to MULE.

Oh, get real. 20.3 is unusable with --unibyte when in a TTY, due to
the bugs in the display engine. 20.4 is reported to fix this
particular bug, though, Set

(standard-display-8bit 128 254)

and try to load a file with this Mule-crap <201><whatever>.

Ilya

Sven Utcke

unread,
Feb 1, 1999, 3:00:00 AM2/1/99
to
Erik Naggum <er...@naggum.no> writes:

> * pi...@cs.uu.nl
> | I am a bit surprised. I use emacs 20.3 / 20.4 pretest quite some time
> | now and I don't have any problems with 8-bit characters (latin1). So
> | what kind of problems are there to be expected, or are you referring to
> | the implementation?
>
> the implementation problems have been covered up so you don't directly
> experience them, but people report seeing \201 all over the place because
> the implementation is incredibly intrusive

That's interesting. I certainly do get these bastards a lot. I've
inquired on g.e.h how to get rid of them and was told to
"(set-language-environment "Latin-1")" --- to no avail. Nothing I've
tried so far has been able to completely hide all the \201; however,
it seemed to work for anybody else (judging from the answers I got).
Now you tell me it's due to a basic design-flaw in MULE. Maybe it
_would_ be a good idea to get rid of MULE after all...

Kai.Gro...@cs.uni-dortmund.de

unread,
Feb 1, 1999, 3:00:00 AM2/1/99
to
Sven Utcke <ut...@tu-harburg.de> writes:

> [...] I certainly do get these bastards a lot. [...]

Do you run in unibyte mode? Try turning that off. Strange as it may
sound. I do not turn on unibyte, and I set the language environment,
and I have no problem.

But then, I don't really care whether MULE transforms each character
thrice, as long as I don't see it and it's not written to disk.

Eli Zaretskii

unread,
Feb 1, 1999, 3:00:00 AM2/1/99
to

On 30 Jan 1999, Ilya Zakharevich wrote:

> Oh, get real. 20.3 is unusable with --unibyte when in a TTY, due to
> the bugs in the display engine. 20.4 is reported to fix this
> particular bug, though

Speaking about which: somebody who can test Emacs on a TTY with and
without --unibyte should take a look at the latest pretest of 20.4. Me
thinks there are some unresolved problems there, especially when display
tables are used. I fixed these problems for the MSDOS version, but it
uses a different redisplay code. Judging by the source code, similar
changes should be done for Unix TTY displays.

Hannu Koivisto

unread,
Feb 1, 1999, 3:00:00 AM2/1/99
to
Sven Utcke <ut...@tu-harburg.de> writes:

| That's interesting. I certainly do get these bastards a lot. I've
| inquired on g.e.h how to get rid of them and was told to
| "(set-language-environment "Latin-1")" --- to no avail. Nothing I've
| tried so far has been able to completely hide all the \201; however,

Have you tried:

(set-language-environment "latin-1")
(set-input-mode (car (current-input-mode))
(nth 1 (current-input-mode))
0)
(set-terminal-coding-system 'latin-1)

This should make \201s disappear whether you use unibyte or
multibyte mode. Well, at least it does that for me. There's an
alternative way too; you could replace that set-input-mode with
set-keyboard-coding-system, but I prefer this way.

//Hannu

Dave Love

unread,
Feb 1, 1999, 3:00:00 AM2/1/99
to
>>>>> "Ilya" == Ilya Zakharevich <il...@math.ohio-state.edu> writes:

Ilya> Oh, get real. 20.3 is unusable with --unibyte when in a TTY,
Ilya> due to the bugs in the display engine.

On the contrary; I've been using unibyte tty mode continually since it
was available. I currently only normally use vanilla 20.3 in unibyte
over tty to the FSF to do maintenance there, but use it I do.

I'm baffled by the connexion between 8-bit redisplay and load. It
might be helpful to explain the circumstances surrounding the somewhat
obscure way of operating so that it can be checked with the rewritten
redisplay. I don't think my available fonts make such configuration
reasonable, quite apart from the data I display.

Dave Love

unread,
Feb 1, 1999, 3:00:00 AM2/1/99
to
>>>>> "Kai" == Kai Grossjohann <Kai.Gro...@CS.Uni-Dortmund.DE> writes:

Kai> Sven Utcke <ut...@tu-harburg.de> writes:
>> [...] I certainly do get these bastards a lot. [...]

Kai> Do you run in unibyte mode? Try turning that off.

Better, try upgrading from the 20.2 indicated by the Gnus header.

Kai> Strange as it may sound. I do not turn on unibyte, and I set
Kai> the language environment, and I have no problem.

Good-oh. I do run almost exclusively unibyte and I don't have such
problems either, so it probably doesn't matter much. I don't think
I've generated a \201 since I hacked around the last bit of code
confused by the MBSK Emacs 20.2.

TM is a likely cause of trouble. (I don't know what the current state
of SEMI is.) Beware of similar somewhat MULE-aware packages that
don't properly support the current Emacs. Early versions of the
development Pterodactyl Gnus may also have had trouble despite larsi's
heroic effort.

James H. Cloos Jr.

unread,
Feb 1, 1999, 3:00:00 AM2/1/99
to
>>>>> "Hannu" == Hannu Koivisto <az...@iki.fi.ns> writes:

Hannu> Have you tried:

Hannu> (set-language-environment "latin-1") (set-input-mode (car
Hannu> (current-input-mode)) (nth 1 (current-input-mode)) 0)
Hannu> (set-terminal-coding-system 'latin-1)

Having recently upgraded from emacs-20.2 as shipped with redhat 5.1 to
20.3 as shipped with redhat 5.2, I've noticed this problem for the
first time. In 20.2 I had been running with just
(standard-display-european t), but have now switched to the above
code.

Most buffers show everything well, but *Help* does not. Specifically,
the contents of *Help* as generated by (describe-bindings).

If it matters, I do still (require 'iso-transl).

-JimC
--
James H. Cloos, Jr. <http://www.jhcloos.com/cloos/public_key> 1024D/ED7DAEA6
<cl...@jhcloos.com> E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6

Dave Love

unread,
Feb 1, 1999, 3:00:00 AM2/1/99
to
>>>>> "Rat" == Stainless Steel Rat <rat...@peorth.gweep.net> writes:

Rat> Erik recomended that FSF Emacs 19 users try FSF Emacs 20.3 and
Rat> report any problems to him.

If they did, I hope the reports were passed on and that people will
report problems to bug-gnu-emacs for maintainers' attention.

Rat> That is not quite the same thing as the words Dave is putting
Rat> into Erik's mouth.

Well, I have <31129048...@naggum.no> to hand. I didn't look
further:

Erik> | Does Naggum etc think that it is ready to be
Erik> | used by non-hackers, ie is pretty bug-free?

Erik> well, there have been a _lot_ of changes, mostly actual
Erik> improvements, so if you really want me to say "go for it",
Erik> I'll say "go for it!"

Likewise. (Except that for people supporting groups of it's probably
worth waiting a week or two for 20.4 to appear with more
improvements.)

Erik> | What is the recommendation?

Erik> help make 20.4 bug-free by actually using 20.3.

But apparently others shouldn't advocate improving 20.3/4 now...

Erik> _real_ problems with MULE in 20.3 concern me.

Likewise. I don't see them, but report any that remain unresolved
_urgently_.

Erik> I'm not going to make any MBSK for 20.3 or an Emacs 19
Erik> release without _actual_ problems that don't get solved in
Erik> the official distribution

I hope the question won't arise. It's what the volunteers still doing
maintenance work are trying for AFAIK.

Rat> Or install XEmacs 20.4 instead, which can be compiled without
Rat> MULE and is generally faster and more stable/reliable than the
Rat> FSF counterpart in that state.

I'd still like to see the data which contradict my measurements of
similar speed and my understanding of what XEmacs maintainers think.
Also unbiased data on how `stable/reliable' they are in comparison;
I'd guess similar again. The only major reliability problem I can
recall with 20.3 -- now apparently fixed -- was a GC problem that
might bite after a fortnight or so of heavy use to a ~20MB image. I
can only speak for serious unibyte operation.

People who -- per the Antinews -- need to regress from the Emacs
20.3/4 will probably be more comfortable going to Emacs 19 than XEmacs
20. Note that there are lots of improvements to miss that are
completely unrelated to MULEtilation.

Erik Naggum

unread,
Feb 1, 1999, 3:00:00 AM2/1/99
to
* Dave Love <d.l...@dl.ac.uk>

| TM is a likely cause of trouble. (I don't know what the current state of
| SEMI is.) Beware of similar somewhat MULE-aware packages that don't
| properly support the current Emacs. Early versions of the development
| Pterodactyl Gnus may also have had trouble despite larsi's heroic effort.

well, thank you for helping me point out why MULE is inherently flawed in
its design. intelligent support for larger character sets wouldn't need
all packages everywhere to be written to support it, particularly not
with "heroic effort".

Erik Naggum

unread,
Feb 2, 1999, 3:00:00 AM2/2/99
to
[ I normally try to undo the horrendous quoting style Dave uses, but this
time, it's too much manual work. sorry about the disgusting appearance. ]

* Dave Love <d.l...@dl.ac.uk>


| Rat> That is not quite the same thing as the words Dave is putting
| Rat> into Erik's mouth.
|
| Well, I have <31129048...@naggum.no> to hand. I didn't look
| further:
|
| Erik> | Does Naggum etc think that it is ready to be
| Erik> | used by non-hackers, ie is pretty bug-free?
|
| Erik> well, there have been a _lot_ of changes, mostly actual
| Erik> improvements, so if you really want me to say "go for it",
| Erik> I'll say "go for it!"
|
| Likewise. (Except that for people supporting groups of it's probably
| worth waiting a week or two for 20.4 to appear with more
| improvements.)

I'm faintly amused by this. you appear to be exceedingly good at
ignoring context, so good in fact, that I don't think you really
understand the concept. in this case, people were asking me about 20.2
and the future of MBSK. I recommended to try 20.3, instead. it seldom
hurts to try new things, but if I were to say this _now_, it would be a
very different thing indeed. that message was posted 1998-08-23. as you
yourself point out, 20.3 requires all packages written before MULE to be
upgraded to "understand" MULE, which means to make them unusable with
other version of Emacs. lots of people have reported problems but have,
understandably, refused to waste their time fixing the.

| But apparently others shouldn't advocate improving 20.3/4 now...

of course. some of us humans have a working brain, and part of what
makes it work is that we learn something as time passes. sometimes, this
means changing one's mind, and sometimes when we set out to discover
something, we discover something else. hopes fail to come true, etc.

I see, however, that it is _necessary_ for Dave Love to be disingenous in
the extreme to at all have a point. falsifying people's statements and
taking them out of their context is a well known tactic among people who
have nothing else to argue with. as I have said many times over, you
learn a lot about somebody by how they react when angry. I use strong
language and say _exactly_ what I think. Dave Love shows that he is
really a dishonest dirtbag, because he turns to dishonesty when he has
nothing left. I'm not particularly surprised to see this from either him
or Eli Zaretskii. it takes a certain moral character to stomach MULE.

| People who -- per the Antinews -- need to regress from the Emacs 20.3/4
| will probably be more comfortable going to Emacs 19 than XEmacs 20. Note
| that there are lots of improvements to miss that are completely unrelated
| to MULEtilation.

there are indeed a lot of improvements. I think people should move to
XEmacs if they don't like MULE. not because I love XEmacs, but because
it has finally dawned on me that all the crap in Emacs comes from the
desire to compete with XEmacs. the only way to make Emacs better is thus
to make people leave for XEmacs, as nothing else will make improvements
to Emacs. sad, but true.

Hannu Koivisto

unread,
Feb 2, 1999, 3:00:00 AM2/2/99
to
"James H. Cloos Jr." <cl...@jhcloos.com> writes:

| Having recently upgraded from emacs-20.2 as shipped with redhat 5.1 to
| 20.3 as shipped with redhat 5.2, I've noticed this problem for the

...


| Most buffers show everything well, but *Help* does not. Specifically,
| the contents of *Help* as generated by (describe-bindings).

Sorry, I don't use RedHat (I'm using Debian) so I don't know if
RedHat does something in their site-init that could affect this.
Something like that would be my guess as I don't see any obvious
reason why *Help* generated by (describe-bindings) wouldn't be
ok with that code (it is for me). You could try with
--no-site-file option.

| If it matters, I do still (require 'iso-transl).

As far as I can see, it affects only input, so it shouldn't
matter. Btw, as you are using iso-transl, that ``(set-input-mode
...'' in my example code is probably futile for you (that my
code is meant for people who live in countries where latin-1 is
used by default).

//Hannu

Kai.Gro...@cs.uni-dortmund.de

unread,
Feb 2, 1999, 3:00:00 AM2/2/99
to
Erik Naggum <er...@naggum.no> writes:

> [...] as you yourself point out, 20.3 requires all packages


> written before MULE to be upgraded to "understand" MULE, which

> means to make them unusable with other version of Emacs. [...]

I think Dave said that packages which half-grok MULE needed to be
upgraded, and he pointed to TM as a suspect. In fact, what you need
to do to get TM working in Emacs 20.3 is to tell it that it's running
on a non-MULE Emacs.

In fact, TM has been the only package I had problems with.

I used rmime.el instead, and it worked just like in 19.34. It was the
same rmime.el that I had been using with 19.34, in fact.

(Now I use Pterodactyl Gnus and don't have a need for an extra MIME
package.)

But then, I only use Latin-1 and don't know a thing about the problems
with CJK.

kai
--
I like _ b_ o_ t_ h kinds of music.

Kai.Gro...@cs.uni-dortmund.de

unread,
Feb 2, 1999, 3:00:00 AM2/2/99
to
Stainless Steel Rat <rat...@peorth.gweep.net> writes:

> There is something seriously wrong with MULE if even 'heroic
> effort' fails to produce something that works properly.

It is not surprising at all that early versions of anything have a
number of bugs. I don't think that the early versions of MULE support
had significantly more or fewer bugs than the early versions of
anything else in Gnus (the Agent, the new mail-source mechanism...).

Kai.Gro...@cs.uni-dortmund.de

unread,
Feb 2, 1999, 3:00:00 AM2/2/99
to
Stainless Steel Rat <rat...@peorth.gweep.net> writes:

> Agreed with the 'early version' idea. FSF Emacs 20.3 is *NOT* an
> early version of anything.

We were talking about early versions of pgnus, not of Emacs.

James H. Cloos Jr.

unread,
Feb 2, 1999, 3:00:00 AM2/2/99
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

cloos> If it matters, I do still (require 'iso-transl).

Hannu> As far as I can see, it affects only input, so it shouldn't
Hannu> matter. Btw, as you are using iso-transl, that
Hannu> ``(set-input-mode ...'' in my example code is probably futile
Hannu> for you (that my code is meant for people who live in countries
Hannu> where latin-1 is used by default).

I use iso-transl to make the Alt key do something useful (I have Meta
on Meta).

I tried running with -q and --no-site-file, eval'ing your example in
*scratch* and then requiring iso-transl. I still get the octal
escapes *Help*. But what I didn't point out (and probably didn't even
notice) is that it is only the key translations section of the
bindings that has the octal escapes, and then only in the binding
column, and that is probably because iso-transl.el has code like this
in it:

(defvar iso-transl-char-map
'(("* " . [160])(" " . [160])
("*!" . [161])("!" . [161])
("\"\"" . [168])
("\"A" . [196])
("\"E" . [203])
("\"I" . [207])

etc.

Ie, the 8bit chars are stored raw, not MULE-encoded.

So, is there a better way of getting Alt-Foo, for various Foo, to let
me input non-ascii characters?

(BTW, describe-input-method says I have none, and describe-coding-
system says my coding system for keyboard input is nil. I presume
I need to change something related to these???)

TIA for any info!

- -JimC
- --

James H. Cloos, Jr. <http://www.jhcloos.com/cloos/public_key> 1024D/ED7DAEA6
<cl...@jhcloos.com> E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE2tz+fmXqfF+19rqYRAlSYAJ4p1+OLmIfO8kvTQrWG8PYSb/WJswCgkLU+
Mwap/sto0jS73ecbAbDcJys=
=yZap
-----END PGP SIGNATURE-----

Karl Eichwalder

unread,
Feb 2, 1999, 3:00:00 AM2/2/99
to
Kai.Gro...@CS.Uni-Dortmund.DE writes:

| But then, I don't really care whether MULE transforms each character
| thrice, as long as I don't see it and it's not written to disk.

Happy you... Once in a while you'll be bitten.

Just yesterday I tried with Emacs 20.3(*) "Print Region" from the menubar
(it was a region with 8bit characters, german "umlauts"): in front of
every "umlaut" there was "printed" a spurious white space.

Such things use to work with Emacs 19 out-of-the-box; maybe, my setup is
wrong -- but on the other hand, I don't see these \201 specials as with
Emacs 20.2.

(*) Sic! Don't judge from the header line of this article; this one is a
different little Linux box...

--
Karl Eichwalder

Erik Naggum

unread,
Feb 2, 1999, 3:00:00 AM2/2/99
to
* Kai.Gro...@CS.Uni-Dortmund.DE

| It is not surprising at all that early versions of anything have a number
| of bugs. I don't think that the early versions of MULE support had
| significantly more or fewer bugs than the early versions of anything else
| in Gnus (the Agent, the new mail-source mechanism...).

having suffered all kinds of betaware over the years (voluntarily, since
I"m not a Microsoft victim), I have to disagree: MULE was very different
from every other piece of immature software I have used. late Emacs 19
worked in Europe, but not in Japan. then MULE got merged into it to make
it Emacs 20. the result was that Emacs 20 worked in Japan, but not in
Europe. whatever you do to add something to an existing system, you just
_don't_ destroy what worked, and whatever you do when you add something
that changes the core behavior of a working system, you just _don't_
forget to include a way to turn it off (or, preferably, on), if for no
other reason than to ensure that you can test your new stuff. Emacs with
MULE barely compiled from the merged sources and didn't work at all for
several months. such is just mind-bogglingly incompetent. the same is
true of a _lot_ of Japanese MULE "fixes". while it happens that other
maintainers make mistakes and reverse fixes, it is fairly unusual. for
the MULE team, it happened _regularly_, and it still happens regularly.
they cannot even have _tried_ to test their code prior to committing it.

I was aghast with disbelief in the incredible display of incompetence,
and this was in _Emacs_, previously the most stable piece of free
software I had used, not something out of Redmond, WA, for chrissake!

I expect software _not_ to fail. the MULE folks cannot have shared any
sentiment even _close_ to mine.

Kai.Gro...@cs.uni-dortmund.de

unread,
Feb 3, 1999, 3:00:00 AM2/3/99
to
I wasn't aware that it was *that* bad. I mean, I had been thinking of
spaghetti code but not of code which almost didn't even compile.

I am now even more amazed that I (personally) have so few problems
with MULE!

Eli Zaretskii

unread,
Feb 3, 1999, 3:00:00 AM2/3/99
to

On Tue, 2 Feb 1999, Karl Eichwalder wrote:

> Just yesterday I tried with Emacs 20.3(*) "Print Region" from the menubar
> (it was a region with 8bit characters, german "umlauts"): in front of
> every "umlaut" there was "printed" a spurious white space.

As far as I could see, this is fixed in Emacs 20.4.

Andrew Innes

unread,
Feb 3, 1999, 3:00:00 AM2/3/99
to
On 01 Feb 1999 23:57:57 +0000, Erik Naggum <er...@naggum.no> said:
>* Dave Love <d.l...@dl.ac.uk>
>| TM is a likely cause of trouble. (I don't know what the current state of
>| SEMI is.) Beware of similar somewhat MULE-aware packages that don't
>| properly support the current Emacs. Early versions of the development
>| Pterodactyl Gnus may also have had trouble despite larsi's heroic effort.
>
> well, thank you for helping me point out why MULE is inherently flawed in
> its design. intelligent support for larger character sets wouldn't need
> all packages everywhere to be written to support it, particularly not
> with "heroic effort".

Erik, your last sentence touches on something I would like to understand
better, because it seems to nicely sum up your criticism of MULE, and is
fundamental to any attempt to reverse the damage of MULE and finish the
job properly.

In my limited experience of MULE (mostly from fixing a few MULE-related
or -induced bugs during the 20.3 pretesting), I found that packages like
jka-compr, ange-ftp and arc-mode needed to be altered to control the
encoding/decoding applied during file/process IO at certain stages,
eg. to disable translation when processing files in their compressed
state.

(For reference, this issue already applied to the DOS/Windows ports of
Emacs 19.x, because of the need to cope with DOS vs. Unix EOL
conventions; jka-compr was still broken in 19.34 for instance - I
finally fixed this for the Windows-specific 19.34.6 release, or possibly
even later.)

Now, I don't know if this is typical of the kind of change required for
a package to become MULE-aware (meaning MULE-safe I guess, as opposed to
MULE-savvy), but my impression so far is that control of translation for
IO is one of the main issues. It also seems to me that the need to
specify the translations required for external IO is unavoidable,
regardless of the internal structure of the MULE code.

I assume (maybe wrongly) you feel that an intelligent design would
handle this issue better than MULE does, with its proliferation of
controls like coding-system-for-read/write, process-coding-system-alist,
etc etc. (Put like this, it sounds obvious there must be a better way,
but I don't feel I know Emacs well enough to suggest one that is in
keeping with its pre-MULE design or spirit.)

So, could you please describe, if only briefly, how you would approach
this issue if you were designing an internationalized Emacs?

The other main change I know of that may be needed for a package to be
MULE-aware/safe (at least from 20.3 onwards, where multibyte characters
in buffers and strings are "atomic"), is to make sure that there are no
assumptions that characters in buffers or strings are necessarily in the
range 0-255. Again, I don't see how this issue can be avoided,
regardless of the implementation. (Aside: I'm also not clear on what
the advantage of a distinct character type is supposed to be, as opposed
to representing characters as ordinary numbers.)

Have I missed the point? Is there something more beyond these two or
three issues which is a significant problem for making existing packages
work in a multilingual Emacs (and would those somethings be an issue no
matter what implementation was chosen)?

Thanks for any enlightenment you can offer.

AndrewI

PS. Please note this is not a flame - I am not particularly experienced
in designing or implementing multilingual or internationalized
applications; certainly nothing on the scale of Emacs which might be
expected to handle text in multiple languages both gracefully and
seamlessly. I also have no vested interest in the design or
implementation of MULE, nor any strong opinions about it for that
matter. However, I would like to see Emacs mature into the powerful
multilingual editor it could be.

So I would genuinely like to know how you, and any others who are
experienced in these matters, would approach the task of making Emacs
truly international in character (pardon the pun) while preserving its
original (pre-MULE) spirit. Maybe the answer to that really starts with
defining the spirit of Emacs as you see it.

Erik Naggum

unread,
Feb 3, 1999, 3:00:00 AM2/3/99
to
* Kai.Gro...@CS.Uni-Dortmund.DE

| I am now even more amazed that I (personally) have so few problems
| with MULE!

it could well be that you are simply an extremely mainstream Emacs user
and that all the problems you would have discovered were taken care of
early. judging from the ChangeLogs, there are still people who run into
serious problems with MULE and which mandates an upgrade to "awareness"
of MULE or even "intimacy" with it in other code. I have always had a
tendency to use software to their fullest, and have run into small bugs
in Franz Inc's Allegro Common Lisp that have been undetected for 9 years.
don't know if I'm attracting trouble, but if so, it would explain a lot
of other things, too. :)

Kai.Gro...@cs.uni-dortmund.de

unread,
Feb 4, 1999, 3:00:00 AM2/4/99
to
Kai.Gro...@CS.Uni-Dortmund.DE writes:

> [...] In fact, what you need to do to get TM working in Emacs 20.3
> is to tell it that it's running on a non-MULE Emacs. [...]

Eek. I hate spreading false rumors and therefore let me add that I
remembered that this wasn't what I did at all. Thus, I'm not sure
whether this is really true.

I did a horrible hack to unconditionally remove \201 characters from
Gnus article buffers, instead :-(

I *think* that the right way would have been to tell TM that Emacs
doesn't grok MULE, but I haven't actually tried it.

Sorry,

Dave Love

unread,
Feb 4, 1999, 3:00:00 AM2/4/99
to
>>>>> "Rat" == Stainless Steel Rat <rat...@peorth.gweep.net> writes:

Rat> I posted my data several months ago. If you missed it, that is your
Rat> problem.

Perhaps someone else can point them out.

Rat> If you are that concerned about it, build yourself a copy of
Rat> XEmacs 20.4 without any options on your system of choice and run
Rat> it side-by-side with FSF Emacs 20.3.

I made measurements which were a counterexample to the claim that
XEmacs built without MULE is generally faster than Emacs 20.3.
They're about the same on the XEmacs benchmark package, for instance.
It doesn't seem sensible to run two such benchmarks together.

DL> I'd guess similar again.

Rat> You'd guess.

In the absence of measurements, yes.

Rat> I have personal experience, you have hearsay.

I have some personal experience which I don't regard as reliable data.

Rat> That says a lot, I think.

`Scientist'.

DL> The only major reliability problem I can recall with 20.3 -- now
^^^^^

Rat> And lo, Dave dismisses data corruption as not being serious or major.

My data weren't corrupted.

Dave Love

unread,
Feb 4, 1999, 3:00:00 AM2/4/99
to
>>>>> "Rat" == Stainless Steel Rat <rat...@peorth.gweep.net> writes:

Rat> pGnus was mentioned for its failure to cope with MULE even under
Rat> 'heroic effort'.

_Early test versions_, often not used according to instructions, were
mentioned in a specific context. As I understand it, it's now an
example of something that does work decently with the messy issues.
It works reasonably in unibyte mode for me.

Dave Love

unread,
Feb 4, 1999, 3:00:00 AM2/4/99
to
>>>>> "Erik" == Erik Naggum <er...@naggum.no> writes:

Erik> in this case, people were asking me about 20.2
Erik> and the future of MBSK. I recommended to try 20.3, instead.

The poster didn't seem to be, but the context of the response is
clearly unibyte operation (which is what MBSK tried for, unless I was
misled by the sales pitch). 20.3 allows this easily and reliably.

Erik> | But apparently others shouldn't advocate improving 20.3/4 now...

Erik> of course. some of us humans have a working brain, and part
Erik> of what makes it work is that we learn something as time
Erik> passes.

Such as the increasing technical merit of that recommendation. And
why is it necessary to attempt to intimidate people with slander into
saying otherwise in the absence of anything more than conspiracy
theory (AFAICT)? They might be persuaded by some actual facts of
which they were unaware.

--
help make 20.4 bug-free -- Erik Naggum, 1998-08-23

Still summer in my heart.

Dave Love

unread,
Feb 4, 1999, 3:00:00 AM2/4/99
to
>>>>> "Kai" == Kai Grossjohann <Kai.Gro...@CS.Uni-Dortmund.DE> writes:

Kai> Erik Naggum <er...@naggum.no> writes:
>> [...] as you yourself point out, 20.3 requires all packages
>> written before MULE to be upgraded to "understand" MULE, which
>> means to make them unusable with other version of Emacs. [...]

Kai> I think Dave said that packages which half-grok MULE needed to be
Kai> upgraded, and he pointed to TM as a suspect.

Indeed. What Erik said is clearly absurd, regardless of what I said.
That's obvious from experiment and/or the changelogs for those who
don't actully maintain old packages.

It's more ridiculous since the important point about 20.3 here is the
unibyte mode in which Emacs 19 packages just run unmolested anyway.

W3 and Gnus are obvious examples of things that run on a range of MULE
and non-MULE Emacsen while allowing people that want to use MULE.

Dave Love

unread,
Feb 4, 1999, 3:00:00 AM2/4/99
to
>>>>> "Kai" == Kai Grossjohann <Kai.Gro...@CS.Uni-Dortmund.DE> writes:

Kai> I wasn't aware that it was *that* bad. I mean, I had been
Kai> thinking of spaghetti code but not of code which almost didn't
Kai> even compile.

I don't know how `barely' it didn't compile, but typical development
snapshots of other complex systems done by volunteer teams don't work
generally almost by definition, especially after major merges. The
description of that stage of Emacs development is similar to the
recent state of the egcs compiler, for instance. People can look in
on that. (egcs was somewhat perturbed by an internationalization
merge but the major causes of instability have been elsewhere.)

Erik Naggum

unread,
Feb 5, 1999, 3:00:00 AM2/5/99
to
* Dave Love <d.l...@dl.ac.uk>

| The poster didn't seem to be, but the context of the response is
| clearly unibyte operation (which is what MBSK tried for, unless I was
| misled by the sales pitch). 20.3 allows this easily and reliably.

oh, so 20.3 allows this easily and reliably? I must wonder what all the
works _since_ 20.3 that has removed a lot of spurious errors in unibyte
mode were all about, then. you're a real idiot, Dave Love. I pity you.

| Such as the increasing technical merit of that recommendation.

in your view, but we have already determined that facts that run counter
to your opinion does not count, so who cares what you think?

| And why is it necessary to attempt to intimidate people with slander into
| saying otherwise in the absence of anything more than conspiracy theory
| (AFAICT)?

I have already defeated the insipid "conspiracy theory" theory. there is
no conspiracy, just sheer incompetence and the arrogance that goes with
it when idiots get defensive.

| They might be persuaded by some actual facts of which they were unaware.

you haven't been, and you have had them all delivered to you in the past
few weeks, but you remain utterly convinced of your false belief that
people should have no problems with MULE. how come people have problems?
it must be because _they_ engage in conspiring to destroy MULE, right?
(after all, you're the conspiracy buff here, not me.) the fact that they
appear to spring up from random places and have lots of concerns that are
made to look independent only strengthens your belief that they are just
a bunch of loonies conspiring against Japanese users of Emacs, right?

MULE will never get better. Dave Love will make certain it remains as
bad as it is today, because improving it might actually prove him wrong:
that MULE was somehow _not_ perfect when he said it was.

#:Erik
--
Y2K conversion of date sensitive software simplified: Januark, Februark,
March, April, Mak, June, Julk, August, September, November, December

Ilya Zakharevich

unread,
Feb 5, 1999, 3:00:00 AM2/5/99
to
[A complimentary Cc of this posting was sent to Dave Love
<d.l...@dl.ac.uk>],
who wrote in article <rzq7ltx...@djlvig.dl.ac.uk>:
> Such as the increasing technical merit of that recommendation. And

> why is it necessary to attempt to intimidate people with slander into
> saying otherwise in the absence of anything more than conspiracy
> theory (AFAICT)?

... only several lines after the following:

> The poster didn't seem to be, but the context of the response is
> clearly unibyte operation (which is what MBSK tried for, unless I was
> misled by the sales pitch). 20.3 allows this easily and reliably.

This is a deliberate wrong statement. You have seen my bug report
(about --unibyte being useless in a TTY) only a day or two ago, and
now you say this R-word! You think people need a "conspiracy theory"
after this?

Ilya

Steinar Bang

unread,
Feb 5, 1999, 3:00:00 AM2/5/99
to
>>>>> Kai.Gro...@CS.Uni-Dortmund.DE:

> I *think* that the right way would have been to tell TM that Emacs
> doesn't grok MULE, but I haven't actually tried it.

I tried it. I was unable to find all the different places this
behaviour was assumed. I gave up and installed XEmacs instead.

Steinar Bang

unread,
Feb 5, 1999, 3:00:00 AM2/5/99
to
>>>>> Dave Love <d.l...@dl.ac.uk>:

> W3 and Gnus are obvious examples of things that run on a range of
> MULE and non-MULE Emacsen while allowing people that want to use
> MULE.

Er... did you miss that part about "heroic effort"...?

Hannu Koivisto

unread,
Feb 5, 1999, 3:00:00 AM2/5/99
to
"James H. Cloos Jr." <cl...@jhcloos.com> writes:

[Sorry for late response.]

| I use iso-transl to make the Alt key do something useful (I have Meta
| on Meta).

Ok.

| I tried running with -q and --no-site-file, eval'ing your example in
| *scratch* and then requiring iso-transl. I still get the octal
| escapes *Help*. But what I didn't point out (and probably didn't even

I think I was able to duplicate this behaviour. So your *Help*
contains something like:
"""
mute-asciicircum Prefix Command
A-^ Prefix Command
A-Y \245
A-S \247
A-R \256
A-P \266
A-L \243
A-C \251
A-? \277
"""
?

Actually, even without iso-transl I can see at least this kind
of row:
"""
\240 .. \377 self-insert-command
"""
(although this case could be a feature so that one can see the
numeric range.)

Now, I think this is some sort of a (mis)feature. At least in my
case, if I put cursor at the beginning of, say, ``\277'' (in
other words, on top of ``\''), and then press C-f, the cursor
moves on top of ``2'' (you could test this too). If I'm not
mistaken, this means that that octal code is not a single
character (that is, incorrectly diplayed one), but ``\277''
really is four characters and thus this would seem to be
intentional. Why -- I don't know. Perhaps someone more familiar
with Emacs internals can explain this behaviour?

| Ie, the 8bit chars are stored raw, not MULE-encoded.

Based on the test explained above, at least in my case this
doesn't seem to be true. Try moving your cursor over some octal
number in your *Help* buffer and see if it "jumps" over the
whole number with one C-f.

| So, is there a better way of getting Alt-Foo, for various Foo, to let
| me input non-ascii characters?

I don't know. As a Finn I'm using a keyboard with ä, ö and å, so
I have never needed such a feature.

| (BTW, describe-input-method says I have none, and describe-coding-
| system says my coding system for keyboard input is nil. I presume
| I need to change something related to these???)

I'm not sure, but I don't think that affects this situation.

//Hannu

Alex Schroeder

unread,
Feb 5, 1999, 3:00:00 AM2/5/99
to
>>>>> "Hannu" == Hannu Koivisto <az...@iki.fi.ns> writes:

Hannu> Now, I think this is some sort of a (mis)feature. At least
Hannu> in my case, if I put cursor at the beginning of, say,
Hannu> ``\277'' (in other words, on top of ``\''), and then press
Hannu> C-f, the cursor moves on top of ``2'' (you could test this
Hannu> too). If I'm not mistaken, this means that that octal code

I can confirm this, too. I am using NT Emacs 20.3, set
EMACS_MULTIBYTE=1 and have the following code in my startup files:

(set-language-environment "Latin-1")
; this is from the info file to enable latin-1 input from the keyboard
;(set-input-mode (car (current-input-mode))
; (nth 1 (current-input-mode))
; 0)
; use C-x 8 as compose key
(load-library "iso-transl")

Alex.
--
http://www.geocities.com/TimesSquare/6120/ %o / _
%o _%o_/ <b--+ \ %O Ś \
%o odMMp' / M M / \dB--+__Ś_/__
..oooOOO/ /\ /\ / \\ /`L `L\_ __|__

Eli Zaretskii

unread,
Feb 7, 1999, 3:00:00 AM2/7/99
to

On 4 Feb 1999, Stainless Steel Rat wrote:

> Uh-huh. What about the \201 'errors' that are frequenly seen when FSF
> Emacs 20.3 is run in unibyte mode? Fact is, many of those \201s are
> because of a *MULTI*byte character being dumped into the works when it
> supposedly has been disabled.

As far as I could see, these problems don't happen anymore in latest
pretests of Emacs 20.4.

Dave Love

unread,
Feb 7, 1999, 3:00:00 AM2/7/99
to
>>>>> "Ilya" == Ilya Zakharevich <il...@math.ohio-state.edu> writes:

Ilya> This is a deliberate wrong statement. You have seen my bug report
Ilya> (about --unibyte being useless in a TTY) only a day or two ago,

This is a deliberate wrong statement. You have seen my posting (and
subsequent mail) about using it continually in that mode. Theer was a
bug in an unusual mode of operation (actually nothing to do with
`load'). Thanks -- that's what we ask people to do. However, I don't
share the view as I understand it that Latin-N character sets are
somehow broken and that using them doesn't count. Clearly 20.3
unibyte tty isn't absolutely reliable any more than it's absolutely
useless, but I rely on it.

Dave Love

unread,
Feb 7, 1999, 3:00:00 AM2/7/99
to
>>>>> "SB" == Steinar Bang <s...@metis.no> writes:

SB> I tried it. I was unable to find all the different places this
SB> behaviour was assumed.

I asked how my old fixes for TM/SEMI (actually only its support
library?) with unibyte didn't work, but didn't get the info. I might
still update it if there's real demand for TM and SEMI doesn't now
DTRT. I dumped TM long ago and don't remember details, though. The
old stuff is at <URL:ftp://ftp.dl.ac.uk/pub/fx/emacs/MIME-emu-mbsk>.

Dave Love

unread,
Feb 7, 1999, 3:00:00 AM2/7/99
to
>>>>> "SB" == Steinar Bang <s...@metis.no> writes:

SB> Er... did you miss that part about "heroic effort"...?

I hope I don't forget Perry and Larsi heroism, but did you miss that
assertion that it wasn't even possible?

Dave Love

unread,
Feb 7, 1999, 3:00:00 AM2/7/99
to
>>>>> "Rat" == Stainless Steel Rat <rat...@peorth.gweep.net> writes:

Rat> Uh-huh. What about the \201 'errors' that are frequenly seen
Rat> when FSF Emacs 20.3 is run in unibyte mode?

AFAIK the problems occur in the post-Emacs 19 packages I mentioned
before. If there are other problems of which I'm unaware for Emacs 19
packages, I'd like to know.

Rat> Fact is, many of those \201s are because of a *MULTI*byte
Rat> character being dumped into the works when it supposedly has
Rat> been disabled.

Presumably any \201s arise from multibyte stuff. AFAIR the cases I'm
aware of are due to encoding being done explicitly by MULEtilated
programs when it shouldn't be. I don't know how Emacs 19 code would
generate multibyte data; I don't see any.

DL> W3 and Gnus are obvious examples of things that run on a range of
DL> MULE and non-MULE Emacsen while allowing people that want to use
DL> MULE.

Rat> Only because of the hoops MULE has forced William and Lars to
Rat> jump though to get their programs working.

That's not exactly how I'd read the Gnus 5.[56] changelogs, but it
_can_ plainly be done. (W3 contained explicit support for MULE before
it appeared in Emacs; I had the first stab for Emacs pre-20.3 IIRC.)

Emacs/XEmacs differences actually seem to be more of a pain than
specifying coding systems when necessary. Obviously _using_ MULE
features is a different matter, but Lars seemed to be rather enjoying
it last I noticed. (Rather him than me.)

Dave Love

unread,
Feb 8, 1999, 3:00:00 AM2/8/99
to
>>>>> "Erik" == Erik Naggum <er...@naggum.no> writes:

Erik> oh, so 20.3 allows this easily and reliably?

Yes, it allows unibyte mode to be thus established. It also is
decently reliable in use, certainly compared with MBSK 20.2.
Otherwise I'd say so.

Erik> I must wonder what all the works _since_ 20.3 that has
Erik> removed a lot of spurious errors in unibyte mode were all
Erik> about, then.

Presumably the fixes for rarely-exhibited problems I (and others)
didn't encounter in prerelease, as usual; the sort of things we've
asked people to uncover in wider use. _I've_ actually been using it
heavily, making minor fixes of various sorts and seeing the bug
reports. I don't recall anything that bit me specific to unibyte
mode, though I know Eli has uncovered redisplay problems in areas I
don't venture. Is multibyte more reliable? If so, excellent.

The compiler system I used to build it has surely had more fixes in
the relevant period; I see them as well as the bug reports.

Erik> MULE will never get better. Dave Love will make certain it
Erik> remains as bad as it is today, because improving it might
Erik> actually prove him wrong: that MULE was somehow _not_ perfect
Erik> when he said it was.

Oh do stop these ridiculous lies. They don't even falsify a
consistent story.

Steinar Bang

unread,
Feb 8, 1999, 3:00:00 AM2/8/99
to
>>>>> Dave Love <d.l...@dl.ac.uk>:

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

SB> I tried it. I was unable to find all the different places this
SB> behaviour was assumed.

> I asked how my old fixes for TM/SEMI (actually only its support
> library?) with unibyte didn't work, but didn't get the info.

Do you have a heavy mail filter or something?

I replied that I never got things working with your filter, so I gave
up the entire 20.2 MBSK and went to XEmacs for mail and newsreading.

I run email expiry on my mail folders so I can't resend it. It
expired almost a year ago.

Steinar Bang

unread,
Feb 8, 1999, 3:00:00 AM2/8/99
to
>>>>> Dave Love <d.l...@dl.ac.uk>:

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

SB> Er... did you miss that part about "heroic effort"...?

> I hope I don't forget Perry and Larsi heroism, but did you miss that
> assertion that it wasn't even possible?

I went back and searched.

I couldn't find the word "possible" in the article I responded to.

Eli Zaretskii

unread,
Feb 8, 1999, 3:00:00 AM2/8/99
to

On 8 Feb 1999, Dave Love wrote:

> Is multibyte more reliable?

I usually run Emacs in multibyte mode, and I never had any significant
problems. Typical usage, except editing program sources, include
reading mail (mostly us-ascii and latin-1 character sets, but
sometimes latin-2 and even some iso-8859-8). I don't use any of the
CJK stuiff, and I don't even have the relevant fonts installed; only
iso-8859-N.

I cannot compare with --unibyte based on my experience, since I only
use that for testing purposes, but I'm actually would like to know why
do you use --unibyte as the main mode of operation. Is it because
initial versions of Emacs 20 were better in this mode, or do you think
it is still true in latest versions (and if so, why)?

Eli Zaretskii

unread,
Feb 8, 1999, 3:00:00 AM2/8/99
to

On 8 Feb 1999, Erik Naggum wrote:

> Emacs 20.3 died after a few days. when I tried out all the pretests on
> my own machine, using it the exact same way it was used in the critical
> production environment, they died after less than a day. with my Emacs
> version, Emacs has been started three times in 70 days.

This may or may not be a proof of reliability.

As you yourself explained elsewhere, your use of Emacs is somewhat
special. I think you said you that you have uncovered bugs which were
dormant for years. This indicates that most users didn't excercise
the buggy code.

What you describe above is a clear evidence that your own version of
Emacs is much more reliable in your typical use. There's no doubt of
that. But it doesn't necessarily tell what reliability would the
average Emacs user see.

For example, I routinely run both Emacs 20.3 and the pretests of 20.4
for weeks without crashing, and all of the crashes are due to my own
stupid bugs when I test changes. I don't see this as a proof of
anything except that it works for me, in my environment, and in my
type of Emacs usage.

Ilya Zakharevich

unread,
Feb 8, 1999, 3:00:00 AM2/8/99
to
[A complimentary Cc of this posting was sent to Dave Love
<d.l...@dl.ac.uk>],
who wrote in article <rzqn22p...@djlvig.dl.ac.uk>:

> >>>>> "Ilya" == Ilya Zakharevich <il...@math.ohio-state.edu> writes:
>
> Ilya> This is a deliberate wrong statement. You have seen my bug report
> Ilya> (about --unibyte being useless in a TTY) only a day or two ago,
>
> This is a deliberate wrong statement. You have seen my posting (and
> subsequent mail) about using it continually in that mode. Theer was a
> bug in an unusual mode of operation (actually nothing to do with
> `load'). Thanks -- that's what we ask people to do. However, I don't
> share the view as I understand it that Latin-N character sets are
> somehow broken and that using them doesn't count.

Oh, I see another peace of lovely logic: any char set which is not
Latin-N does not count. And yes - any font which shows 1/8 of chars
as whitespace is broken.

Ilya

Ilya Zakharevich

unread,
Feb 8, 1999, 3:00:00 AM2/8/99
to
[A complimentary Cc of this posting was sent to Eli Zaretskii
<el...@is.elta.co.il>],

who wrote in article <Pine.SUN.3.91.990208105906.17335P-100000@is>:
>
> On 8 Feb 1999, Erik Naggum wrote:
>
> > Emacs 20.3 died after a few days. when I tried out all the pretests on
> > my own machine, using it the exact same way it was used in the critical
> > production environment, they died after less than a day. with my Emacs
> > version, Emacs has been started three times in 70 days.
>
> This may or may not be a proof of reliability.
>
> As you yourself explained elsewhere, your use of Emacs is somewhat
> special. I think you said you that you have uncovered bugs which were
> dormant for years. This indicates that most users didn't excercise
> the buggy code.

This is a sheer nonsense! All which this indicates is that most user
*tolerate* bugs. Unix lemmings are not a tiny bit better in this
respect than Window lemmings (though initially I would think the opposite).

> For example, I routinely run both Emacs 20.3 and the pretests of 20.4
> for weeks without crashing, and all of the crashes are due to my own
> stupid bugs when I test changes. I don't see this as a proof of
> anything except that it works for me, in my environment, and in my
> type of Emacs usage.

For example, I started Emace 20.3 the first time, and pressed *one
key*. I momentarily got an error message from Emacs (yes, an error on
the first keypress!). The file was open in my own CPerl mode, so I
naturally spent a lot of time debugging my mode. *Obviously* it could
not be an error with Emacs! It was! It would happen in any mode.

And I think it *does* prove something about Emacs testing. (Though my
bug report was not the first one.)

Ilya

Marc Zonzon

unread,
Feb 8, 1999, 3:00:00 AM2/8/99
to
Do you think that this MULE war is very useful?

I'm only a simple emacs user, not so learned and clever than people
who are talking in this group. Nevertheless as it happens that I write elisp
stuff I would like to understand to make them reliable.

I must say that I sadly read these arguings, How can we go ahead with them.

I suppose that the MULE choice has been discussed at length between the emacs
maintainers. But by now it would be very useful that these group of leaders
publish some white-paper explaining it.

What are our goals, and how can we achieve them.

If our goals are truly opposite it's stupid to look for a common product.
But if not we can explain them.

Do we agree that we want emacs to support eastern languages. (By
eastern I mean non western, is Ethiopia eastern?).

If so we must find some mean with or without mule.

Can we drop MULE or are we deemed to improve it?

I suppose that all these question have been discussed over and over, but
what I read here seem to show that it need to be explained again in a clear
frame.

At least if we have to do with mule it is very important to provide
all package writers with a recipe book "how to make your packages mule
compliant".

And please stop to use these hard words, there is only one truth isn't
it, and they add nothing to it. Of course Erik if you fill better with
it you can say I'm stupid, I fear it's not wrong. But please consider
that all these people working on emacs are very generous and are not
working for personal profit, for this reason we can certainly do a
good job.

Emacs is a marvelous product not only because of some genius ( even
if I don't want to minor RMS role) but because so many people have
cooperated to build it. And what destroy this cooperation is more
dangerous for it that all the bugs in a, may be very buggy, component.


Marc.

Erik Naggum

unread,
Feb 8, 1999, 3:00:00 AM2/8/99
to
* Dave Love <d.l...@dl.ac.uk>

| Yes, it allows unibyte mode to be thus established. It also is decently
| reliable in use, certainly compared with MBSK 20.2. Otherwise I'd say so.

now I understand. "reliable" means "behaving so that Dave Love can be
right and not have to face the facts".

look, if Emacs 20.3 had been as reliable as you are campaigning like a
politician on the way down that it is, _I_ would have dumped my own Emacs
and used it. trying to keep up with the changes necessary to maintain a
parallel version of Emacs is a lot of boring work, and if I could have
avoided it, I would have. therefore, your statement is another one of
your self-serving denials, also intended to deny every other person the
right to _experiences_ counter to yours.

my Emacs 19.2003.4002 (built 1999-01-03) is actually used in a production
environment with 100% uptime requirements 24 hours a day, 7 days a week,
controlling an Allegro CL process and talking to two different X servers
so I can work on the system from my home office as well as on site.

and here are the _facts_ denying your religious beliefs in MULE, Dave:


Emacs 20.3 died after a few days. when I tried out all the pretests on
my own machine, using it the exact same way it was used in the critical
production environment, they died after less than a day. with my Emacs

version, Emacs has been started three times in 70 days. once when
booted, once to upgrade to the latest version, and once after a network
outage killed all the X server connections.

hundreds of thousands of dollars every _day_ rest on Emacs and Allegro CL
and my application code in both working flawlessly _all_ the time. if I
hadn't had bothered to excise MULE and fix a bunch of errors that came up
because the incompetent MULE team tried to fix something that never was
broken, I would have had to remain with Emacs 19.34, but there man real
improvements in Emacs 20 that I want, so I don't want to go back.

now, you can lie through your teeth all you want, but the fact that my
Emacs version and Common Lisp application does not have any downtime and
that my client can safely trust the system to work flawlessly speaks for
itself. had I believed your propaganda and not been able to fix what you
lie about, my client would have lost millions of dollars. that's what
"reliable" costs when you believe Dave Love. when you believe my stamp
of approval, it saves you a very considerable risk of losing any money at
all. _that's_ why you can give MULE your stamp of approval, but I can't.

* Erik Naggum
| MULE will never get better. Dave Love will make certain it remains as
| bad as it is today, because improving it might actually prove him wrong:
| that MULE was somehow _not_ perfect when he said it was.

* Dave Love


| Oh do stop these ridiculous lies. They don't even falsify a consistent
| story.

I sometimes wonder what it would actually take to reach the inner
recesses of your sick mind to which you have obviously retreated. I was
_ridiculing_ another one of your mind-boggling rationalizations about how
un-flawed MULE is, you interminable dimwit. I'm trying very hard to show
you that your own views are inconsistent and fraudulent, but you are just
like Teflon Man, aren't you. nothing sticks as long as you can sit back
and think you're morally in the right when you lie, misrepresent, drop
context, etc, etc. again, I'm _really_ happy that MULE has a defender in
such a despicable person as yourself.

| help make 20.4 bug-free -- Erik Naggum, 1998-08-23

yeah, do keep quoting that. it must do you real good, but it shows the
rest of the world that "oh do stop these ridiculous lies" is nothing more
than whining from a pathetic loser who lies when it serves his own goals
and doesn't like it when he's exposed.

#:Erik
--
Y2K conversion simplified: Januark, Februark, March, April, Mak, June,
Julk, August, September, October, November, December.

Eli Zaretskii

unread,
Feb 9, 1999, 3:00:00 AM2/9/99
to

On 8 Feb 1999, Ilya Zakharevich wrote:

> This is a sheer nonsense! All which this indicates is that most user
> *tolerate* bugs.

Obviously, I cannot speak for other users, but *I* don't tolerate
bugs, neither in Emacs nor in any other software I use.

> For example, I started Emace 20.3 the first time, and pressed *one
> key*. I momentarily got an error message from Emacs (yes, an error on
> the first keypress!).

So we now have three data points: Erik's, yours, and mine. This still
isn't much of a statistics, by any measure.

My point was that judging stability of a program based on a single bug
might mislead. To assess whether that bug indeed speaks volumes about
the whole program, the best way is to find out what sitiation triggers
that bug, and then estimate how frequent such a situation occurs in
real-life usage.

But this requires additional information about the bug, such as the
way to reproduce it. Erik didn't produce such information, so such
analysis is impossible for the bug he reported.

An alternative is to gather user reports about crashes, but this
requires a lot of data to draw significant conclusions, and I don't
think it's practical in the case in point.

> And I think it *does* prove something about Emacs testing.

What does it prove, except that no one of the pretesters used CPerl?

Btw, if you tell me how to reproduce the problem with CPerl that you
mentioned, I could see if it still exists in the current pretest of
Emacs 20.4 (unless you already know that).

Eli Zaretskii

unread,
Feb 9, 1999, 3:00:00 AM2/9/99
to

On 8 Feb 1999, Stainless Steel Rat wrote:

> MZ> Do you think that this MULE war is very useful?
>
> That depends... have you learned that there are a number of us who have
> proven that MULE has problems? Have you learned that some of MULE's
> proponents deny the existence of any such problems? If so, then it has
> served at least some useful purpose.

The same ideas and arguments could have been conveyed without any
obnoxious language. Valid arguments don't need such language, they
speak for themselves.

In fact, I submit that the message would be delivered much more
effectively, if it were not for the particular wording we see here.
Some people get actually turned off and turned away by cursing and
flammage.

Erik Naggum

unread,
Feb 9, 1999, 3:00:00 AM2/9/99
to
* Marc Zonzon <Marc....@univ-rennes1.fr>

| Do you think that this MULE war is very useful?

yes. now shut up. thank you.

Erik Naggum

unread,
Feb 9, 1999, 3:00:00 AM2/9/99
to
* el...@is.elta.co.il (Eli Zaretskii)

| The same ideas and arguments could have been conveyed without any
| obnoxious language. Valid arguments don't need such language, they speak
| for themselves.

not to you and Dave Love they don't. people use strong language for a
reason. having to deal with arrogant morons is one such reason.

| In fact, I submit that the message would be delivered much more
| effectively, if it were not for the particular wording we see here. Some
| people get actually turned off and turned away by cursing and flammage.

great! that shows it is possible to make you react to _something_. you
see, all the evidence points to a bunch of losers who don't care about
_anything_ and who willfully forget problems they hear about when it
does't fit their desires, but if you actually care when there's strong
language, maybe, just _maybe_, you will listen when the language is toned
down after we have obtained your attention. it sure didn't help to speak
softly _before_ the strong language. but you didn't notice that, did you?

people who object to strong language and are so incredibly judgmental as
to not even believe it has a cause are generaly hopeless morons, but
sometim