Re: documentation bug: Mule and MSDOS

[Francesco Potorti`]

I'll try to explain (from my  point of view) how the perspective of Dirk
Janssen is similar to mine.  Please take all statements in the following
as  my personal  point of  view.  I  am not  really trying  to interpret
Dirk's views, nor to affirm that I am generally right.

"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.

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.

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.

   > 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.
   
   > 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.

Also, I'd advocate that codepage-setup should not be needed.  Code pages
should  be  available  by  default.

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 :-(

   > even not when I next choose this as an encoding in the
   > problematic buffer.
   
   > 1. Make the MULE doc more `hands-on'. Currently, it tells me a whole
   > lot about various options and possibilities, but too little about how
   > I put it to use. 
   
   I don't think this is possible in general: there are too many
   different combinations of the ``primitive'' operations described in
   the manual; describing them all, or even a large portion of them, in a
   cookbook style fashion would be impractical.

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.

Better yet, menu  entries for changing the code system  of an open file.
If it's impossible  to do it without rereading the  file, the menu entry
should  offer that:  revisit the  file using  a different  coding system
chosen from a menu.