[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: documentation bug: Mule and MSDOS
From: |
Eli Zaretskii |
Subject: |
Re: documentation bug: Mule and MSDOS |
Date: |
Thu, 29 Mar 2001 13:32:00 +0200 (IST) |
On 29 Mar 2001, Francesco Potorti` wrote:
> I'll try to explain (from my point of view) how the perspective of Dirk
> Janssen is similar to mine.
Thanks.
> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > From: dirk janssen <dirkj@br905lap.ntz.uni-leipzig.de>
> > 1. I assumed I had to convert the buffer *after* it was read in
>
> I don't understand why did you assume this.
>
> The reason is that it is the most natural way to make things work. I
> find the user interface of Emacs coding system very unintuitive. I am
> not speaking of technical reasons here, only of usability.
Technically, Emacs actually works that way: it reads the text verbatim,
then converts it in-place. But this is hidden from the user, of course,
unless you do it by hand with find-file-literally and
decode-coding-region.
> What I would consider usable and simple would be being able to read the
> file, then, if I see that it is not displayed in the correct way, having
> a menu with a lot of possible coding systems to choose from, and being
> able to change the display of the file's contents until one coding
> system satisfies me.
This is not simple: until the file is decoded, you have no real hope to
see it as anything but garbage (with the exception of pure ASCII),
because Emacs has no idea how to display the non-ASCII characters.
> Having to choose the coding system *before* reading the file in is very
> unnatural to me. Being unable to change it without closing the file and
> rereading it is close to absurd.
As I said earlier, with some encodings, decoding is a lossy operation.
So it is not always possible to avoid rereading the file, unless Emacs
stores the original file's contents in addition to the decoded one.
> > 2. I could find info on disabling multibyte, but not much on enabling
> > it
>
> ??? I'm probably missing something because I don't see how is this
> related to the problem of visiting files encoded in IBM codepages.
>
> I always had the same difficulties while reading the manual. As soon I
> wanted to understand something about coding systems and started reading
> the manual, I stumbled upon that multibyte thing, and the first and
> foremost thing I wanted to know was how to enable and disable it, and I
> was most frustrated to find it difficult to understand how to do it.
The original question was about enabling multibyte. I'd expect the
manual to make it clear it is enabled by default, but perhaps it can do a
better job in making this clear.
> > 3. the MULE docs do not mention codepages at all, one has to go to the
> > emacs on dos section.
>
> The most efficient method of finding something in the manual is by
> using the Info-index command (bound to `i' in Info mode). If you use
> that, you will find the information no matter where in the manual it
> is located.
>
> Yet, code pages are in very common use, and thay indeed should be
> mentioned somewhere else.
They are in the pretest version of Emacs 21. I quoted the manual
fragment which tells that; if you think something's missing from that
fragment, please tell.
> Also, I'd advocate that codepage-setup should not be needed. Code pages
> should be available by default.
I'm not sure. The original motivation was that there are dozens of them,
and it didn't seem justified to bloat everybody's Emacs with them.
There's a TODO item to make them be automatically created when needed;
when that happens, from user's point of view they could be seen as always
loaded.
> In practice, what I need is just latin-1, possibly latin-15, and
> windows-1252. By the way, now that I have learned about codepage-setup,
> I see that windows-1252 is not there :-(
You could simply use define-alias-coding-system, since windows-1252 is
identical to latin-1 where they coincide. As for characters which are
not part of the latin-1 character set, windows-1252 won't help you, since
a coding system can currently produce characters from a single charset.
> I must say that I found Dirk's explanation *very* helpful.
>
> And I must add that it took quite a lot of time for me to understand how
> to read and write a file in a given coding system. Some chapters with
> "how to do" style would be very handy in the section about coding
> systems.
Could you perhaps read the current pretest version of the manual and see
if something still needs to be changed? The manual has changed a lot
since Emacs 20.7, both in the general Mule-related sections and in the
MS-DOS chapter. It is hard to correlate your and Dirk's remarks with the
current manual text, especially since _I_ don't have many unclear aspects
of these issues ;-)