bug#6081: 23.1; emacs23 and etach

bug#6081: 23.1; emacs23 and etach

[enno.vet]

New rmail.el isn't compatible with etach.el (J. Rulnick's MIME extension for emacs) anymore.
The change in the file format from BABYL to mbox isn't necessary the culprit, but the introduction of rmail-attr-array seems to be crucial:  apparently it offers only 8 possible different 'attributes', and the `detached' attribute that etach wants to make use of is not among them.  Thus rmail complains: "Unknown attribute `detached'", and etach cannot carry on with its business.  Trying to simply add the `detached' attribute to rmail-attr-array -- with my extremely limited knowledge of lisp -- merely leads to further different errors, like rmail's "Warning: corrupt attribute header in message".  Trying to add the attribute as a label instead doesn't work either.

Alas, if there is no working etach or similar tool available to DETACH attachments from the rmail file (i.e. to save them elsewhere, not within the RMAIL file), my humble self and all the other folk complaining about this very problem will have to go without emacs as a mailer and switch to mutt or something else in the future :(


In GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.18.2)
 of 2009-11-02 on raven, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10605000
configured using `configure  '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: C
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: de_AT
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: de_AT@euro
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  which-function-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <menu-bar> <help-menu> <send-emacs-bug
-report>

Recent messages:
Loading 00debian-vars...done
Loading /etc/emacs/site-start.d/50dpkg-dev.el (source)...done
Loading /etc/emacs/site-start.d/50git-core.el (source)...done
Loading /etc/emacs/site-start.d/50lilypond-data.el (source)...done
Loading /etc/emacs/site-start.d/50pspp.el (source)...done
Loading /home/enno/.emacs.d/etach.el (source)...done
Loading which-func...done
For information about GNU Emacs and the GNU system, type C-h C-a.

bug#6081: 23.1; emacs23 and etach

[Glenn Morris]

enno.vet@gmx.net wrote:

> Alas, if there is no working etach or similar tool available to
> DETACH attachments from the rmail file (i.e. to save them elsewhere,
> not within the RMAIL file), my humble self and all the other folk
> complaining about this very problem will have to go without emacs as
> a mailer and switch to mutt or something else in the future :(

Perhaps the others have been using the rmail-mime command,
mentioned in NEWS and the manual, and bound to the `v' key.
(The 23.1 version has some bugs, hopefully the version in 23.2 will be
better.)

bug#6081: 23.1; emacs23 and etach

[Stefan Monnier]

>> Alas, if there is no working etach or similar tool available to
>> DETACH attachments from the rmail file (i.e. to save them elsewhere,
>> not within the RMAIL file), my humble self and all the other folk
>> complaining about this very problem will have to go without emacs as
>> a mailer and switch to mutt or something else in the future :(

> Perhaps the others have been using the rmail-mime command,
> mentioned in NEWS and the manual, and bound to the `v' key.

IIUC rmail-mime does not allow you to detach attachments, only to view
them and save a copy elsewhere.


        Stefan

bug#6081: 23.1; emacs23 and etach

[Glenn Morris]

Stefan Monnier wrote:

> IIUC rmail-mime does not allow you to detach attachments, only to view
> them and save a copy elsewhere.

So "detach" means actually remove from the mbox file?
If that is an important distinction, perhaps rmail-mime to save the
attachment + rmail-edit to remove the original from the Rmail file
offers equivalent functionality, to some extent.

bug#6081: 23.1; emacs23 and etach

[Stefan Monnier]

>> IIUC rmail-mime does not allow you to detach attachments, only to view
>> them and save a copy elsewhere.
> So "detach" means actually remove from the mbox file?

That's what I understood from the original message:

    (i.e. to save them elsewhere, not within the RMAIL file)


-- Stefan

bug#6081: 23.1; emacs23 and etach

[enno.vet]

>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
    >>> IIUC rmail-mime does not allow you to detach attachments, only
    >>> to view them and save a copy elsewhere.
    >> So "detach" means actually remove from the mbox file?
> 
> That's what I understood from the original message:
>     (i.e. to save them elsewhere, not within the RMAIL file)

> IIUC rmail-mime does not allow you to detach attachments, only to view
> them and save a copy elsewhere.

Exactly.

Unfortunately quite a few of my correspondents readily send attachments completely unnecessarily -- more or less automatically going with their responses to mails with attachments -- and I'm certainly not in a position to educate them about it.

So a lot of redundancy ends up in my mail file, and I cherish the possibility to actually dispose of that.  etach's detach does exactly that, pulls the attachment out of the mail, offers to save it (poss. with a different name), and just makes a note that it has removed an attachment and to which file such like:
"""
------_=_NextPart_001_01CAEB5E.3071D732
Content-Type: text/plain; charset=us-ascii
X-Former-Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Former-Content-Transfer-Encoding: quoted-printable

[file:/home/enno/detached/FILE_0004.html]
------_=_NextPart_001_01CAEB5E.3071D732--

"""

As you can imagine, this helps to reduce the size of my mail file considerably, which in turn makes working with email as quick as you would expect it (Emacs gets a wee bit slow with a mail file of several MBytes...).

Brgds, enno.

bug#6081: 23.1; emacs23 and etach

[Richard Stallman]

I made a version of etach.el that works with the current Rmail.
But the maintainers did not want to install etach.el, so I
don't know what to do with it.

bug#6081: 23.1; emacs23 and etach

[Glenn Morris]

Richard Stallman wrote:

> I made a version of etach.el that works with the current Rmail.
> But the maintainers did not want to install etach.el, so I
> don't know what to do with it.

You could post it to gnu.emacs.sources.

What features does it offer you that standard Rmail does not, other
than the ability to delete attachments (which hopefully is not hard to
add)?

bug#6081: 23.1; emacs23 and etach

[enno.vet]

>>>>> "RMS" == Richard Stallman <rms@gnu.org> writes:
>  I made a version of etach.el that works with the current
> Rmail.  But the maintainers did not want to install etach.el,
> so I don't know what to do with it.

You could put it on sourceforge.  I'd have thought that you'd have a plenty of possibilities as to where to file it, and I'm certain I'm not the only one who's interested.

Sorry for late answer, but I had to overhaul my laptop after a bath in coffee -- the keyboard's still not quite right.

Brgds, e.