Get \201 when I edit mail

Get \201 when I edit mail

[Nicolas Morais]

This might have to do with other Emacs settings, but I see this only
in pgnus v0.75 (don't ask me if it was there before 0.75).

If I edit a mail ( e into summary buffer ) that has special
characters like "é", the next time I select the group and read the
message, I get \201 in front of every one of these characters.  

If I edit again the message, there is an extra \201 in front of every
\201 already there.  And so on every time I edit.

If I believe the emacs mode bar, my coding system is iso-latin-1.

Any tricks around that, or is this a problem with pgnus0.75 ?

Have a good day and thanks,

Nicolas

-- 
  Nicolas Morais, CAE Électronique Ltée, 
  8585 Côte-de-Liesse Saint-Laurent,  Québec, Canada H4T 1G6
  Email: nimo@cae.ca  Tél.: (514) 341-2000 x3525

Re: Get \201 when I edit mail

[Lars Magne Ingebrigtsen]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Given the recent discussion in the gnu.emacs newsgroups, I am under the
> impression that this is actually a bug in MULE. 

Well -- it has more to do with how Gnus de/encodes things "manually".

I've been thinking quite a bit about how to do article editing, and I
just can't see any way to allow that in an elegant way -- especially
with MIME gunk and MULE gunk in the way.

The two possible approaches that I see are these:

1) When editing a MIME message, not necessarily a multipart one, but
   that as well, we plop the user into something that looks more or
   less like a Message buffer with the article in.  Multipart articles
   are transformed into MML (text parts just get a "part" marker
   before them and non-text parts get a part that has the contents in
   an external file).  When finishing the editing, Gnus does what
   Message does -- transforms the MML back into MIME.

   This approach means that the user has little actual control over
   the details of the resulting article.  For instance, parts of the
   result may be base64-d, etc.

2) Do a `C-u g' before the editing, and let the user edit the
   completely raw article.

I don't really see any middle road.

Of course, if we have 1), we also must have 2).  But 1) will be a
major bitch to write, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Get \201 when I edit mail

[Lars Magne Ingebrigtsen]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Bitch at RMS.  Tell him to fix the idiocy in MULE, or at least all the
> stupid bugs.  Things get done at the FSF if the right people complain.

I don't really know what to complain about.  Gnus is in a different
position from, well, everything else in Emacs in that the things that
Gnus deals with have explicit information in the files themselves as
to what character set they use, while the rest of Emacs converts when
reading/writing.  So Gnus uses quite a bit of energy to avoid the
implicit transformation so that the explicit transformation can be
done safely.

But at the moment I can't really envision how to do the implicit
transformation in any other way than what MULE does.  This might mean
that implicit transformation is a bad thing, or it might mean that I
don't have a wild enough imagination.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Get \201 when I edit mail

[Hallvard B Furuseth]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> Bitch at RMS.  Tell him to fix the idiocy in MULE, or at least all the
>> stupid bugs.  Things get done at the FSF if the right people complain.
> 
> I don't really know what to complain about.  Gnus is in a different
> position from, well, everything else in Emacs in that the things that
> Gnus deals with have explicit information in the files themselves as
> to what character set they use,

Only because rmail doesn't seem to handle Content-Type: ...charset=xxx.

> while the rest of Emacs converts when reading/writing.  So Gnus uses
> quite a bit of energy to avoid the implicit transformation so that the
> explicit transformation can be done safely.

You mean you _haven't_ bitched that MULE makes it hard to work with
files that have explicit character set information??

> But at the moment I can't really envision how to do the implicit
> transformation in any other way than what MULE does.  This might mean
> that implicit transformation is a bad thing,

Depends on what you mean.  Automatic translation can be good after
someone asks for it it, but not when it's done by default.

E.g. if Emacs had tagged objects (buffers, strings, whatever) with their
coding system and also let you modify the tag, then copying an object to
one with a different coding system could automatically convert.  That
can be good.  And it can be bad if abused.

-- 
Hallvard

Re: Get \201 when I edit mail

[Hallvard B Furuseth]

I wrote:

>> Gnus is in a different
>> position from, well, everything else in Emacs in that the things that
>> Gnus deals with have explicit information in the files themselves as
>> to what character set they use,
> 
> Only because rmail doesn't seem to handle Content-Type: ...charset=xxx.

Er... I meant, that's why Gnus is different.

Re: Get \201 when I edit mail

[Lars Magne Ingebrigtsen]

Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:

> You mean you _haven't_ bitched that MULE makes it hard to work with
> files that have explicit character set information??

Not a lot; no.  :-)  The Mule stuff is sometimes so complex that once
you've identified where things go wrong, you've also added things to
work around the weirdness, and then you can't reproduce the bug any
more.  Most of the problems are nigh-impossible to reproduce outside
of the particular situation you're in.

I remember, for instance, when doing an `insert-buffer-substring' from
the " *server...*" buffer to the " *nntpd*" buffer and there was an
iso-8859-1 character in the former buffer, then the latter buffer
would end up with the original text, plus "\n\n random-character" at
the end of the buffer.  (This was the cause of the "Gnus hangs forever
when entering some groups" bug that plagued us for a month or so.)  I
was completely, totally unable to reproduce it outside of Gnus, and it
was completely reproducible inside Gnus.  RMS, Handa (I think) and I
weren't able to fix it, so I worked around it.  *shrug*

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Get \201 when I edit mail

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2429 bytes --]

Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:

