bug-gnu-emacs
[Top][All Lists]
Advanced

[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 ;-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]