Time to get laughed at....
Shaun Lipscombe
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
| 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
> 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
| 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
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
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
> 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
| 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
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
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
<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
> * 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
> [...] 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
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
| 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
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
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.
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
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
| 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
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
| 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
> [...] 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
> 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
> 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.
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
| 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
| 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
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
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
>* 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
| 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
> [...] 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
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
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
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
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
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
| 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
<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
> 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
> 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
[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
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
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
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
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
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
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
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
>>>>> "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
>>>>> "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
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
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
> >>>>> "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
<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
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
| 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
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
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
| Do you think that this MULE war is very useful?
yes. now shut up. thank you.
Erik Naggum
| 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
sometimes they can be _useful_ morons, if properly retrained to be less
judgmental.
Erik Naggum
| 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.
sufficient severity of consequences completely overshadow any frequency.
| 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.
sigh. _again_, you're disingenious. the reproducible bugs get fixed.
irreproducible bugs that cause a system to misbehave seriously do not get
fixed -- people just go elsewhere. after I had excised MULE, a bunch of
errors that caused serious confusions inside Emacs vanished. stability
was reestablished. it's pretty hard to pin-point what actually got
fixed. demanding such is not only stupid, it is foul play.
| 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).
99% of the work in debugging is making a reproducible test case. of
_course_ you'll be happy to fix something once 99% of the job has been
done. what makes MULE such a pain in the butt is that it does so many
weird things and control over the behavior is so distributed that it is
extremely hard to figure out what _actually_ reproduces a bug. I have
spent more time on wild goose hunts with MULE than I have ever had with
any other program. and this is because it's written by incompetents.
Eli Zaretskii
On 9 Feb 1999, Erik Naggum wrote:
> it sure didn't help to speak softly _before_ the strong language.
If you had tried that, you you would have discovered that it actually
works, not only with me, but with everybody else. But you have never
tried, so you wouldn't know.
Erik Naggum
| If you had tried that, you you would have discovered that it actually
| works, not only with me, but with everybody else. But you have never
| tried, so you wouldn't know.
how would you have known? you never notice anything anybody tells you
unless you already agree with them or they offend you. telling you
something you don't agree with is like talking to a deaf dog: it will
bark back only when it's scared.
you're such a dimwit, Eli. "you have never tried", you say, completely
devoid of knowledge of what you speak, and proving my accusation against
you so forcefully I can only applaud: you're a prejudiced fool, with so
strong prejudices that you see cannot even _see_ what you don't want, and
then deny you the existence of evidence counter to them. not only does
this apply to MULE, it applies to people, too. no wonder you're happy
with MULE. most of the idiots who don't see problems with MULE don't see
them because they don't want them to be there.
Eli Zaretskii
On 9 Feb 1999, Erik Naggum wrote:
> * el...@is.elta.co.il (Eli Zaretskii)
> | If you had tried that, you you would have discovered that it actually
> | works, not only with me, but with everybody else. But you have never
> | tried, so you wouldn't know.
>
> how would you have known?
Try reading comp.os.msdos.djgpp, and you will see.
Erik Naggum
you're being disingenious again and reply to something I didn't say. if
you wonder why you annoy me so much, there it is. let's try again:
how would you, Eli Zaretskii, have known if I had tried what you suggest
would have worked but you claim I have never tried? you don't see what
you don't believe in already, like a true religious fundamentalist, and
deny the existence of counter-evidence.
I think you, Eli Zaretskii, are the most dishonest man alive. the sad
part is that it must have worked very well for you, and honesty probably
nearly killed you once, the way you continue to be scared shitless of it.
Eli Zaretskii
On 9 Feb 1999, Erik Naggum wrote:
> how would you, Eli Zaretskii, have known if I had tried what you suggest
> would have worked but you claim I have never tried?
Because I have never seen any message of yours without offending
language. When I see one, I could say that you tried.
Excerpts just from this message:
[I am a] true religious fundamentalist
[I am] the most dishonest man alive
[I am] scared shitless
Torsten Grust
| [...]
| you're being disingenious again and reply to something I didn't say. if
|
| how would you, Eli Zaretskii, [...]
|
| I think you, Eli Zaretskii, [...]
I don't know how people feel about this thread, but to me all of this
looks like Eli, Dave, and Erik will be better off to continue the
rambling by private e-mail. A discussion of technical issues has
turned into a debate on a purely personal level.
No, I don't use kill files as these three folks normally are
remarkably helpful when it comes to Emacs.
Cheers,
--Teggy
--
| Torsten Grust Torste...@uni-konstanz.de |
| http://www.fmi.uni-konstanz.de/~grust/ |
| Database Research Group, University of Konstanz (Lake Constance/Germany) |
Ilya Zakharevich
> > And I think it *does* prove something about Emacs testing.
>
> What does it prove, except that no one of the pretesters used CPerl?
As I explained, the bug had nothing to do with CPerl. It just so
happened that the first file I opened in Emacs was a Perl file.
> 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).
*As I explained*, the bug report is already submitted, and it is
claimed that the bug is already fixed. But 20.3 remains the same.
Ilya
Eli Zaretskii
On 9 Feb 1999, Torsten Grust wrote:
> Erik Naggum <er...@naggum.no> writes:
> | [...]
> | you're being disingenious again and reply to something I didn't say. if
> | you wonder why you annoy me so much, there it is. let's try again: [...]
> |
> | how would you, Eli Zaretskii, [...]
> |
> | I think you, Eli Zaretskii, [...]
>
> I don't know how people feel about this thread, but to me all of this
> looks like Eli, Dave, and Erik will be better off to continue the
> rambling by private e-mail.
On my part, I will readily and gladly discontinue this disgrace, as
soon as offending language and profanities will not be posted here. I
even tried to do that unilaterally a couple of weeks ago, when Kai asked
for it, but the result was that the profanities and flammage went on
and on, unchecked. As much as I feel sick being dragged into this
rambling, I refuse to let discussions on this fine forum be shut down
by personal attacks on those who dissent.
> A discussion of technical issues has turned into a debate on a
> purely personal level.
Not all of it, just those articles posted by Erik, and the rebuttals
they invite.
I hope that it's no incident the quotations above are only from Erik's
articles. That's what caused this thread (and others) go up in flames
in the first place. But if somebody spots something inappropriate in
my messages, please tell me about that ASAP, and I promise to refrain
from such language in the future.
Eli Zaretskii
On 9 Feb 1999, Stainless Steel Rat wrote:
> Two years ago Erik was quite civil.
Yes, he was. I wonder why we can't go back to those days. IMHO,
civilized language is imperative on public forums that discuss
technical issues in order to help users.
> On the rare occasions you were not
> ignoring him you were either twisting what he said out of context, or more
> commonly denying and decrying his claims of flaws in MULE.
I'm entitled to my opinions, as much as Erik and everybody else is
entitled to theirs. I'm entitled to post articles with my opinions,
as long as they are on-topic and use civilized language. Those who
think my opinions are incorrect, can (and should) make their arguments
known, and let people judge who is right. These are all legitimate
parts of discussions in public forums. Personal offense and
profanities are _not_.
And btw, I never denied or decried Erik's claims about MULE (unless
you think that attacks on me personally are part of claims about MULE
flaws). I mostly asked him questions to better understand what is he
saying, and tried to put his claims in a proper perspective. Somehow
this was perceived as a reason for a personal war.
> Is it any wonder the lot of us are sick of you, and now David?
If people are sick of me, they can stop reading my messages, or ignore
their contents. If they *do* want to reply to them, I respectfully
request that they do so in a civilized and polite manner, and refrain
from personal attacks and profanities. As far as I could see, only
Erik does those improper things, the rest of those who are sick of me
do not.
Erik Naggum
| Yes, he was. I wonder why we can't go back to those days.
I'll explain it again: because you keep lying, misrepresenting, and
twisting everything I say out of shape.
| IMHO, civilized language is imperative on public forums that discuss
| technical issues in order to help users.
"civilized" excludes your behavior in my book.
| I'm entitled to my opinions, as much as Erik and everybody else is
| entitled to theirs.
why then do you have to misrepresent them? why then do you pretend that
people have said something they haven't, which requires them to clear up
any confusion _you_ have created? when then do you have imply that
people have said something they haven't? why do you pretend that you
want to understand when there is no evidence that you never do?
| I'm entitled to post articles with my opinions, as long as they are
| on-topic and use civilized language.
I notice that lies, mispresentations, and other kinds of dishonesty and
fraudulent behavior is not excluded.
| These are all legitimate parts of discussions in public forums. Personal
| offense and profanities are _not_.
neither are lies and distortions of other people's point of view.
| Somehow this was perceived as a reason for a personal war.
grow up, Eli Zaretskii. your incredibly disgusting holier-than-thou
attitude is a cause for war all in itself.
| As far as I could see, only Erik does those improper things, the rest of
| those who are sick of me do not.
and still they are sick of _you_. you really don't understand why you
aren't allowed to be a manipulative liar, do you?
the improper things _you_ do cause the hostility, Eli. that you are so
stupid as not to understand that people don't get sick of you without
reason is really nobody's problem but your own, but now that you have
stretched your holier-than-thou attitude so far it reeks of hypocrisy,
perhaps it really is time to put in an automatic answering service to
your messages: "clean up your own act. don't distort and misrepresent
others."
Erik Naggum
| As much as I feel sick being dragged into this rambling, I refuse to let
| discussions on this fine forum be shut down by personal attacks on those
| who dissent.
the problem is that whenever you reply, it contains the most dishonest
crap I have seen in years. if you could only stop lying, could listen,
and not twist people's words, much less heated debate would ensue,
possibly nothing. your lies and implicit personal attacks annoy me. if
you really don't like them, just stop your own. you are the only person
whose behavior you can change. just do it.
| But if somebody spots something inappropriate in my messages, please tell
| me about that ASAP, and I promise to refrain from such language in the
| future.
you have been asked to stop twisting people's words multiple times. it
has had no effect on you whatsoever. let's see if you can actually
change that part of your personality. I doubt it, but if you really want
to help make these discussions technical, you have a responsibility in
not forcing people to respond because you accuse them of all kinds of
shit, albeit in what you think is "nice language". do you understand
this simple condition, Eli Zaretskii? you don't have to answer, just
stop doing it.
Eli Zaretskii
On 11 Feb 1999, Erik Naggum wrote:
> the problem is that whenever you reply, it contains the most dishonest
> crap I have seen in years.
You will have to learn to live with that. You are entitled to think
whatever you want about the ``crap'' I'm posting, as long as you keep
those thoughts to yourself, or at least keep them out of this public
forum. You are invited to reply to my ``crap'' as well, but please do
so without attacking me or others personally, and without using profane
language. If you do want to continue the same conduct I've seen here
lately, expect to see my replies to that as well. I believe such conduct
should not be tolerated here, and I'm going to live up to this belief.
> if you could only stop lying, could listen,
> and not twist people's words, much less heated debate would ensue,
> possibly nothing.
It is not your prerogative to educate me. It's too late for that,
anyway, so you might as well stop trying. As long as I stay withing
the boundaries of the net etiquette and the charter of this group,
I am entitled to post my views and to try to convince people they are
correct.
> your lies and implicit personal attacks annoy me. if
> you really don't like them, just stop your own. you are the only person
> whose behavior you can change. just do it.
I don't intend to tolerate conduct such as yours, because I think it
will destroy this forum. The record shows that for each thread which
went up in flames, those flames were started by your message, sometimes
several messages, where you attacked your opponents instead of arguing
with their veiws. The record shows that you are the only one who
consistently uses profanities to make your points. Stop doing this, and
we will not need to have another argument like this, ever.
> you don't have to answer, just stop doing it.
It goes both ways. But since you are always starting the flames, you are
the one who should stop. The last round of this senseless war (see the
directory separator thread) started when I asked a question that neither
twisted nobody's words nor was related to anything you said. I was
attacked nevertheless. Seems like I can't post anything anymore without
risking such attacks. Don't expect me to yield to this.
Eli Zaretskii
On 11 Feb 1999, Erik Naggum wrote:
> | I'm entitled to post articles with my opinions, as long as they are
> | on-topic and use civilized language.
>
> I notice that lies, mispresentations, and other kinds of dishonesty and
> fraudulent behavior is not excluded.
You are _not_ entitled to pass such judgement publicly here. You will
have to learn to live with what you think are ``lies, mispresentations,
and other kinds of dishonesty'' without calling them such in a public
forum. If you don't, you *will* get replied as appropriate.
You think I'm a liar and a fraud, you post a message that makes those
lies and fraud clear to all. Just don't call them lies, dishonesty,
fraudulent behavior etc., and we'll do just fine. It's that simple.
Preben Randhol
Hi I just wondered if the personal attacks could stop now? At least on
this list. Take it outside as one might say? Please?
--
Preben Randhol | I'm alive, she cried, but I
Phone: +47 73594091 / +47 95797315 | don't know what it means.
Info: http://www.pvv.org/~randhol | - Mercury Rev
Erik Naggum
| the problem is that whenever you reply, it contains the most dishonest
| crap I have seen in years.
* el...@is.elta.co.il (Eli Zaretskii)
| You will have to learn to live with that.
so you admit to being a liar. that's progress, of sorts.
| If you do want to continue the same conduct I've seen here lately,
| expect to see my replies to that as well.
"you will have to learn to live with it, Eli." I'm _amazed_ that you
don't even understand that you are the inverse position for what you do.
| It is not your prerogative to educate me.
I have been trying to show you that your dishonesty is the cause of my
and several other people's anger towards you. this is not "education".
| As long as I stay withing the boundaries of the net etiquette and the
| charter of this group, I am entitled to post my views and to try to
| convince people they are correct.
your views stop where my views begin. you have no right to misrepresent
others, no matter what kind of language you use. when you lie about what
others have said, that is no longer "your views".
| I don't intend to tolerate conduct such as yours, because I think it
| will destroy this forum.
I don't intend to tolerate or condone your continued lies, because I
think unchecked dishonesty has already destroyed the forum.
| The record shows that for each thread which went up in flames, those
| flames were started by your message, sometimes several messages, where
| you attacked your opponents instead of arguing with their veiws.
your ability to keep records straight has been proven to be colored by
what you already believe and you deny the existence of counter-evidence
and lie through your teeth in order to destroy other people, all the
while pretending to be holier than the rest, which certainly aren't.
| Stop doing this, and we will not need to have another argument like this,
| ever.
that's good, but when will you stop lying, Eli? that's what matters to
me and to several other people here.
| It goes both ways. But since you are always starting the flames, you are
| the one who should stop.
you are the one who always start misrepresenting others, which is the
cause of their anger, so if you really want peace, just stop lying. you
could for instance stop making such incredibly stupid lies as "always"
just to make your overstated point.
| Seems like I can't post anything anymore without risking such attacks.
| Don't expect me to yield to this.
as long as you continue to be a liar, you will have to learn to live with
the necessity of exposing it. if you adamantly refuse to be honest, such
as because you feel like I have educated you if you do and would yield to
my requirements, that's nobody's loss but yours, but you won't get away
with it, no matter how hard you have to lie in order not to "yield" to a
simple requirement that you be honest and not misrepresent others.
Erik Naggum
| You will have to learn to live with what you think are ``lies,
| mispresentations, and other kinds of dishonesty'' without calling them
| such in a public forum.
in other words, you will continue to lie, mispresent and be dishonest.
| You think I'm a liar and a fraud, you post a message that makes those
| lies and fraud clear to all. Just don't call them lies, dishonesty,
| fraudulent behavior etc., and we'll do just fine. It's that simple.
so you think it _helps_ to prove that you're a liar by posting the text
you have quoted part of and answered in your typically dishonest way, and
demonstrating that your response is dishonest and fraudulent? since you
will never ever stop lying, according to what you say now, this will mean
that every response from you needs to be followed up by contrasting what
you quote and answer with what people have actually said. if this
doesn't destroy a forum faster than profanity, it'd be a miracle.
the problem, Eli, is that you hope to get away with lying because people
will tire of pointing it out. you will _not_ get away with lying, Eli.
stop wasting everybody's time, and start being honest. it's that simple.
Eli Zaretskii
On 11 Feb 1999, Erik Naggum wrote:
> | If you do want to continue the same conduct I've seen here lately,
> | expect to see my replies to that as well.
>
> "you will have to learn to live with it, Eli." I'm _amazed_ that you
> don't even understand that you are the inverse position for what you do.
Actually, I think I do understand. And I have learnt to live with that a
long time ago.
> | Stop doing this, and we will not need to have another argument like this,
> | ever.
>
> that's good, but when will you stop lying, Eli?
Your definition of lie seems to include everything I say. So the answer
to this is "probably, never".
> | It goes both ways. But since you are always starting the flames, you are
> | the one who should stop.
>
> you are the one who always start misrepresenting others, which is the
> cause of their anger, so if you really want peace, just stop lying.
Misrepresentation should not spark flammage, personal attacks and
profanity. Explain why the issue is misrepresented, and if you do it
like everybody else does, there will be no flammage in response.
> | Seems like I can't post anything anymore without risking such attacks.
> | Don't expect me to yield to this.
>
> as long as you continue to be a liar, you will have to learn to live with
> the necessity of exposing it.
I think I'm doing fine already, no thanks to you.
Eli Zaretskii
On 11 Feb 1999, Erik Naggum wrote:
> * el...@is.elta.co.il (Eli Zaretskii)
> | You will have to learn to live with what you think are ``lies,
> | mispresentations, and other kinds of dishonesty'' without calling them
> | such in a public forum.
>
> in other words, you will continue to lie, mispresent and be dishonest.
By your definition, probably yes. By the definition of others, I'm not
necessarily lying as I am. Your definition seems to include everything I
say.
You are entitled to that definition, but you are _not_ entitled to impose
it on others. The easiest way not to do that is to avoid the word itself.
> | You think I'm a liar and a fraud, you post a message that makes those
> | lies and fraud clear to all. Just don't call them lies, dishonesty,
> | fraudulent behavior etc., and we'll do just fine. It's that simple.
>
> so you think it _helps_ to prove that you're a liar by posting the text
> you have quoted part of and answered in your typically dishonest way, and
> demonstrating that your response is dishonest and fraudulent?
I don't know if it helps or not. But if you think you must do it, be my
guest and do it, and let the others judge. As long as you avoid
attacking me (and others) personally and as long as you avoid
profanities, I don't mind; I even think that it might be useful.
Erik Naggum
| Your definition of lie seems to include everything I say. So the answer
| to this is "probably, never".
this is just what I have come to expect from you. sigh. if there is a
way to answer with a useless, non-committal, non-answer, you'll find it.
you really are _slick_, Eli.
| Misrepresentation should not spark flammage, personal attacks and
| profanity. Explain why the issue is misrepresented, and if you do it
| like everybody else does, there will be no flammage in response.
the record shows that trying to explain things to you simply fails. you
filter things through a number of weird filters before you listen, one of
which is that you have to agree with the _form_ of the statement before
you can at all read it, and not just profanity which you have _finally_
managed to be explicit about. others here have tried to explain things
to you and have simply failed. you just _don't_ get it. that's why
people get upset with you. when reasonable explanations are filtered out
and ignored, and you deny that people have ever tried to communicate with
you, like you have done here several times, what you witness is sheer
exhaustion with having to deal with someone who is as slick as you are
and so utterly unable to _listen_. it works very well to _say_ "explain
why the issue is misrepresented", but it doesn't work in practice, since
you never _actually_ listen to any such explanations.
Bill Richter
I find this discussion really amusing, but can you remind me what
Emacs issue you're arguing about?
And can it be something more specific than "Has Emacs turned into
shit"? Sorry, I shoulda said ``crap'', I don't wanna be profane :)
Anthony Tsakiris
> Do you think that this MULE war is very useful?
>
[snip]
Me too. This thread has been the best motivation yet to
figure out how article scoring works though. :)
--
Anthony Tsakiris
Steinar Bang
> Me too. This thread has been the best motivation yet to figure out
> how article scoring works though. :)
The simplest way to sink this thread, is to find the head of the
thread by doing "^" repeatedly in the summary buffer. Then do
L t s t RET
That should do it.
Erik Naggum
| intelligent support for larger character sets wouldn't need all packages
| everywhere to be written to support it, particularly not with "heroic
| effort".
* Andrew Innes <and...@harlequin.co.uk>
| 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.
true. the coding system stuff is controlled by global variables that
need to be bound around all file system or network I/O operations. a
number of variables exist to specify default values for the controlling
variables in certain common situations.
| 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.
true.
| 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.)
the core problem is that C, upon which Emacs Lisp is based in many more
ways than I like, has no concept of a character vs a byte stream. the
file system lacks type information available for its files, as well. the
result of this is that crucial information is lost as soon as the file or
stream is closed, and has to be provided anew when it is opened the next
time. this is clearly quite amazingly braindamaged, but the idea to let
files be readable as a byte stream regardless of actual structure is a
good one. what is missing is the ability to store meta-information, too.
Emacs attempts to reintroduce the meta-information with a bunch of useful
associations that look at the file name, the first line of the file, file
local variables, etc. (the latter two are actually approaches to the
right solution, but they are unsupported elsewhere, and thus need special
conventions to "hide" the meta-information, such as in comments or string
literals.) these mechanisms were fairly predictable and standardized.
enter MULE. instead of relying on well-tested meta-information encoding,
it yielded to oen of the curses of backward compatibility: it attempts to
intuit information that isn't there, anymore. instead of encoding this
stuff in the file name (we're mostly talking about text files, anyway),
in some form of markup, in innocuous file local variables, in mode lines,
or in directory-based defaults or whatever that would actually _work_,
MULE is fundamentally subservient and accepts that it should not force
anything on anyone. (yes, you read that right, but bear with me.) the
heuristics it then employs is a regexp-based search through the text for
various means of switching encodings and character sets that are in use
in some areas of the world. if you already have a Japanese text, the
chances are pretty good you will have some easily identifiable encoding
scheme inside the file because the Japanese are about 20 years after the
West when it comes to standardizing on their own character representation
-- 20 years ago, Europe was also all 7-bit and had a lot of stupid cruft
in files and hardware and programs to use nationalistic 7-bit character
sets. that vanished with the 8-bit character set families, which were
sufficiently better that we now have only 11 of them to cover ~2 billion
people, instead of the previous 1100 different sets. well, it might
actually have been only 900, but the poit is that two orders of magnitude
reduction in complexity followed from doubling the size of the basic unit
needed to store a character. that's pretty good. it also indicates that
the East Asians will face a similar reduction in complexity with their
own 30+ different ways to encode the big character sets the use. but I
digress.
_given_ that there is a royal mess in Japan and they have been very good
at catering to it (just like IBM was very good at responding to every
customer request with a new code page, display PROM for their terminals
and a custom-made printer chain until a brilliant team in Canada set out
to clean up their horrible mess), and given that the coding systems are
fairly self-identifying (because they use only selected fragments of the
complete code space), the messy thinking of the Japanese culture rules
MULE, almost as if Europeans were to sit down 20 years ago and create
tools to deal with both French and Norwegian using only 7-bit character
sets. (yes, these things were done, and they are almost as stupidly
designed as MULE -- I helped create a 9-bit internal character set in
1981 that could hold all the characters needed by bibliographers and
which would print nicely on all kinds of printers. this was in the
36-bit days.)
now, there's another stupidity in the Japanese culture and tradition that
impacts MULE very hard, indeed. their characters actually mean something
all by themselves and are put together in very different ways than we do
with alphabets, but so far it's brilliant. I wish we could represent
text as efficiently in Europe, too, as that would hopefully mean only one
_written_ language for all of the European Union, but I digress. the
problem occurs when you need to _order_ these symbols. OK, so we number
the radicals ("roots" of the character) and strokes and such and people
can make pretty good dictionaries and all that good stuff. but this is
all so _pre-computer_, and if you don't grow a clue pretty damn quickly
when you want to stuff your text into a computer, you lose big time, and
that's what the Japanese did: they created huge character sets that they
can barely translate between. this means that to a Japanese, the set a
character belongs to is part of its identity. this is manifestly not so
in alphabetic scripts.
the solution, as always when dealing with cultural heritage, is to ignore
the stupid ways and create something that is truly smart. Unicode was
the first such truly smart thing to enter the character set scene in a
lot of years, and it followed the success of the eight-bit character
sets. had it succeeded, and it won't, we would have world peace by now.
briefly put, a character is not a code in a set, it's a concept. it has
a name. which character set it belongs to is a property of the _set_,
not the other way around. if you can describe character sets in terms of
the names of the characters it contains, you have instant gratification
when creating mapping tables or representing things internally. you
don't even need a fixed internal coding, although for efficiency, it's a
really good idea to have that. Unicode unified the many character sets
in use in East Asia, and provided us with a name space. (lots of stupid
Asians have objected to this on bogus grounds, always missing the point,
but the smart people are winning.)
now, what would be needed to make such continuous mapping back and forth
between internal and external coding is a means of knowing what the
source or destination wants. that is, the coding system is not a
property of the writer or reader, but of the source or destination. this
doesn't seem terribly controversial in this object-oriented day and age,
but it actually is, partly because stupid people object to seeing stuff
in their files that they think is unnecessary because they could live
without it when they didn't talk to people who used other character sets,
and they don't grasp that _how_ you represent this meta-information is
much less important than _that_you_do_it_.
| So, could you please describe, if only briefly, how you would approach
| this issue if you were designing an internationalized Emacs?
very simply: a user needs to have available a character set description
(which the OS provider would typically provide) and himself provide a
mapping from file to character set via some form of meta-information. it
could be set visibly in the file itself, but my choice is directory-based
defaults, as people tend to stick similar files together in directories,
already, above and beyond file extensions. instead of just one .emacs,
have one in each directory, and read it to learn what you should assume
about files in that directory. the characters in files would then be
mapped into an internal code in Emacs, such as Unicode, but the file or
directory (_not_ the buffer) will control the behavior of the system when
writing text out. lacking any coding system information, use the
internal coding. if possible, one would use a 16-bit code internally,
but if not forseeably sufficient, 8, 16, or 24 bits might be chosen on
demand in buffers and strings, which would expand on impact with a wider
character. (this is no worse that moving the gap or whole buffers upon
garbage collection. relax.)
key concepts: characters form a universe, with character sets being
selections from the available characters. characters have names that
stick to them wherever they are. coding systems are merely means of
assigning numbers to characters and linearizing codes in a byte stream,
but this is a property of the stream, not of the characters or of the
writer or reader.
why is this not implemented? well, I have implemented it for my own
needs and a client of mine has benefited from the ability to cater to
their customer's needs by doing all the necessary translations on my end
(which means I can change the internal representation if I so desire, and
that's a serious bonus). why is it not implemented in Emacs? because it
would be about 1/5 of the work required to stuff MULE into Emacs, and
MULE took almost a decade to make work reasonably well, and I don't want
to know many people were involved during those years.
there would be a need to override the stream's choice of encoding,
though. that we have gotten away with reading any old file as bytes or
characters without saying what we were doing was a mistake of the past,
and we seriously need to inform the system that want to read bytes.
however, files ending in .gz are never read as characters, anyway, and
neither are .tar files. that _should_ have been sufficient in MULE, but
it wasn't. go figure.
| 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.)
the advantage is that you know whether you look at a byte or a character.
it has the same advantages over machine language where you don't know
what's in a register is an integer or a memory address (i.e., a pointer).
it would help if you knew in a lot of cases. e.g., you can't add two
pointers and adding two characters together doesn't make sense, either.
also, a character type would mean that the character could have a name, a
code in any character set, various properties now represented in tables
all over the place, etc, etc. if you had a 16-bit internal code, you
would typically provide a table of 65,536 structures and bit fields and
what-not to learn about these things. all in all, all of Unicode needs
about 200K of memory to be represented intelligently. MULE takes about
700K, and doesn't do what an intelligent representation of Unicode does.
| 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.
I have always seen Emacs enhance its environment in constructive and
non-intrusive ways. MULE is exceptionally instrusive, immature, and
stupidly designed because it maintains a model that only applies in Japan
to the entire world. even in Japan, the model is as stupid as the 7-bit
model was in Europe, but they're too good at making their stupid cultural
heritage work, so they aren't likely to discover the need to improve.
(Europeans can't even make their stupid cultural heritage work, but at
least this means we don't have as much legacy cruft to fight. :)
now, the reason MULE is so intrusive is that when some things you try to
adapt to are inherently flawed, like the Japanese (and early European)
character set model, it just doesn't work to improve on them piecemeal:
everything only gets _worse_ the better you get at adapting to them. if
people want crufty old coding system based on a single character set,
let's give it to them, but let's do it in their _files_, not in memory,
where we are free to do whatever smart things we want. because MULE is
really stupidly designed to accomodate an _external_ model through much
misplaced subservience, it it _never_ gets out of the quagmire, but digs
itself in more and more every time it wiggles to adopt to people's bogus
requests, just like IBM's national code page nightmare.
the bad thing with MULE is that it maintains a way of thinking that makes
it virtually impossible to reach the optimal solution. "you can't get
there from here" sometimes applies to the path from bad to good design,
and reasonable people who have a _solution_ as their goal, just don't
hang on to the past, they scrap it. "back to the drawing board" is the
old engineer's phrase when something failed the test of application in
real world. but MULE just won't be scrapped. we're stuck with this
mind-bogglingly stupid solution that will become asymptotically worse as
we approach a working internationalized Emacs. how do I know? well, in
the early eighties, I helped solve people's problems with weird codings
and multiple character sets, and was quite happy to see Digital Equipment
Corporation adopt an 8-bit code for their terminals a few years later,
and that became an ECMA standard a few years later, and in 1987 this work
became ISO 8859-1 through -4, with Greek, Hebrew, Katakana, Cyrillic,
Arabic, Devanagari, etc, following suit. I have seen how hard solutions
that _don't_ go for a simpler encoding and the abstraction of characters
into individually named object inevitably get. and they only get worse
and worse, because people's needs are fundamentally incompatible with the
core idea of a character set as the fundamental property it has become in
the Japanese culture because of their past mistakes.
but the _really_ bad thing with MULE is that it sets internationalization
back about 20 years, i.e., to where Japan is. all the hopes of unified
character sets, of explicit meta-information inside and outside of files,
of typed streams and protocols for interchange of culturally sensitive
material all go up in smoke because MULE is a piece of shit that could
_never_ have been developed in a culture that had seen the solution to
the 7-bit character set mess in Europe in the early 80's and which _knew_
how completely bogus a design based on character sets as the fundamental
concept would be. even the sadly dysfunctional "locale" stuff in POSIX
is better than MULE.
| Thanks for any enlightenment you can offer.
sure. I hope this helps, and that the delay in responding has made it
possible to read what I'm writing without the prejudicial hostilities
some people see whatever I write. and those who want to rise to the
defense of stupid cultura heritages, don't. if you have to associate
your culture with its stupid elements, that's your problem. I want to
keep the smart stuff undiluted by the stupidity that makes nostalgia
look like a waste of time. "let's improve" _means_ "let's ignore the
mistakes". MULE is a dead end. adopting it may well be Emacs's bane,
and the worse its downfall will be the harder it tries to make it work,
just like insecure people who desperately want to be loved and only
succeed in becoming miserable pests that everybody hate.
#:Erik
Dave Love
HK> really is four characters and thus this would seem to be
HK> intentional. Why -- I don't know. Perhaps someone more familiar
HK> with Emacs internals can explain this behaviour?
Trace `single-key-description' to where it bottoms out to see what's
going on.
The C-x 8 bindings are actually autoloaded. Don't explicitly require
iso-transl and you should see bindings as obvious function names.
This is helpful if you want to search for a binding you've forgotten,
though one or two (for a-ring, perhaps?) are misleading in 20.3 AFAIR.
Dave Love
Rat> If --unibyte worked as advertised there would be no way for the
Rat> \201 errors to occour, because it would be impossible for
Rat> anything to generate multi-byte characters anywhere under any
Rat> conditions.
That's not how it's advertised anywhere I know (the manual and NEWS).
If it is so advertised, it's clearly a documentation bug -- where?
Rat> Three months ago I told you that --unibyte failed in exactly
Rat> this fashion.
This doesn't seem to have occurred as stated, but anyhow such proof by
assertion isn't useful.
Rat> I told you that an Emacs-Lisp program could trivially and
Rat> automatically override --unibyte, forcing FSF Emacs 20 into
Rat> multi-byte mode.
Any package that sets `default-enable-multibyte-characters' is quite
broken, as if it stomped on similar customizations.
Rat> I told you that once that happens it is impossible to force FSF
Rat> Emacs 20 back into single-byte mode.
Obviously you can reset it, but that's something that should really
only be happening in customizations/startup code.
In case this is about the wrong-headed <x7r9ttk...@peorth.gweep.net>
(reply in <rzq3e68...@djlvig.dl.ac.uk>) the relevant new NEWS
entry, following some tidying of the startup code post-20.3, is:
** Setting the default value of enable-multibyte-characters to nil in
.emacs explicitly or via Custom is basically equivalent to using
--unibyte. (All buffers created during startup will be made unibyte.)
Erik Naggum
| ** Setting the default value of enable-multibyte-characters to nil in
| .emacs explicitly or via Custom is basically equivalent to using
| --unibyte. (All buffers created during startup will be made unibyte.)
another useful NEWS entry is this one:
*** The variable enable-multibyte-characters is now read-only;
any attempt to set it directly signals an error. The only way
to change this value in an existing buffer is with set-buffer-multibyte.
this is even in the manual, it says.
is that wrong, now?
#:Erik
Eli Zaretskii
On 18 Feb 1999, Erik Naggum wrote:
> *** The variable enable-multibyte-characters is now read-only;
> any attempt to set it directly signals an error. The only way
> to change this value in an existing buffer is with set-buffer-multibyte.
>
> this is even in the manual, it says.
>
> is that wrong, now?
As far as I could see, at least in the latest pretest of Emacs 20.4,
the above NEWS entry is correct (I didn't check the manual). I typed
`M-: (setq enable-multibyte-characters t) RET' and got a bell and a
message saying it was a read-only variable.
Bill Richter
correct: that MULE is 20 years behind; that MULE gets us into the
7-bit character set mess that Europe suffered through in the early
80's; that we need your
unified character sets, of explicit meta-information inside and
outside of files, of typed streams and protocols for interchange of
culturally sensitive material
It's still not clear to me what the solution is. Here's a few
questions:
At the time when MULE was merged into Emacs, was it technically
possible to have a solution along your lines? Is it technically
possible now?
Even if a nice clean solution is technically possible, would it be
rejected in Japan, for cultural reason maybe?
Let's say that (a few years from now maybe) Japan is willing to go the
nice clean solution. Will it be much trouble to take the MULE code
out and swap in the clean code?
RMS never shirks big projects. But will the MULE -> clean solution
transformation of Emacs be it be doable? Or will we be in a "worse is
better" game where we can't escape from the bad MULE code? How did
Europe get through the 7-bit character set mess? Must have been a
lotta bad code that had to be surmounted.
Johan Kullstam
> Erik, thanks for the well-reasoned post. Let's assume that you're
> correct: that MULE is 20 years behind; that MULE gets us into the
> 7-bit character set mess that Europe suffered through in the early
> 80's; that we need your
>
> unified character sets, of explicit meta-information inside and
> outside of files, of typed streams and protocols for interchange of
> culturally sensitive material
>
> It's still not clear to me what the solution is. Here's a few
> questions:
one solution is clear. unfortunately, it is beyond the scope of
emacs, but would require changing the operating system and its filesystem.
put meta data onto a file. if a file could point to 1) the file
itself and 2) a 2nd file of metadata you could record the
character-set of the file itself. i have an image of a file-name
being a lisp symbol with the file itself being the symbol-value and a
plist for the metadata.
you could load the metadata with all sorts of useful things. e.g., a
documentation string. file-type (binary vs text at a first level). a
binary file could have settings for a record description, endianness
or cpu-type as applicable. for text, the charset encoding.
end-of-line marker, default-editor, run-time wrapper (replace that
#!/... with something more general since not all languages use # as a
comment marker), emacs-modes, number of backups to keep, a list of
related files &c. the list goes on.
> At the time when MULE was merged into Emacs, was it technically
> possible to have a solution along your lines? Is it technically
> possible now?
>
> Even if a nice clean solution is technically possible, would it be
> rejected in Japan, for cultural reason maybe?
>
> Let's say that (a few years from now maybe) Japan is willing to go the
> nice clean solution. Will it be much trouble to take the MULE code
> out and swap in the clean code?
if i understand the arguments correctly, no. mule will require a lot
of accomodation to get it to work. it will be hard to back out of it
again.
> RMS never shirks big projects. But will the MULE -> clean solution
> transformation of Emacs be it be doable? Or will we be in a "worse is
> better" game where we can't escape from the bad MULE code? How did
> Europe get through the 7-bit character set mess? Must have been a
> lotta bad code that had to be surmounted.
sometimes you really do need to bite the bullet, break old scripts and
move on to a radically better way of doing business.
--
johan kullstam
Bruce Stephens
> Bill Richter <ric...@borel.math.nwu.edu> writes:
> > Let's say that (a few years from now maybe) Japan is willing to go the
> > nice clean solution. Will it be much trouble to take the MULE code
> > out and swap in the clean code?
>
> if i understand the arguments correctly, no. mule will require a
> lot of accomodation to get it to work. it will be hard to back out
> of it again.
I'm not so sure. (I agree that Erik's article was very good. I think
I understand his objections better.)
I think there are two separate issues. One is how you decide what
encoding some external source (file, process, etc.) is using, and how
to convert between that and whatever scheme Emacs uses.
As far as I can tell, MULE is pretty much irrelevant to that---it may
do it badly, but if a better solution can be found it would surely be
not much harder to fix MULE to use it than it would to change some
other system.
The other is the scheme that Emacs uses internally. The documentation
(in Lispref which came with XEmacs-20.4) doesn't seem to describe it,
but the clues suggest that it's not as most people would now do it.
For example:
- Function: char-charset CH
This function returns the character set of char CH.
That just looks wrong, from a Unicode perspective. It makes me
question what's going on inside Emacs (what happens when I cut and
paste between buffers which came from differently-encoded files? Do
characters within strings come from particular character sets?).
The whole notion of dealing with character sets (except in how they
relate to the outside-Emacs world, and except for octet-streams) is
alien. But maybe it's not in Japan?
The reason I suggest that it might not be that hard to fix is that I
suspect that the packages (like Gnus) which needed to be modified to
work with MULE probably don't call things like char-charset. OK, I'm
wrong, but Gnus only calls it a few times.
I suspect the bulk of the changes are saying "this file isn't encoded,
stupid, leave it alone" (if Emacs used UTF-8 internally, most such
files could be stored and read as UTF-8 too, but there's still need to
deal with genuine byte-streams, of course). And that's something that
needs to be handled regardless.
Lars Magne Ingebrigtsen
> I suspect the bulk of the changes are saying "this file isn't encoded,
> stupid, leave it alone" (if Emacs used UTF-8 internally, most such
> files could be stored and read as UTF-8 too, but there's still need to
> deal with genuine byte-streams, of course). And that's something that
> needs to be handled regardless.
Yes. I don't quite see how to achieve a multilingual Emacs without
doing basically what Mule does now (seen from an Elisp programmer
viewpoint) -- you have to say what charset each file you are dealing
with uses. Of course, a newsreader is in a special situation since we
there have what we need in filesystems (but don't have) -- explicit
charset information. (Thank you, MIME, for that one at least.)
But surely there someone must be able to come up with something more
sensible than having to wrap each and every single file writing
operation with:
(let ((pathname-coding-system some-coding-system-variable)
(coding-system-for-write some-other-coding-system-variable))
(write-region 1 10 "/tmp/thing"))
However, I sure can't think of a solution.
--
(domestic pets only, the antidote for overdose, milk.)
la...@ifi.uio.no * Lars Magne Ingebrigtsen
Johan Kullstam
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> * Johan Kullstam <kull...@ne.mediaone.net> 19 Feb 1999 13:38:18 -0500
> | one solution is clear. unfortunately, it is beyond the scope of
> | emacs, but would require changing the operating system and its filesystem.
>
> | put meta data onto a file.
>
> This does not require changing the OS or the filesystem -- it simply
> requires doing it in an accepted (ie, standard) fashion.
well, yes, of course. you could leave the OS and filesystem alone and
simply rewrite every application that reads or writes a file. yes,
that would be *much* easier.
> The Macintosh 'forked' filesystem is simply one way of doing it.
hmm i am not familiar with it.
--
Johan Kullstam [kull...@ne.mediaone.net] Don't Fear the Penguin!
Erik Naggum
| The whole notion of dealing with character sets (except in how they
| relate to the outside-Emacs world, and except for octet-streams) is
| alien. But maybe it's not in Japan?
well, consider two countries, Norway and Sweden, because they have the
same vowels but write them differently. assume a 7-bit character set
based on ISO 646 (of which ASCII is the International Reference Version)
and replace the "national characters" [\]{|} with ЖШЕжше in Norway and
with ДЦЕдце in Sweden. that is, the code displayed as `[' on terminals
that display ASCII, displays as `Ж' in Norway and as `Д' in Sweden.
suppose you need to include a Swedish name in a Norwegian text. now,
let's assume you're not exactly a genius, so the obvious solution does
not come to mind. what do you do? you encode the character set of each
character or a sequence of characters in your text.
one good way to do this character set encoding business is with a
stateful encoding that identifies and switches between character sets.
this is what ISO 2022 is all about. MULE can read ISO 2022 files. this
is good in files, protocols and such. it also makes sense to ask "which
character set is active" and "which character in that character set has
this code" about an ISO 2022 stream. it is also obviously useful to know
which characters a character set is made up of, but this breaks down with
questions like "which character set does this _character_ belong to".
even though Norway and Sweden share the vowels and write them differently
so it would be an insult of sorts to write names from the other country
with the wrong characters, they also share the 26 _other_ letters. it
therefore makes sense to ask "which character set does `Ж' belong to?",
but "which character set does `E' belong to" has no _one_ answer.
in Japan, this is quite different. not only do they have multiple
character sets in use at the same time, like JIS X 0208 and JIS X 0212,
which contain _more_ Japanese characters. Sweden had two character sets,
too, one for names and one for other uses. come to think of it, Norway
also had two character sets, one for private and for government use.
(did this ever _work_? no. was it a seriously demented idea in the
first place? yes. the government use has been discontinued in Norway
and I haven't seen anything but the names set in use in Sweden for years.)
given that you have two different 7-bit sets, how do you encode a string
of characters from both sets in memory, since memory is a bit different
from files (pun intended) and have very different access patterns? even
a subgenius would seize the opportunity to create a common character set,
but you are not allowed be that smart, yet, so hold your horses. since
there's a spare bit, let's use that, instead: let's shift the Swedish
codes into the right half of the character set table. obviously, you now
have two different `A's, and a lot of problems will ensue, but let's fix
_those_ problems with an equivalence table. argh!
there _is_ a shred of evidence to support some belief in a constructive
element to this insanity, and it is that files on disk should not change
except as actually changed, but dealing with the inherent differences
between random and sequential access is perhaps the least well understood
of all in computer practice, because people would be afraid to drag this
dirt into a computer science class, so each programmer has to solve this
problem his own way, and we're en route to hell.
now, let's chuck the dunce cap and start thinking.
Norway and Sweden should obviously cooperate to create a common character
set, and that happened in the newspaper industry, which has to report on
lots of people and places with funny names. the bibliographic "industry"
followed suit with even larger sets, and then the computer industry, with
Digital Equipment Corporation still on top of things, created a character
set that worked very well in most of Europe, and this became ISO 8859-1
in due course, with some more character sets so we could cover the rest
of Europe and include Greece and Israel and the Cyrillic block. we still
have a bunch of different character sets with common characters, so the
problem isn't _solved_, but at least we got rid of the most annoying
problems.
how would a smart person solve the problem of combining "one character,
one code" and read-write consistency of files? one good way is to regard
the coding as a uniquely file-based property, so that nothing you extract
from a buffer retains any knowledge of the original coding, but of course
you can still ask about any given file position. this work well for
files created by other tools and edited by Emacs. how about creating new
files? it is obviously smart to keep files with the same coding in the
same directory, so creating new files could find some sort of defaulting
information from the directory the file is created in, including a simple
way to inherit from parent directories. it is equally obviously _wrong_
just to change the coding scheme in order to allow the user to enter any
odd character, since Emacs cannot know what the user's environment is
capable of handling, and a user is unlikely to understand what happens
when Emacs does what it believes is necessary to accomodate a misguided
wish. respect for the environment is a desideratum, and Emacs therefore
needs to know a lot about that environment.
MULE knows a lot about the Japanese environment, and that's good, so
there's no need to undo MULE for Japan. it might even be a good idea to
ignore Unicode's ideographic zone completely and just map the prevailing
character set(s) into that zone as a means of accomodating environments
that users actually live in. the rest of the world uses a small fraction
of the number of ideographic characters, so this might also save us a lot
of memory in tables and such.
| I suspect the bulk of the changes are saying "this file isn't encoded,
| stupid, leave it alone" (if Emacs used UTF-8 internally, most such files
| could be stored and read as UTF-8 too, but there's still need to deal
| with genuine byte-streams, of course).
UTF-8 is an external coding scheme, but it's pretty stupid to use it in
memory. something as basic as characters should have constant width and
be conveniently placed in a simple vector with random access, instead of
requiding sequential access into strings.
the right solution when it comes to vectors of characters is to use 8,
16, or 24 bits per character, the same way we specialize vectors on
bytes, half-words, and words today. should the world (universe?) need
more than 16 million characters, there should be no impediment to use 32
bits, either, but going from 16 to 32 just because you need a few more
codes above 65536 is not a good idea. (UTF-16 has a mechanism whereby a
million characters may be encoded using one out of 1024 low and one out
of 1024 high codes. this creates a lot of problems for a lot of people,
but it may be a while before we really need to handle this case.)
none of this will come to pass, however. the world is simply not ready
for intelligence applied to text in computers. lots of stupid people
will continue to create the character set equivalents of the year 2000
problem and make faulty assumptions that will still hurt us for many,
many years, viz: "I know which century it is, stupid" and "I know which
character set it is, stupid", and the morons who make all the stupid
noise about "Y2K" are extremely unlikely to understand the real issue,
which is the _fundamental_ differences between internal and external
representation of data, which again is an instance of a problem that we
will probably need 20 years to really understand and solve, and that is
the problem of representing context as data instead of in code.
#:Erik
Erik Naggum
| well, yes, of course. you could leave the OS and filesystem alone and
| simply rewrite every application that reads or writes a file. yes,
| that would be *much* easier.
perhaps you'd like to _think_ about this, instead? consider that we
already _have_ a lot of meta-information, but in the shape of the memory
of users, in error handling in programs, in swearing when printing a file
causes 300 pages of garbage, and in all sorts of human responses. it is
obviously impossible to get _all_ of this communicated to the computer,
such as the meaning of the name of a file or the real intention behind a
letter to the editor, but not starting is obviously the wrong answer.
we have had a decade of user-friendly computing causing a lot of trouble
for us, and I predict that as the computer illiterate that buy Microsoft
products that perpetuate all the problems stop buying or become more
literate, we will enter a long period of computer-friendly users who will
actually realize that computers aren't their subservient slaves, they are
virtual colleagues. as the computing power in office computers continues
to sky-rocket, there is only a question of time before it is possible to
add the sort of artificial intelligence that analyzes what you do and can
begin to predict you, instead of you analyzing what you _think_ you do
and then programming the computer to do that. in order to get there, we
need to let the computer know more about what we want to do and what our
goals and premises are.
now, a lot of people are intimidated by intelligence, real or artificial,
and get scared when smart people can predict their behavior, but this is
mostly because the only real _contact_ with such behavior is from evil
people who use their ability to predict as a means of controlling people
or destroying them. I know managers who are exceedingly smart and are
able to predict their employees' individual reactions to a whole lot of
issues and situations. an employee may "lie" about how much time some
task might take and a smart manager will know how much time will actually
be used and plan accordingly. an employee may be seriously upset about
something going on in the world around him and will work with only 50% of
normal efficiency if it comes up, and probably waste everybody else's
time ranting and raving about it, too, and a very smart manager follows
the news sufficiently well to predict their behavior and answer with a
_caring_ attitude that restores productivity and doesn't waste company
time, while at the same time ensuring that the issue is taken seriously.
(the obvious example is refugees or immigrants whose home countries are
in deep shit or are unfairly treated in the media -- I know managers who
are so inept at dealing with such situations that they don't hire good
people from such areas out of fear of housing a one-man protest movement
or loose cannons.)
so, to bring this digression back to Emacs, I think it would make a lot
of sense to represent as much context as possible and find ways to let
the Emacs figure out what you _really_ want and help you do that, instead
of "helping" you get what you think you want, which for most people are
sadly far apart. however far into the future a virtual colleague may be,
the way to start getting one (and I want one), is to make all assumptions
as explicit as possible, to think about ways to represent context, to
leave markers in your code or documents or notes about stuff that makes
you do what you do. some people write a diary and organize all their
context in one extremely inaccessible place, but the principle is good:
learn to express your thoughts, desires, and reactions along with what
you do on and with the computer. it may not help a lot today, but if
it's there, you will over time accumulate a sizeable amount of data that
just waits to be analyzed and used productively. one such thing, which I
first heard about from Don Knuth in a guest lecture at the U of Oslo, was
to use a "bug diary", which is a living record of all your coding
mistakes and problems, with solution and debugging history and such.
this doesn't give you a lot when you start doing it, but it makes it much
more likely that you make many more mistakes _once_, and actually know
how to avoid them in the future, and avoid them the right way and for the
right reasons.
a good start is to keep notes along with your files about the environment
in which you intend to use them. you might be surprised how fast it
changes, and how much time is lost in trying to reestablish a context
once it's gone. this is like writing comments in source code: what
you'll need when you go back to that code much later is to understand
what you were trying to accomplish and why. all programming languages
offer special and convenient syntax for this kind of meta-information.
very few text processing tools do. very few people learn in school to
document their thinking processes: even essays intended to expose
thinking processes are judged by their end result, not how the student
got there, which would have been _much_ more useful to the teacher. I
think it's high time we started to let the computer in on our thinking.
so think of the computer as a future virtual colleague and yourself as
your own teacher down the road. or in other words: be conscious about
what you do and share it with the computer. (incidentally, remember to
encrypt your files once you start doing this -- there are enough people
out there who will use this information against you if they at all can.)
#:Erik
Lars Magne Ingebrigtsen
> how would a smart person solve the problem of combining "one character,
> one code" and read-write consistency of files? one good way is to regard
> the coding as a uniquely file-based property, so that nothing you extract
> from a buffer retains any knowledge of the original coding, but of course
> you can still ask about any given file position.
In practical terms, how would Emacs know what charset the files
created by other programs use?
> this work well for files created by other tools and edited by
> Emacs. how about creating new files? it is obviously smart to
> keep files with the same coding in the same directory, so creating
> new files could find some sort of defaulting information from the
> directory the file is created in, including a simple way to
> inherit from parent directories.
Hm. Perhaps a file called ".charset" (or something) in a directory
that would say what charset files (and subdirectories) in the
directory use?
And if you try to save a file that can't be encoded using that charset
in those directories, Emacs would complain and the user would decide
what to do. Hm.
Steinar Bang
> Hm. Perhaps a file called ".charset" (or something) in a directory
> that would say what charset files (and subdirectories) in the
> directory use?
It should be generalized beyond that with more file metainformation.
MIME-type of the file contents is the first that comes to mind.
Steinar Bang
> Stainless Steel Rat <rat...@peorth.gweep.net> writes:
>> The Macintosh 'forked' filesystem is simply one way of doing it.
> hmm i am not familiar with it.
If you look at macintosh files with a resource editor like "ResEdit"
you'll find that it has a data fork and a resource fork. The data
fork is what we normally would think _was_ the file (the text in a
text editor file). The resource fork consist of misc. metainformation
in the form of resources.
In addition the file system has more information on each file than
eg. the UNIX or DOS file systems. It has information about the type
of the file and the creator of the file.
When a UNIX machine is file server for Macintosh boxes (eg. running
CAP), it will store the resource fork and the extra file information
in files with the same name as the file holding the data fork, but
residing in subdirectories with names like .head and .res (I don't
remember the exact names used, it's been a few years).