> > So Gnus uses quite a bit of energy to avoid the implicit transformation
> > so that the explicit transformation can be done safely.

> You mean you _haven't_ bitched that MULE makes it hard to work with
> files that have explicit character set information??

I do not speak Mule, and many people warned me that it is not easy to do
it proficiently.  On one hand, it discourages me a bit; on the other hand,
it raises my admiration for those who do! :-)

For PO files (those files containing English texts and their translation
in another language), we decided for a MIME-like header to drive charsets.
I begged Handa-san to tell me how to interface PO files with Mule display,
and he kindly provided a few lines of Emacs LISP code which I blindly
added to `po-mode.el', making the happiness of many translators using Emacs.

My point is that Handa's modification was a little thing, and so, it would
be grossly exaggerated to call it "hard".  Yet, it would have been hard
for me to discover it all alone.  I guess that Mule would appear easier if
people, like me, knew better where to find some full documentation for it.
I saved many `.texi' fragments I found here and there, most of these are
old and of uneasy reading.  My impression is that the FSF did not really
reuse nor rejuvenate the documentation made by the original Japanese team.[1]

We often underestimate the importance of having complete, legible,
properly updated documentation in the success of a package, or the speed
of acceptance.  For packages being changed, reimplemented, challenged,
and rethought all along like Mule seems to be, the documentation job might
become especially difficult.

--------------------
[1] FSF and documentation...  I had to live some, euh, hum, /difficulties/
about the `tar'/`paxutils' manual, in the form of strong interference.  If I
did not break free, `tar' would probably not have a manual yet.  (Of course,
the FSF might hold me responsible that we do not have a *better* manual.)
It is not hard for me to imagine that the Japanese team had similar problems,
yet the plain truth is that I have no idea of the real story.  The FSF is
discrete, and those Japanese fellows are polite enough to stay silent! :-)

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Get \201 when I edit mail

[Lars Magne Ingebrigtsen]

François Pinard <pinard@iro.umontreal.ca> writes:

> I guess that Mule would appear easier if people, like me, knew
> better where to find some full documentation for it.

Yesyesyes!  But there isn't any, really.

> We often underestimate the importance of having complete, legible,
> properly updated documentation in the success of a package, or the speed
> of acceptance.

Indeed.  I don't think the importance of (good and/or complete)
documentation can be overestimated.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Get \201 when I edit mail

[Michael Welsh Duggan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I've been thinking quite a bit about how to do article editing, and I
> just can't see any way to allow that in an elegant way -- especially
> with MIME gunk and MULE gunk in the way.
> 
> The two possible approaches that I see are these:
> 
> 1) When editing a MIME message, not necessarily a multipart one, but
>    that as well, we plop the user into something that looks more or
>    less like a Message buffer with the article in.  Multipart articles
>    are transformed into MML (text parts just get a "part" marker
>    before them and non-text parts get a part that has the contents in
>    an external file).  When finishing the editing, Gnus does what
>    Message does -- transforms the MML back into MIME.
> 
>    This approach means that the user has little actual control over
>    the details of the resulting article.  For instance, parts of the
>    result may be base64-d, etc.

How about the following approach?

When editing the message, the user sees basically what he would see in
the *mail* buffer were he creating the message in the first place.
Parts displayed inline normally remain inline, others get an MML tag.
The MML tags are uneditable (by default), and hitting `RET' or
clicking on the tag brings up the part in a seperate buffer
(unencoded).  This should then be editable, accepting changes with
`C-c C-c' and cancelling changes with `C-c C-k'.  The parts are cached
away in buffers when not being edited.  These buffers, and the main
buffer, are protected by `kill-buffer-query-functions' and
`kill-buffer-hook'.

Of course, you should be able to kill tags and their related parts as
well, and have an easy way to restore them before saving changes...

Now, this approach is what I would call an "easy" approach.  (From the
user's point of view.)  What it does not do, the way I have stated it,
is maintain part seperation between consecutive inlined parts.  This
may be a fatal flaw of some sorts...

-- 
Michael Duggan
(md5i@cs.cmu.edu)
.

Re: Get \201 when I edit mail

[Michael Welsh Duggan]

Of course, right after I write this, I read on to read your note
saying that this is just what you did.  Precognitive, Lars?

-- 
Michael Duggan
(md5i@cs.cmu.edu)
.

Re: Get \201 when I edit mail

[Lars Magne Ingebrigtsen]

Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

> The MML tags are uneditable (by default), and hitting `RET' or
> clicking on the tag brings up the part in a seperate buffer
> (unencoded).

Hm...  Well, I don't see why the tags should be uneditable -- why not
let people change, say, the filename parameter if they wish?  Of
course, they may then do something wrong and ruin the tag, but that
must surely be their business.  :-)

But the bit about bringing up the unencoded part in a separate buffer
I like.

> Of course, you should be able to kill tags and their related parts as
> well, and have an easy way to restore them before saving changes...

If the tags are gone, then the parts won't be included in the edited
message, which sounds right to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen