Sending attachments

Sending attachments

[Richard Stallman]

Is there any facility that can be used in Mail mode
to put attachments into the message?

If not, would someone like to write one?

Re: Sending attachments

[Alfred M. Szmidt]

   Is there any facility that can be used in Mail mode
   to put attachments into the message?

I use attach-file (C-c TAB) if it is just plain text, or etach (file
attached) if I send something binary.

===File ~/elisp/etach.el====================================
;;;     etach is an Emacs extension for handling MIME mail.
;;;     Copyright (C) 2000-2009 John M. Rulnick

;;;     This program is free software; you can redistribute it and/or
;;;     modify it under the terms of the GNU General Public License as
;;;     published by the Free Software Foundation; either version 2 of
;;;     the License, or (at your option) any later version.

;;;     This program is distributed in the hope that it will be useful,
;;;     but WITHOUT ANY WARRANTY; without even the implied warranty of
;;;     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;;     GNU General Public License for more details.

;;;     You should have received a copy of the GNU General Public
;;;     License along with this program; if not, write to the Free
;;;     Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
;;;     MA 02111-1307 USA

;;;     Contact: John M. Rulnick, PO Box 299, Charlton, MA 01507-0299
;;;     USA, email: etach@rulnick.com (be sure to include the word
;;;     "etach" somewhere in the "Subject:" line of any email to this
;;;     address).

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;			   This is etach.el
;;;			   Version number:
		    (defvar etach-version "1.4.3")
;;;			   Date: 2009-03-13

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; The following macro is for compatibility with Emacs versions that do
;;; not have defcustom:

(defmacro etach-defcustom (a b c &rest d)
  (if (fboundp 'defcustom)
      (append (list 'defcustom a b c :group '(quote etach)) d)
    (list 'defvar a b c)))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; The following establishes the etach customization group.  Do "M-x
;;; customize-group RET etach RET" to set all of the etach variables to
;;; your liking; this is often preferable to using the set-variable or
;;; setq commands suggested below.  Review the comments below and the
;;; README.txt, INSTALL.txt, and FAQ.txt files that came with etach for
;;; extra details.

(if (fboundp 'defgroup)
    (defgroup etach nil
      "Manage MIME email attachments in RMAIL and Mail modes."
      :group 'etach))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Please set the variable "etach-debug" to "t" if you need to send a
;;; bug report or have problems using etach:
;;;
;;;  M-x set-variable RET etach-debug RET t RET
;;;
;;; This will create a buffer called "etach-debug" to which a transcript
;;; of etach's subsequent operation will be sent.

(etach-defcustom etach-debug nil
  "*Write etach troubleshooting messages to a buffer.
Set `etach-debug' to t to write etach troubleshooting messages to a
buffer named \'etach-debug\'."
  :type 'boolean)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; If your version of Emacs doesn't have base64-encode-region and
;;; base64-decode-region then you should set "etach-use-mimencode" to
;;; "t" by putting the following (or equivalent custom-set-variables
;;; entry) in your startup file:
;;;
;;;  (setq etach-use-mimencode t)
;;;
;;; You will then need to have a working "mimencode" command on your
;;; system.  The mimencode utility is freely and widely available.

(etach-defcustom etach-use-mimencode nil
  "*Use mimencode instead of Emacs and etach native decoders.
Set `etach-use-mimencode' to t to use the external command
\"mimencode\" instead of Emacs and etach native base64- and
quoted-printable- encoders and decoders.  Setting to t is not
necessary unless calls to the encode or decode functions generate
errors that indicate that the functions are unavailable in your
version of Emacs."
  :type 'boolean)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Put this line:
;;;
;;;  (setq etach-prompt-me-for-file-names t)
;;;
;;; (or equivalent custom-set-variables entry) into your startup file if
;;; you want etach to ask you to confirm file names for detachments.

(etach-defcustom etach-prompt-me-for-file-names nil
  "*Prompt for detachment file names.
Set `etach-prompt-me-for-file-names' to t to be prompted for
detachment file names when using the detach function.  This also
permits cancellation of individual detachments with C-g.  Leaving this
variable set to nil means detachments can proceed with default file
names and, in general, no additional user intervention."
  :type 'boolean)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Put this line:
;;;
;;;  (setq etach-fill-decoded-plain-text t)
;;;
;;; (or equivalent custom-set-variables entry) into your startup file if
;;; you want etach to fill (via the command "fill-region") areas of
;;; encoded plain text that are displayed in place after decoding.

(etach-defcustom etach-fill-decoded-plain-text nil
  "*Fill encoded regions of plain text.
Set `etach-fill-decoded-plain-text' to t to make etach fill encoded
regions of plain text viewed in place after decoding.  See also
`etach-clean-decoded-plain-text'."
  :type 'boolean)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Put this line:
;;;
;;;  (setq etach-write-text-files t)
;;;
;;; (or equivalent custom-set-variables entry) into your startup file if
;;; you want etach to write the text/plain portions of RMAIL messages to
;;; files.

(etach-defcustom etach-write-text-files nil
  "*Write text/plain portion(s) of message to file(s).
Set `etach-write-text-files' to t to make etach write the plain text
portion(s) of the RMAIL message to file(s), rather than leaving them
in the message body."
  :type 'boolean)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Put this line:
;;;
;;;  (setq etach-write-html-files nil)
;;;
;;; (or equivalent custom-set-variables entry) into your startup file if
;;; you want etach to translate the text/html portions of RMAIL messages
;;; to plain text and display them in place in the message.  You must
;;; have lynx or another effective html-to-plain-text converter available
;;; for this to function properly.

(etach-defcustom etach-write-html-files t
  "*Write text/html portion(s) of message to file(s).
Set `etach-write-html-files' to nil to make etach translate the
text/html portions of RMAIL messages to plain text and display them in
place in the message.  Requires lynx or another effective html-to-plain-
text converter.  See etach-unhtml-command."
  :type 'boolean)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; For use when etach-write-html-files is nil.  See above.

(etach-defcustom etach-unhtml-command "lynx"
  "*External command to run to convert text/html to text/plain.
For use when etach-write-html-files is nil.  Must take input from
stdin and put output on stdout."
  :type 'string)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; For use with etach-unhtml-command.  See above.

(etach-defcustom etach-unhtml-args '("-stdin" "-dump" "-underscore" "-dont_wrap_pre" "-width=70")
  "*Arguments for etach-unhtml-command.
For use when etach-write-html-files is nil."
  :type '(repeat string))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Put this line:
;;;
;;;  (setq etach-clean-decoded-plain-text t)
;;;
;;; (or equivalent custom-set-variables entry) into your startup file if
;;; you want etach to replace any control-M (generally extraneous
;;; carriage return) characters appearing in areas of base64-encoded or
;;; quoted-printable-encoded plain text that are displayed in place
;;; after decoding.

(etach-defcustom etach-clean-decoded-plain-text nil
  "*Replace control-M characters with newlines in plain text.
Set `etach-clean-decoded-plain-text' to t to make etach replace
control-M characters with newlines in encoded regions of plain text
viewed in place after decoding.  See also
`etach-fill-decoded-plain-text'."
  :type 'boolean)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Put this line:
;;;
;;;  (setq etach-detachment-default-directory "/your/preferred/directory/")
;;;
;;; (or equivalent custom-set-variables entry) into your startup file if
;;; you want etach to put detachments into /your/preferred/directory/
;;; instead of the "detached/" subdirectory of the RMAIL buffer's
;;; current working directory.

(etach-defcustom etach-detachment-default-directory "detached/"
 "*Preferred directory path for detachments.
Set `etach-detachment-default-directory' to a string containing your
preferred directory path for detachments if you prefer not to use the
default.  The default is to place detachments in a subdirectory named
\"detached\" of the current directory.  Etach will attempt to create
the directory if it doesn't already exist."
 :type 'string)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Put this line:
;;;
;;;  (setq etach-detachment-discard-directory "/your/preferred/discard/directory/")
;;;
;;; (or equivalent custom-set-variables entry) into your startup file if
;;; you want etach to put discarded detachments into
;;; /your/preferred/discard/directory/ instead of the
;;; etach-detachment-default-directory.

(etach-defcustom etach-detachment-discard-directory etach-detachment-default-directory
 "*Preferred directory path for discarded detachments.
Set `etach-detachment-discard-directory' to a string containing your
preferred directory path for discarded detachments if you prefer they
be placed somewhere other than the etach-detachment-default-directory.
It may be useful to set this to /tmp/ or the location of your \"trash
folder.\" Etach will attempt to create the directory if it doesn't
already exist.  By default, only non-text/plain parts of
multipart/alternative messages are discarded.  However, it is possible
to direct etach to discard all non-text/plain attachments simply by
calling etach-detach with a prefix arg."
 :type 'string)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Put this line:
;;;
;;;  (setq etach-restore-buffer-after-detach t)
;;;
;;; (or equivalent custom-set-variables entry) into your startup file if
;;; you want etach to simply detach any attached files and then restore
;;; the contents of the current RMAIL message when you invoke the detach
;;; command.  This can also be set via M-x set-variable RET, of course.
;;; See also etach-restore-attachments-after-detach.

(etach-defcustom etach-restore-buffer-after-detach nil
  "*Restore pre-detach contents of RMAIL buffer upon detach.
Set `etach-restore-buffer-after-detach' to t to make etach leave no
changes in the RMAIL buffer.  This is done by first performing a
detach, then replacing the (new) contents of your RMAIL buffer
entirely with the original (pre-detach) contents.  This applies when
you invoke the detach command."
  :type 'boolean)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Put this line:
;;;
;;;  (setq etach-restore-attachments-after-detach t)
;;;
;;; (or equivalent custom-set-variables entry) into your startup file if
;;; you want etach to restore the original content of any MIME parts
;;; that were written to files.  This can also be set via M-x
;;; set-variable RET, of course.  See also
;;; etach-restore-buffer-after-detach.

(etach-defcustom etach-restore-attachments-after-detach nil
  "*Restore content of MIME parts written to files upon detach.
Set `etach-restore-attachments-after-detach' to t to make etach
restore the original content of any MIME parts that were written to
files.  This allows you to use detach to decode inline
quoted-printable- or base64-encoded text and effectively copy any
attached files out to disk, but otherwise not change the content of
the current message.  It makes sense to leave this set to nil if you
have `etach-restore-buffer-after-detach' set to t, since that setting
will cause the entire buffer to be restored."
  :type 'boolean)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Customize the variable etach-spam-message via setq or
;;; custom-set-variables if you would like to use a different text
;;; message when you forward spam for handling by email postmasters and
;;; the like.

(etach-defcustom etach-spam-message
  "I have received unsolicited commercial or bulk email (spam) from, or
alleging to be from, your domain.  I would appreciate if you would
take steps to prevent this from happening in the future.

Any claims made by the sender that the message was requested by me are
false.  I have never directly or indirectly (by subscription, opt-in,
non-opt-out, or any other means) requested any such contact from the
sender.

The full content of the offending email message, including mail
transport headers, is attached below.

Thank you for your time and attention."
  "*Message to insert into spam reports."
  :type 'string)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; You should definitely customize the variable
;;; etach-spam-host-exclude-list via setq or custom-set-variables by
;;; adding more strings to the etach-spam-host-exclude-list if you plan
;;; to use the spam-handling functionality of etach-mime-forward.  The
;;; strings to add should include your own host and domain; for example:
;;;
;;; (setq etach-spam-host-exclude-list
;;;       '("localhost" "mydomain.com" "myhost.mydomain.com"))
;;;
;;; Use lowercase name strings.

(etach-defcustom etach-spam-host-exclude-list '("localhost")
  "*Specific hosts or domains to skip when sending a spam report."
  :type 'sexp)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Set the variable etach-spam-message-subject-string via setq or
;;; custom-set-variables if you prefer a different default "Subject:"
;;; line preface to be included in your spam reports.

(etach-defcustom etach-spam-message-subject-string "mail abuse report"
  "*Subject line preface to use when sending a spam report."
  :type 'string)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(etach-defcustom etach-include-x-mailer t
  "*Include the \"X-Mailer:\" header in outgoing etach mail.
Set `etach-include-x-mailer' to nil if you prefer your outgoing
etach mail (mail composed using etach's attach or mime-forward
functions) to not include the \"X-Mailer:\" header."
  :type 'boolean)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Set the variable etach-detached-file-label-separator-string via setq
;;; or custom-set-variables if you are unable to use file selection
;;; (e.g., point-and-click) convenience features on the detached file
;;; names in the RMAIL buffer.  This is reportedly useful in certain
;;; operating environments.

(etach-defcustom etach-detached-file-label-separator-string ""
  "*Separator string for padding detached file names.
Separator string to place on either side of the file name when a
file is detached and replaced by a '[file:filename]' label.  Set this
to a single space if necessary to allow easy file selection; the
result would be '[ file: filename ]'."
  :type 'string)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Set the variable etach-default-charset via setq or
;;; custom-set-variables if you wish to use an alternative such as
;;; iso-8859-1.

(etach-defcustom etach-default-charset "us-ascii"
  "*Default character set for MIME Content-Type headers.
Change the default character set name for MIME Content-Type headers if
necessary to help etach better handle or label MIME parts that contain
non-us-ascii characters."
  :type 'string)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; Immediately following is a list of associations for file name
;;; extensions and MIME types.  Add entries to the list as you like, but
;;; be cognizant of the specifications in RFCs 2045-9 (see
;;; http://www.cis.ohio-state.edu/htbin/rfc/rfc-index.html
;;; and/or
;;; http://www.faqs.org/rfcs/
;;; and/or
;;; ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/).
;;;
;;; Also, change the order within the groups of entries having the same
;;; MIME type if you wish.  The first entry provides the default file
;;; name extension.  For example, if "txt" is the first with association
;;; "text/plain" then ".txt" will be the default extension for detached
;;; files of type text/plain.

(defvar etach-mime-type-alist '(

  ("txt"  "text/plain")
  ("asc"  "text/plain")
  ("text" "text/plain")

  ("html" "text/html")
  ("htm"  "text/html")

  ("aif"  "audio/x-aiff")
  ("aifc" "audio/x-aiff")
  ("aiff" "audio/x-aiff")

  ("cdf" "application/x-netcdf")
  ("nc"  "application/x-netcdf")

  ("exe" "application/x-msdos-program")
  ("bat" "application/x-msdos-program")
  ("com" "application/x-msdos-program")

  ("ics" "text/calendar")
  ("ifb" "text/calendar")

  ("jpg"  "image/jpeg")
  ("JPG"  "image/jpeg")
  ("jpe"  "image/jpeg")
  ("jpeg" "image/jpeg")

  ("ltx"   "application/x-latex")
  ("latex" "application/x-latex")

  ("mid"  "audio/midi")
  ("midi" "audio/midi")

  ("mov" "video/quicktime")
  ("qt"  "video/quicktime")

  ("mpg"  "video/mpeg")
  ("mp2"  "video/mpeg")
  ("mpe"  "video/mpeg")
  ("mpeg" "video/mpeg")

  ("pfb" "application/x-font")
  ("gsf" "application/x-font")
  ("pfa" "application/x-font")

  ("php"   "application/x-httpd-php")
  ("pht"   "application/x-httpd-php")
  ("phtml" "application/x-httpd-php")

  ("pl" "application/x-perl")
  ("pm" "application/x-perl")

  ("ps"  "application/postscript")
  ("eps" "application/postscript")

  ("ram" "audio/x-pn-realaudio")
  ("ra"  "audio/x-pn-realaudio")
  ("rm"  "audio/x-pn-realaudio")

  ("roff" "application/x-troff")
  ("t"    "application/x-troff")
  ("tr"   "application/x-troff")

  ("texi" "application/x-texinfo")
  ("texinfo" "application/x-texinfo")

  ("tif"  "image/tiff")
  ("tiff" "image/tiff")

  ("uri" "text/uri-list")
  ("uris" "text/uri-list")

  ("xml" "text/xml")
  ("dtd" "text/xml")

  ("au" "audio/ulaw")
  ("avi" "video/x-msvideo")
  ("bcpio" "application/x-bcpio")
;  ("bin" "application/octet-stream") ; leave this commented unless you want a default of ".bin"
  ("bmp" "application/x-ms-bmp")
  ("c" "text/x-csrc")
  ("cgm" "image/cgm")
  ("cpio" "application/x-cpio")
  ("csh" "application/x-csh")
  ("css" "text/css")
  ("csv" "text/comma-separated-values")
  ("deb" "application/x-debian-package")
  ("doc" "application/msword")
  ("dvi" "application/x-dvi")
  ("etx" "text/x-setext")
  ("ez" "application/andrew-inset")
  ("g3fax" "image/g3fax")
  ("gif" "image/gif")
  ("gpg" "application/gnupg")
  ("gtar" "application/x-gtar")
  ("gz" "application/x-gunzip")
  ("hdf" "application/x-hdf")
  ("ief" "image/ief")
  ("man" "application/x-troff-man")
  ("mdb" "application/msaccess")
  ("me" "application/x-troff-me")
  ("mif" "application/x-mif")
  ("movie" "video/x-sgi-movie")
  ("ms" "application/x-troff-ms")
  ("naplps" "image/naplps")
  ("o" "application/x-object")
  ("oda" "application/oda")
  ("pbm" "image/x-portable-bitmap")
  ("pdf" "application/pdf")
  ("pgm" "image/x-portable-graymap")
  ("pgn" "application/x-chess-pgn")
  ("pgp" "application/pgp")
  ("php3" "application/x-httpd-php3")
  ("php3p" "application/x-httpd-php3-preprocessed")
  ("phps" "application/x-httpd-php3-source")
  ("png" "image/png")
  ("pnm" "image/x-portable-anymap")
  ("ppm" "image/x-portable-pixmap")
  ("ppt" "application/powerpoint")
  ("ras" "image/x-cmu-raster")
  ("rgb" "image/x-rgb")
  ("rtf" "application/rtf")
  ("rtx" "text/richtext")
  ("sgml" "text/sgml")
  ("sh" "application/x-sh")
  ("shar" "application/x-shar")
  ("snd" "audio/basic")
  ("sv4cpio" "application/x-sv4cpio")
  ("sv4crc" "application/x-sv4crc")
  ("tar" "application/x-tar")
  ("tcl" "application/x-tcl")
  ("tex" "application/x-tex")
  ("tgz" "application/x-gtar")
  ("tsv" "text/tab-separated-values")
  ("ustar" "application/x-ustar")
  ("wav" "audio/x-wav")
  ("wpd" "application/x-wordperfect")
  ("xbm" "image/x-xbitmap")
  ("xls" "application/excel")
  ("xpm" "image/x-xpixmap")
  ("xwd" "image/x-xwindowdump")
  ("zip" "application/zip")

  )
  "Association list of file name extensions and MIME types recognized
by etach.")

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; USERS SHOULD BE PARTICULARLY CAUTIOUS MAKING CHANGES BEYOND THIS POINT
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(defalias 'attach 'etach-attach)
(defalias 'detach 'etach-detach)
(defalias 'mime-forward 'etach-mime-forward)
(defalias 'quoted-printable-encode-region 'etach-quoted-printable-encode-region)
(defalias 'kill-label-detached 'etach-kill-label-detached)

(defvar etach-content-type)
(defvar etach-content-transfer-encoding)
(defvar etach-content-id)
(defvar etach-content-description)
(defvar etach-content-disposition)
(defvar etach-boundary)

;;; Here are the interactive (user-visible) functions:

(defun etach-version ()
  "Show the etach version number."
  (interactive)
  (message "etach version %s" etach-version))

(defun etach-file-attach (file-to-attach)
  "Attach a file to the present outgoing email message.  Use in Mail
mode."
  (interactive "fFile to attach: ")
  (etach-debug-msg (concat "========== file-attach called with file \'" file-to-attach "\' =========="))
  (save-excursion
    (let ((etach-content-type "")
	  (etach-content-transfer-encoding "")
	  (etach-content-id "")
	  (etach-content-description "")
	  (etach-content-disposition "")
	  (case-fold-search t))
      (etach-mime-validate-minimal-headers)
      (goto-char (point-min))
      (etach-mime-get-content-headers)
      (let ((etach-boundary ""))
	(etach-prep-outgoing-mime-message)
	(insert "Content-Type: ")
	(let ((lext ""))
	  (if (string-match "\\.\\([a-zA-Z0-9]+\\)$" file-to-attach)
	      (setq lext (match-string 1 file-to-attach)))

	  (if (assoc lext etach-mime-type-alist)
	      (progn
		(insert (car (cdr (assoc lext etach-mime-type-alist))))
		(if (string-match "text/" (car (cdr (assoc lext etach-mime-type-alist))))
		    (insert "; charset=" etach-default-charset)))
	    (insert "application/octet-stream")))
	(let ((name-sans-path file-to-attach))
	  (if (string-match "/\\([^/]*\\)$" file-to-attach) ; could use file-name-nondirectory
	      (setq name-sans-path (match-string 1 file-to-attach)))
	  (insert (if (> (length name-sans-path) 22)
		      ";\n\t"
		    "; ")
		  "name=\"" name-sans-path "\"\nContent-Transfer-Encoding: "
		  (if (or (string-match "\.te?xt$" file-to-attach)
			  (string-match "\.asc$" file-to-attach))
		      "quoted-printable\n\n"
		    "base64\n\n")))
	(insert-file-contents-literally file-to-attach)
	(if (or (string-match "\.te?xt$" file-to-attach)
		(string-match "\.asc$" file-to-attach))
	    (progn
	      (if etach-use-mimencode
		  (shell-command-on-region (point) (point-max) "mimencode -q" t t)
		(etach-quoted-printable-encode-region (point) (point-max)))
	      (goto-char (point-max)))
	  (if etach-use-mimencode
	      (shell-command-on-region (point) (point-max) "mimencode -b" t t)
	    (base64-encode-region (point) (point-max)))
	  (goto-char (point-max))
	  (or (bolp) (insert "\n")))
	(insert "--" etach-boundary "--\n")))))

(defun etach-attach (files-to-attach)
  "Attach a file or collection of files to the present outgoing email
message.  Wildcards are permitted under recent versions of Emacs.
Use in Mail mode."
  (interactive "FFile(s) to attach: ")
  (etach-debug-msg (concat "========== attach called with file(s) \'" files-to-attach "\' =========="))
  (while (string-equal (substring files-to-attach -1) "/")
    (setq files-to-attach (substring files-to-attach 0 -1)))
  (if (fboundp 'file-expand-wildcards)
      (let ((filelist (file-expand-wildcards files-to-attach)))
	(while filelist
	  (let ((file (car filelist)))
	    (if (file-regular-p file)
		(etach-file-attach file)
	      (message "not attaching \'%s\': not a regular file" file))
	    (setq filelist (cdr filelist)))))
    (if (file-regular-p files-to-attach)
	(etach-file-attach files-to-attach)
      (message "not attaching \'%s\': not a regular file" files-to-attach))))

(defun etach-detach (&optional discard)
  "Detach the encoded attachments from the present email message.  Use in RMAIL mode.
Call with prefix arg via C-u to discard all attachments."
  (interactive "P")
  (etach-debug-msg (concat "========== detach called =========="))
  (rmail-set-attribute "detached" t)
  (save-excursion
    ;; if in the x-summary buffer, switch to the x buffer:
    (set-buffer rmail-buffer)
    (goto-char (point-min))
    (let ((case-fold-search t)
	  (default-directory default-directory)
	  (require-final-newline require-final-newline)
	  (insert-default-directory insert-default-directory)
	  (copy-of-rmail-text (buffer-string))
	  (copy-of-rmail-babyl-header (etach-get-babyl-header))
	  (my-current-buffer (current-buffer)))
      (condition-case err
	  (progn
	    (if discard
		(etach-mime-detach "\\'" 0 1)
	      (etach-mime-detach "\\'" 0 0))
	    (if etach-restore-buffer-after-detach
		(etach-restore-buffer "user preference" my-current-buffer copy-of-rmail-text copy-of-rmail-babyl-header)
	      ))
	((quit error)
	 (etach-restore-buffer (concat "error: " (error-message-string err))
			       my-current-buffer
			       copy-of-rmail-text
			       copy-of-rmail-babyl-header))))))

(defun etach-mime-forward (&optional this-is-spam)
  "Use MIME message/rfc822 format to forward a message.  Use in RMAIL mode.
Call with prefix arg via C-u to reply to spam."
  (interactive "P")
  (if this-is-spam
      (etach-debug-msg (concat "========== mime-forward (spam) called =========="))
    (etach-debug-msg (concat "========== mime-forward called ==========")))
  ;; if in the x-summary buffer, switch to the x buffer:
  (set-buffer rmail-buffer)
  (let ((msg-to-be-forwarded ""))
    (if this-is-spam
	(if (etach-rmail-msg-is-pruned)
	    (rmail-toggle-header)))
    (setq msg-to-be-forwarded (buffer-string))
    (if this-is-spam
	(if (not (etach-rmail-msg-is-pruned))
	    (rmail-toggle-header)))
    (rmail-set-attribute "forwarded" t)
    (rmail-mail)
    (delete-other-windows)
    (save-excursion
      (let ((etach-content-type "")
	    (etach-content-transfer-encoding "")
	    (etach-content-id "")
	    (etach-content-description "")
	    (etach-content-disposition "")
	    (case-fold-search t))
	(etach-mime-validate-minimal-headers)
	(goto-char (point-min))
	(etach-mime-get-content-headers)
	(let ((etach-boundary "")
	      (to-list '()))
	  (etach-prep-outgoing-mime-message)
	  (if this-is-spam
	      (save-excursion
		(goto-char (point-min))
		(re-search-forward "^$") ; first blank line should be text/plain "writing area"
		(forward-line)
		(insert (concat etach-spam-message "\n"))))
	  (if (equal (find-charset-string msg-to-be-forwarded) '(ascii))
	      (insert "Content-Type: message/rfc822\nContent-Transfer-Encoding: 7bit\n\n")
	    (save-excursion
	      (goto-char (point-min))
	      (if (re-search-forward "^Content-Transfer-Encoding:.+$" (etach-mail-header-end) t)
		  (replace-match "Content-Transfer-Encoding: 8bit")
		(etach-debug-msg "no Content-Transfer-Encoding found in mail header, none replaced")))
	    (insert "Content-Type: message/rfc822\nContent-Transfer-Encoding: 8bit\n\n"))
	  (save-excursion
	    (insert msg-to-be-forwarded))
	  (if this-is-spam
	      (let ((host ""))
		;; first scan all email addresses appearing in message:
		(save-excursion
		  (while (re-search-forward "@\\([^ \]\t\n>\)\'\";,]+\\)" nil t)
		    (setq to-list (etach-extract-hosts (match-string 1) to-list))))
		;; now scan all "Received: from" header lines:
		(save-excursion
		  (while (re-search-forward "Received: from \\(.+\\)$" nil t)
		    (setq to-list (etach-extract-hosts (match-string 1) to-list))))
		(save-excursion
		  (goto-char (point-min))
		  (re-search-forward "^To: ")
		  (let ((host ""))
		    (while to-list
		      (setq host (car to-list))
		      (setq to-list (cdr to-list))
		      (insert
		       "abuse@" host ", postmaster@" host
		       (if to-list
			   ",\n\t"
			 "")))))))
	  (let ((sender "")
		(orig-subject ""))
	    (save-excursion
	      (re-search-forward "^From:[ \t]*\\(.*\\)$" nil t)
	      (setq sender (match-string 1))
	      (if (string-match "\<\\([^ ]+\\)\>" sender)
		  (setq sender (match-string 1 sender))
		(if (string-match "\\([^ ]+\\)[ \t]+\(.*\)" sender)
		    (setq sender (match-string 1 sender)))))
	    (save-excursion
	      (if (re-search-forward "^Subject: \\(.*\\)$" nil t)
		  (setq orig-subject (match-string 1))))
	    (save-excursion
	      (goto-char (point-min))
	      (re-search-forward "^Subject: ")
	      (if this-is-spam
		  (insert etach-spam-message-subject-string " "))
	      (insert "[" sender ": " orig-subject "]")))
	  (goto-char (point-max))
	  (or (bolp) (insert "\n"))
	  (insert "--" etach-boundary "--\n"))))))

(defun etach-quoted-printable-encode-region (rbeg rend)
  "Quoted-printable-encode region."
  (interactive "r")
  (etach-debug-msg (concat "quoted-printable-encode-region called"))
  (require 'font-lock)
  (let ((mime-bad-char		; all but ascii 33-60, 62-126, and \n
	 "[^\]!\"#\$%&'()\*\+,\./0-9;<:>\?@A-Z_^\[`a-z{|}~\\\n-]")
	(case-fold-search t)
	(my-global-font-lock-mode global-font-lock-mode))
    (if my-global-font-lock-mode
	(progn
	  (etach-debug-msg (concat "calling global-font-lock-mode(0)"))
	  (global-font-lock-mode 0)))
    (save-excursion
      (save-restriction
      (narrow-to-region rbeg rend)

      (goto-char (point-min))
      (while (re-search-forward mime-bad-char nil t)
	(cond
	 ((or (char-equal (preceding-char) ? )
	      (char-equal (preceding-char) ?\t))
	  (if (char-equal (following-char) ?\n)
	      (insert "=\n")))
	 (t
	  (replace-match (upcase (format "=%02x" (preceding-char)))))))

      (goto-char (point-min))
      (while (re-search-forward "^[.]" nil t)
	(replace-match "=2E" t t))

      (goto-char (point-min))
      (while (re-search-forward "^F\\(rom\\)" nil t)
	(beginning-of-line)
	(replace-match (concat (upcase (format "=%02x" (following-char))) (match-string 1)) t t))

      (goto-char (point-min))
      (while (re-search-forward		; look for 77+ chars on a line, split 73/4
	      "^\\(.........................................................................\\)\\(=[A-F0-9][A-F0-9].\\)"
	      nil t)
	(replace-match (concat (match-string 1) "=\n" (match-string 2)) t t)
	(beginning-of-line))

      (goto-char (point-min))
      (while (re-search-forward		; look for 77+ chars on a line, split 74/3
	      "^\\(..........................................................................\\)\\(=[A-F0-9][A-F0-9]\\)"
	      nil t)
	(replace-match (concat (match-string 1) "=\n" (match-string 2)) t t)
	(beginning-of-line))

      (goto-char (point-min))
      (while (re-search-forward		; look for 77+ chars on a line, split 75/2
	      "^\\(...........................................................................\\)\\(..\\)"
	      nil t)
	(replace-match (concat (match-string 1) "=\n" (match-string 2)) t t)
	(beginning-of-line))

      (goto-char (point-max))
      (if (/= (preceding-char) ?\n)
	  (insert "=\n"))))
    (if my-global-font-lock-mode
	(progn
	  (etach-debug-msg (concat "calling global-font-lock-mode(1)"))
	  (global-font-lock-mode 1)))))

(defun etach-kill-label-detached ()
  "Remove the \"detached\" attribute from this message."
  (interactive)
  ;; if in the x-summary buffer, switch to the x buffer:
  (set-buffer rmail-buffer)
  (rmail-set-attribute "detached" nil))

;;; Here are the utility (code-visible, not user-visible) functions:

(defun etach-extract-hosts (host to-list)
  "Extract hosts from candidate strings for spam to-list."
  (if (or (string-match "\\(.*\\) by[ \t\n]" host)
	  (string-match "\\(.*\\) for[ \t\n]" host))
      (setq host (match-string 1 host)))
  (if (string-match "\(really [\[]?\\([^\] ]*\\).*\)" host) ; if "really," reduce to the really part
      (setq host (match-string 1 host)))
  (if (string-match "^\\([^ ]+\\) [\(\[]+\\([^\] \)]+\\)" host)
      (let ((hosta (match-string 1 host))
	    (hostb (match-string 2 host)))
	(setq host (if (or (string-match "^[0-9.]+$" hostb)
			   (not (string-match ".+[.].+$" hostb)))
		       hosta
		     hostb))))
  (if (string-match "@\\(.+\\)" host)
      (setq host (match-string 1 host)))
  (if (string-match "^[ \t]*\\(.+\\)[ \t]*$" host) ; remove leading/trailing whitespace
      (setq host (match-string 1 host)))
  (if (string-match ".+[.]\\(.+[.].+[.].+[.].+\\)$" host)
      (setq host (match-string 1 host)))
  (etach-downcase host)
  (etach-debug-msg (concat "etach-extract-hosts extracted: " host))
  (if (not (string-match "^\[?[0-9.]+\]?$" host))
      (while (string-match "[.]\\(.+\\)" host)
	(if (or (member host etach-spam-host-exclude-list)
		(member host to-list))
	    nil
	  (setq to-list (cons host to-list)))
	(setq host (match-string 1 host))))
  to-list)

(defun etach-restore-buffer (msg my-current-buffer copy-of-rmail-text copy-of-rmail-babyl-header)
  "Restore contents of RMAIL buffer."
  (etach-debug-msg (concat "restoring buffer due to " msg "..."))
  (message "restoring buffer due to %s..." msg)
  (set-buffer my-current-buffer)
  (setq buffer-read-only nil)
  (delete-region (point-min) (point-max))
  (save-excursion
    (rmail-widen-to-current-msgbeg
     (function (lambda ()
		 (delete-region (point-min) (point-max))))))
  (etach-debug-msg "inserting everything\n")
  (insert (concat copy-of-rmail-babyl-header copy-of-rmail-text))
  (etach-debug-msg "cleaning up")
  (etach-mime-decode-cleanup 1 nil nil nil)
  (setq buffer-read-only t)
  (etach-debug-msg (concat "restoring buffer due to " msg "...done"))
  (message "restoring buffer due to %s...done" msg))

(defun etach-prep-outgoing-mime-message ()
  "Prepare outgoing message headers and boundaries (called by
etach-attach and etach-mime-forward)."
  (if (etach-mime-part-is-multipart etach-content-type)
      (progn
	(setq etach-boundary (etach-mime-get-boundary-string etach-content-type))
	(search-forward (concat "--" etach-boundary "--\n"))
	(replace-match (concat "--" etach-boundary "\n")))
    (let ((oldE)
	  (oldT))
      (goto-char (point-min))
      (if (re-search-forward "^Content-Transfer-Encoding:\\(.*\\)\n" (etach-mail-header-end) t)
	  (progn
	    (setq oldE (match-string 1))
	    (replace-match "" nil t))
	(etach-debug-msg "no Content-Transfer-Encoding found, none noted as oldE"))
      (goto-char (point-min))
      (if (re-search-forward "^Content-Type:\\(.*\\)" (etach-mail-header-end))
	  (progn
	    (setq oldT (match-string 1))
	    (replace-match "Content-Type: multipart/mixed;\n\tboundary=\"" nil t))
	(etach-debug-msg "no Content-Type found, none noted as oldT or replaced"))
      (setq etach-boundary (etach-mime-create-boundary-marker))
      (insert etach-boundary "\"\nContent-Transfer-Encoding:" oldE)
      (search-forward (concat mail-header-separator "\n") nil)
      (insert "This is a multi-part message in MIME format.\n--" etach-boundary
	      "\nContent-Type:" oldT "\nContent-Transfer-Encoding:" oldE "\n\n")
      (goto-char (point-max))
      (or (bolp) (insert "\n"))
      (insert "--" etach-boundary "\n"))))

(defun etach-who-is-this-from ()
  "Get the email address of the sender, according to the From header."
  (let ((sender ""))
    (save-excursion
      (goto-char (point-min))
      (re-search-forward "^From:[ \t]*\\(.*\\)$" nil t)
      (setq sender (match-string 1))
      (if (string-match "\<\\([^ ]+\\)\>" sender)
	  (setq sender (match-string 1 sender))
	(if (string-match "\\([^ ]+\\)[ \t]+\(.*\)" sender)
	    (setq sender (match-string 1 sender)))))
    (if (string-match "[.][a-zA-Z0-9]+$" sender)
	(setq sender (concat sender "_"))) ; do this so that, e.g., ".com" isn't seen as a file name extension
    sender))

(defun etach-create-unique-string ()
  "Return a unique string of numbers of the form YMDHMS-R where
YMDHMS is date/time and R is random."
  (concat (format-time-string "%Y%m%d%H%M%S" (current-time)) "-" (format "%09d" (abs (random)))))

(defun etach-mime-create-boundary-marker ()
  "Return a string suitable as a mime boundary marker."
  (concat "++----------" (etach-create-unique-string) "----------++"))

(defun etach-mime-validate-minimal-headers ()
  "Confirm that default headers are in place (for mail composition)."
  (goto-char (point-min))
  (if (not (re-search-forward "^Mime-Version:" (etach-mail-header-end) t))
      (progn
	(goto-char (etach-mail-header-end))
	(insert "Mime-Version: 1.0\n")))
  (goto-char (point-min))
  (if (not (re-search-forward "^Content-Type:" (etach-mail-header-end) t))
      (progn
	(goto-char (etach-mail-header-end))
	(insert "Content-Type: text/plain; charset=" etach-default-charset "\n")))
  (goto-char (point-min))
  (if (not (re-search-forward "^Content-Transfer-Encoding:" (etach-mail-header-end) t))
      (progn
	(goto-char (etach-mail-header-end))
	(insert "Content-Transfer-Encoding: "
		(if (equal (find-charset-region (point-min) (point-max)) '(ascii))
		    "7bit\n"
		  "8bit\n"))))
  (if etach-include-x-mailer
      (progn
	(goto-char (point-min))
	(if (not (re-search-forward "^X-Mailer:" (etach-mail-header-end) t))
	    (progn
	      (goto-char (etach-mail-header-end))
	      (insert (concat "X-Mailer: Emacs " emacs-version " with etach " etach-version "\n")))))))

(defun etach-mime-get-content-headers ()
  "Assign values to variables corresponding to MIME Content- headers."
  (let ((mime-header-end (point)))
    (save-excursion
      (re-search-forward "^\\([ \t]*$\\|--\\)") ; look for end of headers (blank line or "^--")
      (beginning-of-line)
      (setq mime-header-end (point)))
    (while (re-search-forward "^Content-\\([^:]*\\):[ \t]*\\(.*\\)[ \t]*$" mime-header-end t)
      (let ((field-name (match-string 1))
	    (field-body (match-string 2)))
	(while (looking-at "\n[ \t]+")
	  (re-search-forward "\n[ \t]+\\(.*\\)[ \t]*$" mime-header-end)
	  (setq field-body (concat field-body (match-string 1)))
	  )
	(etach-debug-msg (concat "found Content-" field-name ": " field-body))
	(cond
	 ((string-match "^type$" field-name) (setq etach-content-type field-body))
	 ((string-match "^transfer-encoding$" field-name) (setq etach-content-transfer-encoding field-body))
	 ((string-match "^id$" field-name) (setq etach-content-id field-body))
	 ((string-match "^description$" field-name) (setq etach-content-description field-body))
	 ((string-match "^disposition$" field-name) (setq etach-content-disposition field-body))
	 (t
	  (progn
	    (etach-debug-msg (concat "unrecognized MIME 1.0 header: [" field-name "]"))
	    (message "unrecognized MIME 1.0 header: [%s]" field-name))))))
    (goto-char mime-header-end))
  )

(defun etach-mime-part-is-multipart-alternative (content-type-body)
  "Return t if this type is multipart/alternative, nil otherwise."
  (string-match "^[^;]*multipart/alternative" content-type-body))

(defun etach-mime-part-is-multipart (content-type-body)
  "Return t if this type is multipart, nil otherwise."
  (string-match "^[^;]*multipart/" content-type-body))

(defun etach-mime-part-is-message (content-type-body)
  "Return t if this type is message, nil otherwise."
  (string-match "^[^;]*message/" content-type-body))

(defun etach-mime-get-boundary-string (content-type-body)
  "Return boundary string from \"Content-Type: multipart; boundary=...\" body."
  (or (string-match "\\<boundary[ \t]*=[ \t]*\"\\([^;]*\\)\"[ \t]*\\(;\\|$\\)" content-type-body)
      (string-match "\\<boundary[ \t]*=[ \t]*\\([^;]*\\)[ \t]*\\(;\\|$\\)" content-type-body))
  (match-string 1 content-type-body))

(defun etach-rewrite-content-headers (T E Disp hbeg)
  "Rewrite content headers after decode."
  (if t
      (save-excursion
	(if (re-search-backward "^Content-Disposition:" hbeg t)
	    (replace-match "X-Former-Content-Disposition:" t))))

  (if (not (string-match "\\<text/plain\\>" T))
      (save-excursion
	(if (re-search-backward "^Content-Type:" hbeg t)
	    (replace-match (concat "Content-Type: text/plain; charset=" etach-default-charset "\nX-Former-Content-Type:") t))))

  (if (not (string-match "\\<7bit\\>" E))
      (save-excursion
	(if (re-search-backward "^Content-Transfer-Encoding:" hbeg t)
	    (replace-match "Content-Transfer-Encoding: 7bit\nX-Former-Content-Transfer-Encoding:" t)))))

(defun etach-mime-decode (rbeg rend T E I Desc Disp hbeg depth discard)
  "Mime-decode the region rbeg to rend based on \"content-\" headers, starting at hbeg.
This function does more than just decode; it is also responsible for committing the actual
detachment(s)."
  (etach-debug-msg (concat "etach-mime-decode called with T=\'" T "\', E=\'" E "\', depth=" (number-to-string depth)))
  (cond
   ((and (or (and (string-match "\\<text/plain\\>" T)
		  (not etach-write-text-files))
	     (and (string-match "\\<text/html\\>" T)
		  (= discard 0)
		  (not etach-write-html-files)))
	 (not (string-match "\\<name=" T))
	 (not (string-match "\\<filename=" Disp)))
    (progn
      (setq buffer-read-only nil)
      (cond
       ((string-match "\\<quoted-printable\\>" E)
	(progn
	  (etach-debug-msg (concat "quoted-printable-decoding MIME type \'" T "\'..."))
	  (message "quoted-printable-decoding MIME type \'%s\'..." T)
	  (save-excursion
	    (save-restriction
	      (narrow-to-region rbeg rend)
	      (if etach-use-mimencode
		  (shell-command-on-region (point-min) (point-max) "mimencode -u -q" t t)
		(etach-rmail-decode-quoted-printable (point-min) (point-max)))
	      (decode-coding-region (point-min) (point-max) 'undecided)
	      (if (string-match "\\<text/html\\>" T)
		  (progn
		    (etach-debug-msg "converting quoted-printable-decoded html to plain text")
		    (message "converting quoted-printable-decoded html to plain text")
		    (apply 'call-process-region (point-min) (point-max)
			   etach-unhtml-command t t nil etach-unhtml-args)))
	      (goto-char (point-max))
	      (if (/= (preceding-char) ?\n)
		  (insert "\n"))
	      (if etach-fill-decoded-plain-text
		  (fill-region (point-min) (point-max)))
	      (if etach-clean-decoded-plain-text
		  (subst-char-in-region (point-min) (point-max) ?\r ?\n))))
	  ))
       ((string-match "\\<base64\\>" E)
	(progn
	  (etach-debug-msg (concat "base64-decoding MIME type \'" T "\'..."))
	  (message "base64-decoding MIME type \'%s\'..." T)
	  (save-excursion
	    (save-restriction
	      (goto-char rbeg)
	      (if (re-search-forward "[^A-Za-z0-9+/=\n]\\|[\n][\n]" rend t)
		  (progn
		    (backward-char)
		    (etach-debug-msg (concat "limiting region here, non-base64 char or blank line found"))
		    (narrow-to-region rbeg (point)))
		(narrow-to-region rbeg rend))
	      (if etach-use-mimencode
		  (shell-command-on-region (point-min) (point-max) "mimencode -u" t t)
		(base64-decode-region (point-min) (point-max)))
	      (decode-coding-region (point-min) (point-max) 'undecided)
	      (if (string-match "\\<text/html\\>" T)
		  (progn
		    (etach-debug-msg "converting base64-decoded html to plain text")
		    (message "converting base64-decoded html to plain text")
		    (apply 'call-process-region (point-min) (point-max)
			   etach-unhtml-command t t nil etach-unhtml-args)))
	      (goto-char (point-max))
	      (if (/= (preceding-char) ?\n)
		  (insert "\n"))
	      (if etach-fill-decoded-plain-text
		  (fill-region (point-min) (point-max)))
	      (if etach-clean-decoded-plain-text
		  (subst-char-in-region (point-min) (point-max) ?\r ?\n))))
	  ))
       (t
	(progn
	  (etach-debug-msg (concat "null-decoding MIME type \'" T "\' encoding \'" E "\'"))
	  (message "null-decoding MIME type \'%s\' encoding \'%s\'" T E)
	  (save-excursion
	    (save-restriction
	      (narrow-to-region rbeg rend)
	      (decode-coding-region (point-min) (point-max) 'undecided)
	      (if (string-match "\\<text/html\\>" T)
		  (progn
		    (etach-debug-msg "converting null-decoded html to plain text")
		    (message "converting null-decoded html to plain text")
		    (apply 'call-process-region (point-min) (point-max)
			   etach-unhtml-command t t nil etach-unhtml-args)))
	      (goto-char (point-max))
	      (if (/= (preceding-char) ?\n)
		  (insert "\n"))
	      (if etach-fill-decoded-plain-text
		  (fill-region (point-min) (point-max)))
	      (if etach-clean-decoded-plain-text
		  (subst-char-in-region (point-min) (point-max) ?\r ?\n))))
	  )))
      ))

   (t
    (let ((F nil) ; file name
	  (Fcopy nil) ; copy of file name
	  (Ff nil) ; file name sans extension
	  (Fe nil) ; file name extension (including the dot)
	  (Ftag 1) ; file tag (in case FfFe exists)
	  (require-final-newline nil)
	  (insert-default-directory t)
	  (default-directory default-directory)
	  (skip-this-file nil)
	  (my-write-error nil)
	  (stuff-to-yank nil))
      ;; discard directory (path) portion of file names;
      ;; notice that the leading dots on file names are discarded, too:
      (if (or (string-match "\\<name=\"\\([^;]*/\\)*\\.*\\([^;]*\\)\""               T)
	      (string-match   "\\<name=\\([^;]*/\\)*\\.*\\([^;]*\\)\\([ \t;]\\|$\\)" T))
	  (setq F (match-string 2 T))
	(if (or (string-match "\\<filename=\"\\([^;]*/\\)*\\.*\\([^;]*\\)\"" Disp)
		(string-match   "\\<filename=\\([^;]*/\\)*\\.*\\([^;]*\\)\\([ \t;]\\|$\\)" Disp))
	    (setq F (match-string 2 Disp))
	  (if etach-prompt-me-for-file-names
	      (setq F "FILE")
	    (setq F (or (etach-who-is-this-from) (format-time-string "%Y-%m-%d"))))))
      (etach-debug-msg (concat "raw file name: [" F "]"))
      (if (string-match "^[ \t]*$" (file-name-nondirectory F))
	  (setq F "FILE"))
      (etach-safe-clean F) ; get rid of funny characters
      (if (not (string-match "\\.[a-zA-Z0-9]+$" F))
	  (let ((major-type)
		(minor-type))
	    (if (string-match "^\\(.*\\)/\\([^ \t;]*\\)" T)
		(progn
		  (setq major-type (match-string 1 T))
		  (setq minor-type (match-string 2 T))
		  ;; add a file name extension based on Content-Type:
		  (if (rassoc (list (concat major-type "/" minor-type)) etach-mime-type-alist)
		      (setq F (concat F
				      "."
				      (car (rassoc
					    (list (concat major-type "/" minor-type))
					    etach-mime-type-alist)))))))))
      (if (string-match "^\\(.*\\)\\(\\.[a-zA-Z0-9]+\\)$" F)
	  (progn
	    (setq Ff (match-string 1 F))
	    (setq Fe (match-string 2 F)))
	(setq Ff F)
	(setq Fe ""))
      (setq Fcopy (concat Ff Fe))
      (let ((detach-dir (if (= discard 0)
			    etach-detachment-default-directory
			  etach-detachment-discard-directory)))
	(setq default-directory
	      (concat
	       (if (or (string-match "^/" detach-dir)
		       (string-match "^[a-z]:/" detach-dir))
		   ""
		 default-directory)
	       detach-dir
	       (if (string-match "/$" detach-dir)
		   ""
		 "/"))))
      (etach-debug-msg (concat "default directory set to: " default-directory))
      (if (not (file-exists-p default-directory))
	  (progn
	    (etach-debug-msg (concat "creating directory: " default-directory))
	    (make-directory default-directory t)))
      (if (file-exists-p (concat Ff Fe))
	  (progn
	    (while (and (<= Ftag 9999) (file-exists-p (concat Ff (format "_%04d" Ftag) Fe)))
	      (setq Ftag (1+ Ftag)))
	    (setq Ff (concat Ff (format "_%04d" Ftag)))))
      (if (> Ftag 9999)
	  (setq F Fcopy)
	(setq F (concat Ff Fe)))
      (setq Fcopy F)
      (etach-debug-msg (concat "offered for detachment: " F))
      (if etach-prompt-me-for-file-names
	  (save-excursion
	    (goto-char hbeg) ; do this just to make visual connection between part and name
	    (setq F
		  (condition-case err
		      (read-file-name "Save as: "
				      default-directory
				      nil
				      nil
				      Fcopy)
		    ((quit error)
		     (setq skip-this-file t)
		     (etach-debug-msg (concat "skipping " Fcopy ": " (error-message-string err)))
		     (message "skipping %s: %s" Fcopy (error-message-string err))
		     Fcopy)))))
      (if (string-match "^[ \t]*$" (file-name-nondirectory F))
	  (progn
	    (setq F Fcopy)
	    (etach-debug-msg (concat "cannot accept blank filename, using " F " instead"))
	    (message "cannot accept blank filename, using %s instead" F)
	    ))
      (setq buffer-read-only nil)
      (if skip-this-file
	  nil
	;; here's where the action is:
	(setq F (expand-file-name F))
	(etach-debug-msg (concat "detaching: " F))

	(save-restriction
	  (if (string-match "\\<base64\\>" E)
	      (save-excursion
		(goto-char rbeg)
		(if (re-search-forward "[^A-Za-z0-9+/=\n]\\|[\n][\n]" rend t)
		    (progn
		      (backward-char)
		      (etach-debug-msg (concat "limiting region here, non-base64 char or blank line found"))
		      (narrow-to-region rbeg (point)))
		  (narrow-to-region rbeg rend)))
	    (narrow-to-region rbeg rend))

	  (setq stuff-to-yank (buffer-substring (point-min) (point-max)))
	  (kill-region (point-min) (point-max))
	  ;; this save-excursion is necessary if using write-file, since write-file
	  ;; visits the buffer after writing
	  (save-excursion
	    (let ((buffer (get-buffer-create " *temp*")))
	      (set-buffer buffer)
	      (unwind-protect
		  (progn
		    (insert stuff-to-yank) ; use this instead of (yank) to avoid setting mark
		    (cond
		     ((string-match "\\<base64\\>" E)
		      (progn
			(etach-debug-msg (concat "base64-decoding MIME type \'" T "\'..."))
			(message "base64-decoding MIME type \'%s\'..." T)
			(if etach-use-mimencode
			    (let ((inhibit-eol-conversion t))
			      (shell-command-on-region (point-min) (point-max) "mimencode -u" t t))
			  (base64-decode-region (point-min) (point-max)))))
		     ((string-match "\\<quoted-printable\\>" E)
		      (progn
			(etach-debug-msg (concat "quoted-printable-decoding MIME type \'" T "\'..."))
			(message "quoted-printable-decoding MIME type \'%s\'..." T)
			(if etach-use-mimencode
			    (let ((inhibit-eol-conversion t))
			      (shell-command-on-region (point-min) (point-max) "mimencode -u -q" t t))
			  (etach-rmail-decode-quoted-printable (point-min) (point-max)))))
		     (t
		      (progn
			(etach-debug-msg (concat "leaving as-is MIME type \'" T "\' encoding \'" E "\'"))
			(message "leaving as-is MIME type \'%s\' encoding \'%s\'" T E))))

		    (condition-case err
			(let ((jka-compr-compression-info-list nil)
			      (coding-system-for-write 'no-conversion))
			  (if (or (string-match "^[0-9][.]" emacs-version)
				  (string-match "^1[0-9][.]" emacs-version)
				  (string-match "^20[.][0-2][.]" emacs-version))
			      (write-region (point-min) (point-max) F nil nil nil)
			    (write-region (point-min) (point-max) F nil nil nil t)))
		      ((quit error)
		       (setq my-write-error t)
		       (set-buffer-modified-p nil)
		       (etach-debug-msg (concat "un-detaching: " (error-message-string err)))
		       (message "un-detaching: %s" (error-message-string err))
		       (sit-for 1)
		       )))
		(kill-buffer buffer))))) ; end save-restriction

	(if my-write-error
	    (progn
	      (etach-debug-msg (concat "restoring MIME attachment due to error"))
	      (insert stuff-to-yank))
	  (if etach-restore-attachments-after-detach
	      (progn
		(etach-debug-msg (concat "restoring MIME attachment per user preference"))
		(save-excursion
		  (if (re-search-backward "^[ \t]*$" hbeg t)
		      (replace-match (concat "X-Detachment: ["
					     etach-detached-file-label-separator-string
					     "file:"
					     etach-detached-file-label-separator-string
					     F
					     etach-detached-file-label-separator-string
					     "]\n"))))
		(insert stuff-to-yank))
	    (insert "[" etach-detached-file-label-separator-string "file:" etach-detached-file-label-separator-string F etach-detached-file-label-separator-string "]\n")
	    ))
	) ; end of stuff to do if skip-this-file is nil
      )))

  (etach-rewrite-content-headers T E Disp hbeg)
  (etach-mime-decode-cleanup depth T E Disp)
  (setq buffer-read-only t)
  (etach-debug-msg (concat "exiting etach-mime-decode with default directory: " default-directory)))

(defun etach-mime-detach (bboundary depth discard)
  "Detach the encoded attachments from the MIME part or message starting at point."
  (etach-debug-msg (concat "etach-mime-detach called with bboundary [" bboundary "] depth " (number-to-string depth) " discard " (number-to-string discard)))
  (let ((etach-content-type (concat "text/plain; charset=" etach-default-charset))
	(etach-content-transfer-encoding "7bit")
	(etach-content-id "")
	(etach-content-description "")
	(etach-content-disposition "")
	(hbeg (point))
	(hend (point))
	(header-chars "[\]!\"#\$%&'()\*\+,\./0-9;<=>\?@A-Z_^\[`a-z{|}~-]")) ; ascii 33-126 except 58
    ;; advance to start of first header candidate
    (save-excursion
      (re-search-forward "^[ \t]*$") ; the Content- lines can be absent, but there should always be a blank line
      (beginning-of-line)
      (setq hend (point)))
    (beginning-of-line)
    ;; we need the following in case the bboundary looks like a header
    ;; (e.g., non-compliant sender using colon in MIME separator):
    (if (looking-at (regexp-quote bboundary))
	(forward-line))
    (re-search-forward (concat "^" header-chars "+:") hend t)
    (beginning-of-line)
    (etach-debug-msg (concat "etach-mime-detach: header lines begin here"))
    (setq hbeg (point))
    ;; get headers
    (etach-mime-get-content-headers)
    (beginning-of-line)
    ;; advance to first line after separator
    (forward-line)
    (cond

     ((etach-mime-part-is-multipart etach-content-type)
      (let* ((b (etach-mime-get-boundary-string etach-content-type))
	     (bb (concat "--" b)))
	(etach-debug-msg (concat "etach-mime-detach processing (multipart): " etach-content-type))
	(re-search-forward (regexp-quote bb) nil t)
	(beginning-of-line)
	(while (not (looking-at (regexp-quote (concat bb "--"))))
	  (if (etach-mime-part-is-multipart-alternative etach-content-type)
	      (etach-mime-detach bb (+ depth 1) 1) ; always discard alternatives
	    (etach-mime-detach bb (+ depth 1) discard)))
	; we should be at a boundary, but in case there are blank lines we better make sure:
	(re-search-forward (if (string= bboundary "\\'") "\\'" (regexp-quote bboundary)))
	(beginning-of-line)))

     ((etach-mime-part-is-message etach-content-type)
      (progn
	(etach-debug-msg (concat "etach-mime-detach processing (message): " etach-content-type))
	(etach-mime-detach bboundary (+ depth 1) discard)
	; we should be at a boundary, but in case there are blank lines we better make sure:
	(re-search-forward (if (string= bboundary "\\'") "\\'" (regexp-quote bboundary)))
	(beginning-of-line)))

     (t
      (let ((ebeg (point))
	    (eend (point)))
	(etach-debug-msg (concat "etach-mime-detach processing: " etach-content-type))
	(re-search-forward (if (string= bboundary "\\'") "\\'" (regexp-quote bboundary)))
	(beginning-of-line)
	(setq eend (point))
	(etach-mime-decode ebeg eend
			   etach-content-type
			   etach-content-transfer-encoding
			   etach-content-id
			   etach-content-description
			   etach-content-disposition
			   hbeg
			   depth
			   discard)
	; we should be at a boundary, but in case there are blank lines we better make sure:
	(re-search-forward (if (string= bboundary "\\'") "\\'" (regexp-quote bboundary)))
	(beginning-of-line)
	))

     )))

(defun etach-get-babyl-header ()
  "Return the Babyl header as a string."
  (set-marker (aref rmail-message-vector (1+ rmail-current-message))
	      (point-max))
  (if (boundp 'rmail-summary-vector)
      (aset rmail-summary-vector (1- rmail-current-message) nil))
  (save-excursion
    (rmail-widen-to-current-msgbeg
     (function (lambda ()
		 (if (search-forward "*** EOOH ***\n" nil t)
		     (etach-debug-msg "etach-get-babyl-header: end of babyl header found")
		   (etach-debug-msg "etach-get-babyl-header: end of babyl header NOT found"))
		 (buffer-substring (point-min) (point)))))))

(defun etach-mime-decode-cleanup (leave-babyl-mime-headers-alone T E Disp) ; see rmail-cease-edit in rmailedit.el
  "Clean up the RMAIL structure."
  (etach-debug-msg (concat "etach-mime-decode-cleanup called with parameter " (number-to-string leave-babyl-mime-headers-alone)))
  (save-excursion
    (goto-char (point-max))
    (if (/= (preceding-char) ?\n)
	(insert "\n"))
    (set-marker (aref rmail-message-vector (1+ rmail-current-message))
		(point))
    (if (boundp 'rmail-summary-vector)
	(aset rmail-summary-vector (1- rmail-current-message) nil))
    (save-excursion
      (rmail-widen-to-current-msgbeg
       (function (lambda ()
		   (if (= leave-babyl-mime-headers-alone 0)
		       (progn
			 (save-excursion
			   (if (search-forward "*** EOOH ***" nil t)
			       (etach-debug-msg "etach-mime-decode-cleanup: end of babyl header found")
			     (etach-debug-msg "etach-mime-decode-cleanup: end of babyl header NOT found"))
			   (etach-rewrite-content-headers T E Disp (point-min)))
			 (if (boundp 'rmail-summary-vector)
			     (progn
			       (forward-line 2)
			       (if (looking-at "Summary-line: ")
				   (delete-region (point)
						  (progn (forward-line 1)
							 (point))))))))))))
    (rmail-show-message)))

(defun etach-downcase (s)
  "Take string as argument, return lowercase version."
  (let ((x 65))
    (while (<= x 90)
      (etach-subst-char-in-string x (+ x 32) s t)
      (setq x (+ 1 x)))))

(defun etach-safe-clean (f)
  "Clean up a string to make it suitable as a safe one-word file name."
  (let ((x 0))
    (while (<= x 44)
      (etach-subst-char-in-string x ?_ f t)
      (setq x (+ 1 x)))
    (setq x 58)
    (while (<= x 64)
      (etach-subst-char-in-string x ?_ f t)
      (setq x (+ 1 x)))
    (setq x 91)
    (while (<= x 94)
      (etach-subst-char-in-string x ?_ f t)
      (setq x (+ 1 x)))
    (setq x 96)
    (while (<= x 96)
      (etach-subst-char-in-string x ?_ f t)
      (setq x (+ 1 x)))
    (setq x 123)
    (while (<= x 255)
      (etach-subst-char-in-string x ?_ f t)
      (setq x (+ 1 x)))))

(defun etach-debug-msg (msg-string)
  "Write a debug message."
  (if etach-debug
      (let ((debug-msg
	     (concat
	      (buffer-name)
	      " (line "
	      (number-to-string (+ 1 (count-lines (point-min) (point))))
	      " ["
	      (if (char-after (1- (point)))

		  (if (= (preceding-char) ?\n)
		      "\\n"
		    (char-to-string (char-after (1- (point))))))

	      "/"
	      (if (char-after (point))
		  (if (= (following-char) ?\n)
		      "\\n"
		    (char-to-string (char-after (point)))))
	      "]): " msg-string "\n")))
	(get-buffer-create "etach-debug")
	(save-excursion
	  (set-buffer "etach-debug")
	  (goto-char (point-max))
	  (insert debug-msg)))))

;;; The following are local copies of functions that may be absent from
;;; some Emacs versions or installations (names have "etach-" prepended).

;;; The following is nicked from sendmail.el (and modified in form but
;;; not function):

(defun etach-mail-header-end ()
  "Return the buffer location of the end of headers, as a number."
   (save-restriction
     (widen)
     (save-excursion
       (goto-char (point-min))
       (while (looking-at "^[^: \n]+:\\|^[ \t]")
	 (forward-line 1))
       (point))))

;;; The following is taken from subr.el:

(defun etach-subst-char-in-string (fromchar tochar string &optional inplace)
  "Replace FROMCHAR with TOCHAR in STRING each time it occurs.
Unless optional argument INPLACE is non-nil, return a new string."
  (let ((i (length string))
	(newstr (if inplace string (copy-sequence string))))
    (while (> i 0)
      (setq i (1- i))
      (if (eq (aref newstr i) fromchar)
	  (aset newstr i tochar)))
    newstr))

;;; The following are taken from rmail.el:

(defun etach-rmail-msg-is-pruned ()
  (rmail-maybe-set-message-counters)
  (save-restriction
    (narrow-to-region (rmail-msgbeg rmail-current-message) (point-max))
    (save-excursion
      (goto-char (point-min))
      (forward-line 1)
      (= (following-char) ?1))))

(defun etach-rmail-decode-quoted-printable (from to)
  "Decode Quoted-Printable in the region between FROM and TO."
  (interactive "r")
  (goto-char from)
  (or (markerp to)
      (setq to (copy-marker to)))
  (while (search-forward "=" to t)
    (cond ((eq (following-char) ?\n)
	   (delete-char -1)
	   (delete-char 1))
	  ((looking-at "[0-9A-F][0-9A-F]")
	   (let ((byte (etach-rmail-hex-string-to-integer
			(buffer-substring (point) (+ 2 (point))))))
	     (delete-region (1- (point)) (+ 2 (point)))
	     (insert byte)))
	  ((looking-at "=")
	   (delete-char 1))
	  (t
	   (message "Malformed MIME quoted-printable message")))))

(defun etach-rmail-hex-string-to-integer (hex-string)
  "Return decimal integer for HEX-STRING."
  (let ((hex-num 0)
	(index 0))
    (while (< index (length hex-string))
      (setq hex-num (+ (* hex-num 16)
		       (etach-rmail-hex-char-to-integer (aref hex-string index))))
      (setq index (1+ index)))
    hex-num))

(defun etach-rmail-hex-char-to-integer (character)
  "Return CHARACTER's value interpreted as a hex digit."
  (if (and (>= character ?0) (<= character ?9))
      (- character ?0)
    (let ((ch (logior character 32)))
      (if (and (>= ch ?a) (<= ch ?f))
	  (- ch (- ?a 10))
	(error "Invalid hex digit `%c'" ch)))))

;;; let (provide 'etach) be the last line:

(provide 'etach)

;;; etach.el ends here
============================================================

Re: Sending attachments

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> Is there any facility that can be used in Mail mode
> to put attachments into the message?

Use message-mode.

-Miles

-- 
Cannon, n. An instrument employed in the rectification of national boundaries.

Re: Sending attachments

[Robert J. Chassell]

Richard Stallman <rms@gnu.org> asked:

    > Is there any facility that can be used in Mail mode
    > to put attachments into the message?

Marc Andreessen wrote Emacs Lisp to add gif, jpeg, postscript,
raw-binary, and raw-nonbinary in 1992 in MIME and in 1993-95 Masanobu
UMEDA wrote Emacs Lisp to edit MIME text messages.

In 1996, Ray Moody wrote Emacs Lisp to read MIME.

As far as I know, none were part of GNU Emacs.  I can send the libraries
if wanted.

-- 
    Robert J. Chassell                          
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Sending attachments

[Miles Bader]

bob@rattlesnake.com (Robert J. Chassell) writes:
> Marc Andreessen wrote Emacs Lisp to add gif, jpeg, postscript,
> raw-binary, and raw-nonbinary in 1992 in MIME and in 1993-95 Masanobu
> UMEDA wrote Emacs Lisp to edit MIME text messages.
> In 1996, Ray Moody wrote Emacs Lisp to read MIME.
>
> As far as I know, none were part of GNU Emacs.  I can send the libraries
> if wanted.

Emacs _already_ has mime libraries; they seem to work quite well.
Message mode (and Gnus) already uses them.  Message mode is more or less
a superset of mail-mode.

It seems fairly obvious that the best solutions are:

  1. In the long-term, merge mail-mode and message-mode.  It's silly
     that there are two modes.  AIUI, this is already an Emacs goal.

  2. In the short-term, just use message mode when you want to send
     mime mail.

No?

-Miles

-- 
Vote, v. The instrument and symbol of a freeman's power to make a fool of
himself and a wreck of his country.

Re: Sending attachments

[Jason Rumney]

Miles Bader wrote:
>   1. In the long-term, merge mail-mode and message-mode.  It's silly
>      that there are two modes.  AIUI, this is already an Emacs goal.
>   

What features of mail-mode are missing from message-mode?

Re: Sending attachments

[Reiner Steib]

On Thu, Jul 02 2009, Miles Bader wrote:

> Emacs _already_ has mime libraries; they seem to work quite well.

,----[ (info "(emacs-mime)Top") ]
| Emacs MIME
| **********
| 
| This manual documents the libraries used to compose and display MIME
| messages.
`----

For composing MIME message, there's the `mml' library (see
lisp/gnus/mml*.el) and (info "(emacs-mime)Composing").

> Message mode (and Gnus) already uses them.

MH-E also uses it.

> Message mode is more or less a superset of mail-mode.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sending attachments

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

>   1. In the long-term, merge mail-mode and message-mode.  It's silly
>      that there are two modes.  AIUI, this is already an Emacs goal.

Would anyone like to work on this?

The first step is to check for incompatibilities and missing features in
message-mode.  Currently, message-mode recognizes many mail-mode
variables, such as `sendmail-program', and do the right thing in
response.  Someone needs to go through all the sendmail.el variables and
make sure they are all handled properly in message-mode.  Once that is
done, we can start to migrate rmail, the bug reporter, and any other
places that use mail-mode to message-mode.

Re: Sending attachments

[Richard Stallman]

    > Is there any facility that can be used in Mail mode
    > to put attachments into the message?

    Use message-mode.

There was no reason to add Message mode to Emacs at all.
Someone decided to write a duplicate mode instead of
improving the one we had, and snuck it into Emacs without
submitting the decision to discussion.

Perhaps I will merge the relevant code from Message mode
into Mail mode.

Re: Sending attachments

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Use message-mode.
>
> There was no reason to add Message mode to Emacs at all.
> Someone decided to write a duplicate mode instead of
> improving the one we had, and snuck it into Emacs without
> submitting the decision to discussion.

I agree, there shouldn't be this duplication, and we should try to fix
it -- but since message-mode has much more functionality (which is
widely used and important), we can't just get rid of message-mode.
Thus we should merge the two modes.

Since message-mode is mostly a superset of mail-mode, then
_technically_ it seems pretty likely that the safest and quickest way
to accomplish this merge would be to adopt message-mode (after fixing
any problems with message-mode, and with whatever other changes are
necessary to help mail-mode users).

I realize that the whole mess annoys you (me too), and that to some
degree it's message-mode that's "at fault" -- but we also need to
think about the technical issues, developer time, and our users.

Message-mode wasn't created or merged maliciously.  Let's just let
the past be the past, and try to do the best thing for Emacs and its
users, and merge the two modes into one.  If the name "mail-mode" is
preferred, then message-mode can be renamed (with appropriate
compatibility hooks for existing users of message-mode).

Do you have any technical (UI/interfaces/functionality/code-quality/etc)
objections to message-mode?  Is the code ugly?  Does it not work well
with rmail?  Do you not like the name?

Thanks,

-Miles

-- 
`Life is a boundless sea of bitterness'

message-mode / mail-mode (was: Sending attachments)

[Teemu Likonen]

On 2009-07-03 11:37 (+0900), Miles Bader wrote:

> Do you have any technical (UI/interfaces/functionality/code-quality/etc)
> objections to message-mode?  Is the code ugly?  Does it not work well
> with rmail?  Do you not like the name?

You asked Richard but I'll voice my opinion or point anyway. I mostly
use only Gnus and message-mode but there is (at least) one thing in
mail-mode which is not very well supported in message-mode: editing raw
mbox or mail files.

Sometimes I need to edit raw mail/mbox files manually. Similar situation
is composing a mail with a mail user agent like Mutt [1]. In
message-mode there's command M-q (fill-paragraph) which works
differently when cursor is in message's header and when it's on
message's body. There's also C-a which is context sensitive, probably
there are others.

Context-sensitive commands are good but in message-mode they seem to
require that the "--text follows this line--" separator line exists.
This fact pretty much ties message-mode to only Emacs internal mail/news
applications. If header and body is separated only by an empty line
(which is the case with raw mail files) then message-mode's
context-sensitive commands like M-q seem to always operate in "header
mode". This makes M-q quite useless as it indents the second line of a
paragraph with a TAB character.

I wish there was just a simple mode for editing raw mail files. Just
highlighting messages' headers and recognizing ">" as a comment char
would suffice. Functions like sending mail don't make much sense with
raw mail files. Currently mail-mode is a bit better on this area,
perhaps because it's not too clever, I don't know. With Gnus
message-mode is much better.


---------------
 1. http://www.mutt.org/

Re: message-mode / mail-mode

[Miles Bader]

Teemu Likonen <tlikonen@iki.fi> writes:
> Sometimes I need to edit raw mail/mbox files manually. Similar situation
> is composing a mail with a mail user agent like Mutt [1]. In
> message-mode there's command M-q (fill-paragraph) which works
> differently when cursor is in message's header and when it's on
> message's body. There's also C-a which is context sensitive, probably
> there are others.
>
> Context-sensitive commands are good but in message-mode they seem to
> require that the "--text follows this line--" separator line exists.
> This fact pretty much ties message-mode to only Emacs internal mail/news
> applications. If header and body is separated only by an empty line
> (which is the case with raw mail files) then message-mode's
> context-sensitive commands like M-q seem to always operate in "header
> mode". This makes M-q quite useless as it indents the second line of a
> paragraph with a TAB character.

You should set the variable `mail-header-separator' to ""; message-mode
also pays attention to this variable.

[I do this, and it makes filling in both mail-mode and message-mode "do
the right thing" for standard mail files.]

-Miles

-- 
"... The revolution will be no re-run brothers; The revolution will be live."

Re: message-mode / mail-mode

[Miles Bader]

BTW, I use the following little hack for editing mutt files:

   (defun setup-mutt-buffer ()
     (require 'sendmail)
     ;; be like mail-mode, but without the special keybindings                     
     (mail-mode)
     (set (make-local-variable 'mail-header-separator) "")
     (use-local-map nil)
     (change-signature))

   (add-to-list 'auto-mode-alist '("\\<mutt-" . setup-mutt-buffer))

[I suppose it might more properly be done using define-derived-mode or
something, but...]

-Miles

-- 
White, adj. and n. Black.

Re: message-mode / mail-mode

[Teemu Likonen]

On 2009-07-03 17:43 (+0900), Miles Bader wrote:

> You should set the variable `mail-header-separator' to "";
> message-mode also pays attention to this variable.
>
> [I do this, and it makes filling in both mail-mode and message-mode
> "do the right thing" for standard mail files.]

Ah, thanks! Then I don't have use for mail-mode anymore. Message-mode
doesn't recognize headers and bodies in multi-message mbox files but I
rarely need to load mbox files directly to my editor so this is not
really important.

Re: Sending attachments

[Richard Stallman]

I object strenuously to the idea of replacing the very simple Mail
mode with something complex from Gnus.

Re: Sending attachments

[Alfred M. Szmidt]

   The first step is to check for incompatibilities and missing
   features in message-mode.  Currently, message-mode recognizes many
   mail-mode variables, such as `sendmail-program', and do the right
   thing in response.  Someone needs to go through all the sendmail.el
   variables and make sure they are all handled properly in
   message-mode.  Once that is done, we can start to migrate rmail,
   the bug reporter, and any other places that use mail-mode to
   message-mode.

That is much  unneeded work, the only thing  that uses message-mode is
gnus.  It would be much easier to add etach, or similar, to mail-mode,
and make gnus use mail-mode which is the default mode for sending mail
in Emacs.

Re: Sending attachments

[Alfred M. Szmidt]

   I object strenuously to the idea of replacing the very simple Mail
   mode with something complex from Gnus.

As a user of mail-mode, I agree fully.

Adding something like etach would be the right solution.

Re: Sending attachments

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> I object strenuously to the idea of replacing the very simple Mail
> mode with something complex from Gnus.

It's a question of necessary complexity.  You pointed out that it's
ludicrous to have two modes that perform similar functions.  Message
mode is more complex, as it provides more features (e.g. support for
attachments).  Any merger cannot very well remove existing features, so
this additional complexity will not go away.

Another possibility is to refactor message-mode into a simple core,
which can be merged with mail-mode, plus an "xtras" library that can be
loaded on demand.  That would be a much larger job.

Re: Sending attachments

[Richard Stallman]

    > I object strenuously to the idea of replacing the very simple Mail
    > mode with something complex from Gnus.

    It's a question of necessary complexity.

I don't think so.  Look at all the libraries message.el loads.


    (require 'hashcash)
    (require 'canlock)
    (require 'mailheader)
    (require 'gmm-utils)
    (require 'nnheader)

      That loads
	(require 'mail-utils)
	(require 'mm-util)
	(require 'gnus-util)

    ;; This is apparently necessary even though things are autoloaded.
    ;; Because we dynamically bind mail-abbrev-mode-regexp, we'd better
    ;; require mailabbrev here.
    (if (featurep 'xemacs)
	(require 'mail-abbrevs)
      (require 'mailabbrev))
    (require 'mail-parse)
    (require 'mml)
    (require 'rfc822)
    (require 'ecomplete)

I don't want to replace the simple sendmail.el with this tremendous
pile of complexity.

message.el is also 8000 lines long, where sendmail.el is under 2000
lines.  I expect that sending attachments won't require more than 200
lines.

Re: Sending attachments

[Richard Stallman]

    For composing MIME message, there's the `mml' library (see
    lisp/gnus/mml*.el) and (info "(emacs-mime)Composing").

mml.el says

    ;;; mml.el --- A package for parsing and validating MML documents

It does not say that it can be used for composing them.
Is the comment erroneous?

According to the documentation in "(emacs-mime)Composing",
one must put certain text in the buffer
which then gets converted to Mime parts,

Maybe that is convenient for some cases, but what I would like
is a simpler command that just attaches a file.

Has anyone written such a thing?

Bob Chassell wrote:

    Marc Andreessen wrote Emacs Lisp to add gif, jpeg, postscript,
    raw-binary, and raw-nonbinary in 1992 in MIME and in 1993-95 Masanobu
    UMEDA wrote Emacs Lisp to edit MIME text messages.

Does any of that do the simple thing I would like?

Re: Sending attachments

[Robert J. Chassell]

mime-compose-1.5.el is 52576 bytes and 1284 lines long including a
commented out patch for the Sun Record program demo.  Without the patch,
mime-compose-1.5.el is 49428 bytes and 1182 lines long.

-- 
    Robert J. Chassell                          
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Sending attachments

[Teemu Likonen]

On 2009-07-03 18:52 (-0400), Richard Stallman wrote:

> I don't want to replace the simple sendmail.el with this tremendous
> pile of complexity.

I have an idea: Let's have two different modes, a simple mode called
mail-mode and a complex mode named message-mode which has more features.
People who like simplicity can use mail-mode and people who need more
features can use message-mode. How does that sound? :-)

> message.el is also 8000 lines long, where sendmail.el is under 2000
> lines.  I expect that sending attachments won't require more than 200
> lines.

I think it's clear that message-mode contains more features over
mail-mode than just attachments.

A humble request from a user: if some kind of code reordering or merging
of the modes takes place please don't cripple message-mode's current
features too badly.

Re: Sending attachments

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> According to the documentation in "(emacs-mime)Composing",
> one must put certain text in the buffer
> which then gets converted to Mime parts,
>
> Maybe that is convenient for some cases, but what I would like
> is a simpler command that just attaches a file.
>
> Has anyone written such a thing?

C-c RET f runs the command mml-attach-file, which is an interactive
compiled Lisp function in `mml.el'.

It is bound to <menu-bar> <Attachments> <Attach File...>, C-c RET f, C-c
C-a.

(mml-attach-file file &optional type description disposition)

Attach a file to the outgoing MIME message.
The file is not inserted or encoded until you send the message with
`C-c C-c' or `C-c C-s'.

file is the name of the file to attach.  type is its
content-type, a string of the form "type/subtype".  description
is a one-line description of the attachment.  The disposition
specifies how the attachment is intended to be displayed.  It can
be either "inline" (displayed automatically within the message
body) or "attachment" (separate from the body).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Sending attachments

[Chad Brown]

On Jul 3, 2009, at 7:21 AM, Alfred M. Szmidt wrote:

> That is much  unneeded work, the only thing  that uses message-mode is
> gnus.

MH-e uses message-mode, as do a few third-party elisp mail packages  
(or they did when I last looked, a few years ago).  For better or  
worse, MIME handling is seen as necessary in most elisp mail packages,  
and is tremendously fiddly, which leaves most people relying on the  
gnus-ish code.

Sadly, I'm not in a good position to offer to help with either  
proposal, but I doubt that you can make mail-mode usable for the mime- 
handling features that multiple packages want from message-mode  
without significant (mostly duplicated) effort.

*Chad

Re: Sending attachments

[Eli Zaretskii]

> From: Chad Brown <yandros@MIT.EDU>
> Date: Sat, 4 Jul 2009 08:33:56 -0700
> 
> I doubt that you can make mail-mode usable for the mime- handling
> features that multiple packages want from message-mode without
> significant (mostly duplicated) effort.

Could you please post a list of the features you had in mind, so that
the effort could be estimated?

Just looking at email messages with MIME attachments, it looks like
each attachment is just a fancy header line and a body encoded by
either base64 or quoted-printable.  Implementing a simple command that
asks for a file name and then encodes it and puts the result in the
*mail* buffer sounds easy enough, so I'm sure I'm missing something.

Re: Sending attachments

[Leo]

On 2009-07-04 16:11 +0100, Teemu Likonen wrote:
> I have an idea: Let's have two different modes, a simple mode called
> mail-mode and a complex mode named message-mode which has more
> features. People who like simplicity can use mail-mode and people who
> need more features can use message-mode. How does that sound? :-)

There are already a few variants.

,----[ C-h v mail-user-agent RET ]
|   `sendmail-user-agent' -- use the default Emacs Mail package.
|                            See Info node `(emacs)Sending Mail'.
|   `mh-e-user-agent'     -- use the Emacs interface to the MH mail system.
|                            See Info node `(mh-e)'.
|   `message-user-agent'  -- use the Gnus Message package.
|                            See Info node `(message)'.
|   `gnus-user-agent'     -- like `message-user-agent', but with Gnus
|                            paraphernalia, particularly the Gcc: header for
|                            archiving.
`----

I'd prefer the core functionality of both sendmail and message-mode be
merged into a library that offers a default send mail interface and also
a basis for all other MUAs like gnus, mh-e etc. if they need extra stuff
than the default.

-- 
Leo's Emacs uptime: 24 days, 2 hours, 2 minutes, 12 seconds

Re: Sending attachments

[Chad Brown]

On Jul 4, 2009, at 8:53 AM, Eli Zaretskii wrote:

>> From: Chad Brown <yandros@MIT.EDU>
>> Date: Sat, 4 Jul 2009 08:33:56 -0700
>>
>> I doubt that you can make mail-mode usable for the mime- handling
>> features that multiple packages want from message-mode without
>> significant (mostly duplicated) effort.
>
> Could you please post a list of the features you had in mind, so that
> the effort could be estimated?
>
> Just looking at email messages with MIME attachments, it looks like
> each attachment is just a fancy header line and a body encoded by
> either base64 or quoted-printable.  Implementing a simple command that
> asks for a file name and then encodes it and puts the result in the
> *mail* buffer sounds easy enough, so I'm sure I'm missing something.

I'm sorry to say that it's unlikely, but I will see if I can do.  Most  
of my experience with this sort of thing comes from long-ago work on  
MH-e, wherein I found that simple MIME is pretty easy but everything  
turns crazy when you hit multipart/mixed and multipart/alternative.   
If the goal is simply to be able to attach files to messages, then the  
code required is very simple (my long-ago MH-e for doing so was less  
than 15 lines of elisp).  If you want to handle the larger range of  
MIME options, the complication is hard to avoid.

To be more specific about what I was trying to say:   I doubt that  
mail-mode can be made into a replacement for message-mode for things  
like MH-e easily, and I expect the result will duplicate most of  
message mode.  Adding a simple `attach file' to mail-mode is probably  
not very hard at all, but the result won't allow you to drop message- 
mode/mml (it's been long enough that I forget which parts are where).

*chad

Re: Sending attachments

[Richard Stallman]

Etach looks like just what I had in mind.
(The parts that interact with Rmail need updating.)

Re: Sending attachments

[Daniel Pittman]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Chad Brown <yandros@MIT.EDU>
>> Date: Sat, 4 Jul 2009 08:33:56 -0700
>>
>> I doubt that you can make mail-mode usable for the mime- handling
>> features that multiple packages want from message-mode without
>> significant (mostly duplicated) effort.
>
> Could you please post a list of the features you had in mind, so that
> the effort could be estimated?
>
> Just looking at email messages with MIME attachments, it looks like
> each attachment is just a fancy header line and a body encoded by
> either base64 or quoted-printable.  Implementing a simple command that
> asks for a file name and then encodes it and puts the result in the
> *mail* buffer sounds easy enough, so I'm sure I'm missing something.

If you do decide to go the simple path, don't encode anything but text/* MIME
content as Q-P.  Various mailers, especially on Windows, take Q-P as an
instruction to un-Q-P the text, then convert line endings to the platform
format.

This violates the spec, but causes corruption of attachments.  Gnus, for a
while, selected the optimum of Q-P and base64 for size, and I found the above
issue when PDF files selected Q-P and ended up corrupted on Windows.

Regards,
        Daniel

Re: Sending attachments

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> Could you please post a list of the features you had in mind, so that
> the effort could be estimated?

Important things:

  1. Proper handling of non-ascii text. For instance:

      a. Proper encoding of non-ascii headers (using "=?" notation)
      b. Ability to use other transfer encodings besides 8-bit
      c. Ability to automatically choose different character encodings
         depending on the language/context/whatever (e.g., for many
         cases, the "standard" isn't utf-8).

  2. Ability to have both text and binary attachments (both are very
     important), and that these work together with the language support
     in part (1).

  3. The ability to handle the various quirks of sending netnews as
     opposed to email (they're similar in many ways, but obviously not
     all).

     [This presumes that we're looking at _replacing_ the current
     duplicated infrastructure with something new/better -- if the
     non-trivial effort is to be spent to make mail-mode really do email
     correctly, it would be dumb to retain message-mode just for
     handling netnews!]

Of course, message-mode already does all this properly.

My observation has been that there are lot of corner cases, and a lot of
software screws them up.

It would be very very useful to have some of the guys that actually work
on message-mode involved in this conversation, because they probably
know this stuff in much more detail -- I only know what I use as a user,
and have had problems with in the past.

-Miles


p.s. A probably unrelated problem, which made testing a bit annoying:
I can't actually send _any_ mail with mail-mode, because my ISP's
mail-forwarder rejects any messages generated with it!  I'm not quite
sure what extra headers or whatever message-mode adds, but I have no
problems with mail sent using message-mode...

-- 
Friendless, adj. Having no favors to bestow. Destitute of fortune. Addicted to
utterance of truth and common sense.

Re: Sending attachments

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Chad Brown <yandros@MIT.EDU>, Katsumi Yamaoka <yamaoka@jpl.org>,
>     emacs-devel@gnu.org, ding@gnus.org
> Date: Sun, 05 Jul 2009 11:39:59 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > Could you please post a list of the features you had in mind, so that
> > the effort could be estimated?
> 
> Important things:

Thanks.

>   1. Proper handling of non-ascii text. For instance:
> 
>       a. Proper encoding of non-ascii headers (using "=?" notation)
>       b. Ability to use other transfer encodings besides 8-bit
>       c. Ability to automatically choose different character encodings
>          depending on the language/context/whatever (e.g., for many
>          cases, the "standard" isn't utf-8).

I think this is not really related to attaching files.

>   3. The ability to handle the various quirks of sending netnews as
>      opposed to email (they're similar in many ways, but obviously not
>      all).

And this is out of scope for mail-mode, which (AFAIK) does not support
news.

> p.s. A probably unrelated problem, which made testing a bit annoying:
> I can't actually send _any_ mail with mail-mode, because my ISP's
> mail-forwarder rejects any messages generated with it!  I'm not quite
> sure what extra headers or whatever message-mode adds, but I have no
> problems with mail sent using message-mode...

If you find out why that happens and post the info here, perhaps
someone could fix the problems causing it.  FWIW, I use mail-mode for
many years with many different ISPs with no problems at all.

Re: Sending attachments

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> I think this is not really related to attaching files.
...
> And this is out of scope for mail-mode, which (AFAIK) does not support
> news.

What exactly is the plan here?

Do we want to address the duplication between mail-mode and message-mode
or not?  Isn't this duplication a bad thing?  I think it is -- it
confuses users and adds maintenance burden.  Is adding layers and layers
of poorly integrated leaky bandaids to mail-mode really the path we want
to follow?  Are you just saying "let's add this one function now and
deal with the real problem later"?

-Miles

-- 
Hers, pron. His.

Re: Sending attachments

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

> p.s. A probably unrelated problem, which made testing a bit annoying:
> I can't actually send _any_ mail with mail-mode, because my ISP's
> mail-forwarder rejects any messages generated with it!  I'm not quite
> sure what extra headers or whatever message-mode adds, but I have no
> problems with mail sent using message-mode...

Perhaps it's the wrong envelope sender.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Sending attachments

[Miles Bader]

Andreas Schwab <schwab@linux-m68k.org> writes:
>> p.s. A probably unrelated problem, which made testing a bit annoying:
>> I can't actually send _any_ mail with mail-mode, because my ISP's
>> mail-forwarder rejects any messages generated with it!  I'm not quite
>> sure what extra headers or whatever message-mode adds, but I have no
>> problems with mail sent using message-mode...
>
> Perhaps it's the wrong envelope sender.

I think that's it, but somehow, message-mode manages to set it correctly
(or perhaps not set it incorrectly), whereas mail-mode fails to do so.

I was kind of surprised because I thought both used the same backend
sending code in emacs....

-Miles

-- 
Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.

Re: Sending attachments

[Richard Stallman]

    MH-e, wherein I found that simple MIME is pretty easy but everything  
    turns crazy when you hit multipart/mixed and multipart/alternative.   

I don't know a lot about Mime.  What does multipart/alternative mean?
I see that in incoming messages that have plain text and HTML,
but handling those messages in Emacs should be basically trivial.
So what is the difficulty?

Likewise for multipart/mixed: I see that in a message I received,
but it looks like handling that message requires nothing special
or difficult.

      Adding a simple `attach file' to mail-mode is probably  
    not very hard at all, but the result won't allow you to drop message- 
    mode/mml (it's been long enough that I forget which parts are where).

I do not propose to eliminate those programs.
The people who installed them should have proposed the change,
rather than sneaking it in as "part of Gnus".  But that was years ago,
and it would not make sense to remove it now.

Re: Sending attachments

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     It's a question of necessary complexity.
>
> I don't think so.  Look at all the libraries message.el loads.
>
> I don't want to replace the simple sendmail.el with this tremendous
> pile of complexity.
>
> message.el is also 8000 lines long, where sendmail.el is under 2000
> lines.  I expect that sending attachments won't require more than 200
> lines.

As has been pointed out, message-mode has more features than mail-mode.
Even if we wanted to bring mail-mode up to par, that would turn it into
something just as complex, or more (since, as you noted, message-mode
already relies on other libraries to much of its functionality).

Re: Sending attachments

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: yamaoka@jpl.org,  yandros@MIT.EDU,  ding@gnus.org,  emacs-devel@gnu.org
> Date: Sun, 05 Jul 2009 12:44:00 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > I think this is not really related to attaching files.
> ...
> > And this is out of scope for mail-mode, which (AFAIK) does not support
> > news.
> 
> What exactly is the plan here?

There is no plan (yet).  I was just trying to estimate the effort
needed for adding simple attachment facility to mail-mode.  Plans, if
there will be such, will come later.

> Do we want to address the duplication between mail-mode and message-mode
> or not?

I don't know about ``we'', but _I_ don't.  I simply don't have enough
time for such cleanups, and don't think I know enough about Gnus and
message-mode to be a good candidate for the job anyway.

> Isn't this duplication a bad thing?

Probably, but we have lived with that since when Gnus was merged with
Emacs.

> Is adding layers and layers of poorly integrated leaky bandaids to
> mail-mode really the path we want to follow?

I have no idea why you thought I was about to add ``leaky bandaids''.
I didn't even say I'm going to write any code, let alone ``leaky''.
And I don't think I ever added to Emacs such low-quality code that
would justify you making such assumptions, should I decide to write
some code.

Re: Sending attachments

[Byung-Hee HWANG]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    The first step is to check for incompatibilities and missing
>    features in message-mode.  Currently, message-mode recognizes many
>    mail-mode variables, such as `sendmail-program', and do the right
>    thing in response.  Someone needs to go through all the sendmail.el
>    variables and make sure they are all handled properly in
>    message-mode.  Once that is done, we can start to migrate rmail,
>    the bug reporter, and any other places that use mail-mode to
>    message-mode.
>
> That is much  unneeded work, the only thing  that uses message-mode is
> gnus.  It would be much easier to add etach, or similar, to mail-mode,
> and make gnus use mail-mode which is the default mode for sending mail
> in Emacs.

As a user of Gnus, i think mail-mode need to more features. For
example, mail-mode does not support IMAP. Currently, most folks use
Google's Gmail which offers IMAP. Hence, i cannot agree to such an
Alfred's proposal. Again, Gnus will not go with mail-mode unless Gmail's
users respect for mail-mode.

Sincerely,
 
-- 
Byung-Hee HWANG, KNU 
∑ WWW: http://izb.knu.ac.kr/~bh/

Re: Sending attachments

[Alfred M. Szmidt]

mail-mode is for sending mail, not for reading it.

Re: Sending attachments

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> > And this is out of scope for mail-mode, which (AFAIK) does not support
>> > news.
>> 
>> What exactly is the plan here?
>
> There is no plan (yet).  I was just trying to estimate the effort
> needed for adding simple attachment facility to mail-mode.  Plans, if
> there will be such, will come later.

So that would be the "let's add this one function now and
deal with the real problem later" answer, yes?

> I have no idea why you thought I was about to add ``leaky bandaids''.
> I didn't even say I'm going to write any code, let alone ``leaky''.
> And I don't think I ever added to Emacs such low-quality code that
> would justify you making such assumptions, should I decide to write
> some code.

I was not saying anything about your code (I wasn't even thinking you'd
write the code), and thus was making no assumptions about it.

The point was that real support for mime (as message-mode has today)
can't be done piecemeal, and that while adding "a little bit" of support
to mail-mode may be a _temporary_ fix for some people's perceived
problem, it isn't a good long-term solution -- and even in the
short-term it actually makes the duplication problem _worse_, so it
seems worth thinking about whether even that is actually desirable.

-Miles

-- 
Abstainer, n. A weak person who yields to the temptation of denying himself a
pleasure. A total abstainer is one who abstains from everything but
abstention, and especially from inactivity in the affairs of others.

Re: message-mode / mail-mode

[Stefan Monnier]

> You should set the variable `mail-header-separator' to ""; message-mode
> also pays attention to this variable.

Still, message-mode needs to be fixed so this is not necessary.


        Stefan

Re: Sending attachments

[Stefan Monnier]

>    I object strenuously to the idea of replacing the very simple Mail
>    mode with something complex from Gnus.
> As a user of mail-mode, I agree fully.

Could you give actual concrete arguments why you think so?


        Stefan

Re: Sending attachments

[Stefan Monnier]

> Etach looks like just what I had in mind.
> (The parts that interact with Rmail need updating.)

Adding etach to Emacs means adding complexity and the only benefit will
be to add to mail-mode a subset of the features offered by
message-mode, AFAICT.
So for mail-mode it may be a good idea, but not for Emacs as a whole.

As far as I'm concerned, mail-mode should be moved to the
`obsolete' directory.


        Stefan

Re: Sending attachments

[Alfred M. Szmidt]

   Etach looks like just what I had in mind.

I'll see if I can wip up something that we can included in Emacs, that
replaces mail-attach-file in mail-mode so that it will use MIME
instead.

   (The parts that interact with Rmail need updating.)

Indeed they do, rmail already has some hooks for MIME.  But the
rmailmime mode that I saw was quite complex, and I can no longer find
it, the URL that is listed in rmail.el doesn't work..

Does anyone have a copy of rmailmime.el?

Re: Sending attachments

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> Is adding layers and layers of poorly integrated leaky bandaids to
>> mail-mode really the path we want to follow?
>
> I have no idea why you thought I was about to add ``leaky bandaids''.

RMS has suggested adding simple attachment functionality to mail-mode,
e.g. via etach.  I haven't had time to look at the code of etach, but I
suspect that all this will accomplish is an incremental and incomplete
extension of mail-mode's feature set---not enough to catch up with
message-mode, but adding more code duplication.

Re: Sending attachments

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 05 Jul 2009 23:52:03 +0200
> Cc: ams@gnu.org, emacs-devel@gnu.org
> 
> As far as I'm concerned, mail-mode should be moved to the
> `obsolete' directory.

I hope that's a joke.  Especially since there's no mail-mode.el to
move.

Re: Sending attachments

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: yamaoka@jpl.org,  yandros@MIT.EDU,  ding@gnus.org,  emacs-devel@gnu.org
> Date: Mon, 06 Jul 2009 05:44:51 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> > And this is out of scope for mail-mode, which (AFAIK) does not support
> >> > news.
> >> 
> >> What exactly is the plan here?
> >
> > There is no plan (yet).  I was just trying to estimate the effort
> > needed for adding simple attachment facility to mail-mode.  Plans, if
> > there will be such, will come later.
> 
> So that would be the "let's add this one function now and
> deal with the real problem later" answer, yes?

Maybe, or maybe it will be a "let's do nothing" answer.

> The point was that real support for mime (as message-mode has today)
> can't be done piecemeal

I don't think anybody was talking about ``real support for MIME''.
People who managed to get away without MIME at all till this day
probably don't need more than a simple way of attaching non-text
files.

Re: Sending attachments

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> I don't think anybody was talking about ``real support for MIME''.
> People who managed to get away without MIME at all till this day
> probably don't need more than a simple way of attaching non-text
> files.

It's not what rms asked about, but it's certainly relevant to the
discussion.  Even if rms and ams would be satisfied with mail-mode +
simple-attach, it's natural to step back and think about the wider
implications of doing that.

In particular, the objections to simply adopting message-mode are still
unclear to me (other than the obvious one, that rms continues to be
annoyed because it was merged [apparently] without asking him).  Roughly
these objections seem to be something along the lines of "mail-mode is
simpler", but unless I've missed it, there's been little discussion of
exactly what the benefits of that are.

Some random points that come to mind:

  (1) We must still maintain message-mode as well, so mail-mode's
      "simplicity" yields no obvious code maintenance Benefit.

      Indeed, it's obviously more of a _burden_ to maintain both modes
      than it is to maintain message-mode alone (in the case that we got
      rid of mail-mode).  This burden goes up, of course, if mail-mode
      starts getting more features, like the suggested attachments.

  (2) I've used both modes over the years, and from my viewpoint as a
      user, both modes seem pretty much the same form a UI standpoint --
      message-mode has more bindings to support its additional
      functionality, but they do not get in the way as far as I can see.

      So as far as I can tell, mail-mode does not have an obviously
      simpler UI for the average user.

So... what exactly _is_ the "simplicity advantage" that's been alluded to?

[The "duplicated code disadvantage", on the other hand is pretty obvious...]

Thanks,

-Miles

-- 
Sabbath, n. A weekly festival having its origin in the fact that God made the
world in six days and was arrested on the seventh.

Re: Sending attachments

[Miles Bader]

Miles Bader <miles@gnu.org> writes:
> Some random points that come to mind:
>
>   (1) We must still maintain message-mode as well, so mail-mode's
>       "simplicity" yields no obvious code maintenance Benefit.
>
>   (2) I've used both modes over the years, and from my viewpoint as a
>       user, both modes seem pretty much the same form a UI standpoint

Oh, also:

  (3) Having both modes present presents a user burden, especially
      because the default is mail-mode -- there are many cases where
      a new user may need the extra features (even if he doesn't
      realize this, e.g., if he is sending non-ASCII characters in a
      way that isn't handled properly by mail-mode), but will still
      be using the default settings.

      Not only must the documentation be written to consider this
      and guide users, but in many cases, the user won't look at the
      documentation, or won't look in the proper place, and so will
      simply decide that Emacs mail handling doesn't support the
      desired feature.  In the case non-ASCII character case
      mentioned above, he may not even _know_ that he needs to do
      anything or look at any documentation -- he'll just send
      incorrect mail.

Thanks,

-Miles

-- 
Education, n. That which discloses to the wise and disguises from the foolish
their lack of understanding.

Re: Sending attachments

[Alfred M. Szmidt]

     (1) We must still maintain message-mode as well, so mail-mode's
	 "simplicity" yields no obvious code maintenance Benefit.

Seeing that we have already rcirc vs. erc, rmail vs. gnus vs. vm
vs. mh (which each has their own mail sending mode!), viper
vs. vi-mode vs. vile; a small _derived_ mode can't be the problem.
You already have people who prefer it, and are more than happy to fix
any bugs it has.  Maintaince is clear not the issue here.

	 Indeed, it's obviously more of a _burden_ to maintain both
	 modes than it is to maintain message-mode alone (in the case
	 that we got rid of mail-mode).  This burden goes up, of
	 course, if mail-mode starts getting more features, like the
	 suggested attachments.

For such a feature to be properly implmented they wouldn't be in
mail-mode (or any such mode), but in a seperate mode that handles MIME
attachment exclusivly.  If message-mode handles this itself, then it
is a sign that it was not properly thought through.

  (3) Having both modes present presents a user burden, especially
      because the default is mail-mode -- there are many cases where a
      new user may need the extra features (even if he doesn't realize
      this, e.g., if he is sending non-ASCII characters in a way that
      isn't handled properly by mail-mode), but will still be using
      the default settings.

I use it every day for non-ASCII text, and mail-mode has not had any
problems with that.

Re: message-mode / mail-mode

[Reiner Steib]

On Sun, Jul 05 2009, Stefan Monnier wrote:
> Miles Bader wrote:
>> Teemu Likonen <tlikonen@iki.fi> writes:
>>> Context-sensitive commands are good but in message-mode they seem to
>>> require that the "--text follows this line--" separator line exists.
[...]
>> You should set the variable `mail-header-separator' to ""; message-mode
>> also pays attention to this variable.
>
> Still, message-mode needs to be fixed so this is not necessary.

Please elaborate.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sending attachments

[Miles Bader]

"Alfred M. Szmidt" <ams@gnu.org> writes:
>      (1) We must still maintain message-mode as well, so mail-mode's
> 	 "simplicity" yields no obvious code maintenance Benefit.
>
> Seeing that we have already rcirc vs. erc, rmail vs. gnus vs. vm
> vs. mh (which each has their own mail sending mode!), viper
> vs. vi-mode vs. vile; a small _derived_ mode can't be the problem.

For all of the above, the duplication _does_ cause additional
maintenance burden, and more user confusion.

However, for many such packages the UIs of the various alternative modes
are quite different, so it's much easier to argue that the alternatives
are all "necessary" (in some cases that may not be true -- e.g., I'm not
sure if vi-mode is still really necessary), and that the burden is
justified.

mail-mode vs. message-mode is a particular funny case because the
message-mode UI seems to be pretty much a superset of mail-mode's UI
(if it isn't, please give details).

ERC vs. rcirc is a case where ERC is more functional, but has a very
different feel to the user.  My vague sense is that maybe people are
saying they feel the same is true of mail-mode vs. message-mode, but in
my own experience, such a difference was not at all obvious.

> You already have people who prefer it, and are more than happy to fix
> any bugs it has.

So, tell me, in concrete terms, _why_ do they prefer it?   Well, OK, you
may not want to speak for others, so just tell me why _you_ prefer it?
How would you be adversely affected if one day, someone snuck up and
replaced mail-mode with message-mode?

To help you get started, here are a general categories:

 (1) UI differences (AFAICT, they're very very similar, but I'm sure
     there are some differences that annoy people -- though in some
     cases these are probably bugs...)

 (2) Customization/hook differences -- maybe mail-mode has some great
     hooks or settings that message-mode doesn't.

 (3) Behavioral differences -- does mail-mode work with some systems
     where message-mode doesn't (as I mentioned earlier, mail-mode fails
     to send for some reason on one of my machines)?

Remember, be concrete, and be detailed -- we've all argued enough that
people's basic position is clear enough, and I don't see how it's
possible to advance this discussion without some actual details...

The reason why I sound a bit incredulous is that I've used both, and
other than message-mode's extra functionality -- which seemed pretty
much invisible to me unless I needed it -- they seemed more or less
identical.  [Well there are some things, like the fill prefix when
filling a header line is different...]

> Maintenance is clearly not the issue here.

Both modes seem fairly mature, so it's not the problem it might be, but
any bugs need to be checked for in both modes, and any new features may
need to be thought about in the context of both.  Documentation needs to
consider both, and worry about making the difference clear to users.
But I agree, it's probably not the main issue (though in the abstract
it's Not Good to have duplicate code bases).

I think, however, that the user burden of the duplication is very real.
People do not know, in general, that to get certain functionality they
have to use a different mail-sending mode.

> 	 Indeed, it's obviously more of a _burden_ to maintain both
> 	 modes than it is to maintain message-mode alone (in the case
> 	 that we got rid of mail-mode).  This burden goes up, of
> 	 course, if mail-mode starts getting more features, like the
> 	 suggested attachments.
>
> For such a feature to be properly implmented they wouldn't be in
> mail-mode (or any such mode), but in a seperate mode that handles MIME
> attachment exclusivly.  If message-mode handles this itself, then it
> is a sign that it was not properly thought through.

That is not at all clear -- AFAIK, much of the actual MIME stuff is a
separate library, but MIME covers a lot of aspects of mail encoding, not
just attachments, and all of that it's going to need to be hooked into
the top-level mode.

In any case, I can't defend the quality of the message-mode code.  The
general code quality or design of mail-mode may well be higher.

However, if mail-mode doesn't have the requisite functionality (which
certainly seems to be the case), then we could

 (a) Keep both, and suffer the problems of having both (maintenance
     burden and user confusion).

 (b) Fix any bugs / functional inadequacies in in message-mode, and
     trash mail-mode.  Since message-mode largely seems to be a superset
     from the user's point of view, this option seems to have a fairly
     small cost.  If message-mode's code is bad, then that's a shame,
     but having message-mode alone is certainly less of a problem than
     message-mode plus something else.

 (c) Add the required functionality to mail-mode, fix any other problems
     with it, and trash message-mode.  As mail-mode is missing a lot of
     functionality, this would seem to have a far higher cost than
     option (b), but the end result might be better.

If mail-mode has better code than message-mode, then ideally we'd choose
(c), but in practice, the implementation cost (and associated extra
maintenance burden of new code) may make (b) the better choice.

> I use it every day for non-ASCII text, and mail-mode has not had any
> problems with that.

The most obvious problem with mail-mode's handling of non-ASCII text is
that it doesn't seem to encode headers correctly (headers in email are
annoying, you need to use a whole separate system for encoding them).

[and does mail-mode support any non-8-bit transfer encodings?  Does it
work if the message encoding isn't utf-8, and the user uses multiple
languages?]

Thanks,

-Miles

-- 
Erudition, n. Dust shaken out of a book into an empty skull.

Re: Sending attachments

[Chong Yidong]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Seeing that we have already rcirc vs. erc, rmail vs. gnus vs. vm
> vs. mh (which each has their own mail sending mode!), viper
> vs. vi-mode vs. vile; a small _derived_ mode can't be the problem.
> You already have people who prefer it, and are more than happy to fix
> any bugs it has.  Maintaince is clear not the issue here.

Apart from Miles' reply to this (with which I fully agree), it should be
noted that rcirc/erc/gnus/mh have dedicated maintainers, while mail-mode
is maintained in-tree.

Re: Sending attachments

[Richard Stallman]

    As far as I'm concerned, mail-mode should be moved to the
    `obsolete' directory.

Please don't do that!

Re: Sending attachments

[Richard Stallman]

    I'll see if I can wip up something that we can included in Emacs, that
    replaces mail-attach-file in mail-mode so that it will use MIME
    instead.

Other than some simplifications, because it would not need to work
in old Emacs versions, why is any change needed?

Re: Sending attachments

[Richard Stallman]

    So that would be the "let's add this one function now and
    deal with the real problem later" answer, yes?

The real issue that I raised is sending attachments with Mail mode.
Installing Etach will deal with that.  This actually does not involve
a change in sendmail.el, since Etach is modular.

Re: Sending attachments

[Richard Stallman]

      1. Proper handling of non-ascii text. For instance:

	  a. Proper encoding of non-ascii headers (using "=?" notation)
	  b. Ability to use other transfer encodings besides 8-bit
	  c. Ability to automatically choose different character encodings
	     depending on the language/context/whatever (e.g., for many
	     cases, the "standard" isn't utf-8).

      2. Ability to have both text and binary attachments (both are very
	 important), and that these work together with the language support
	 in part (1).

The features I would like to see are probably a subset of this.  I am
not sure it needs to be as automatic and complete as this would have
it.

Etach seems to do the job that I want done.

Re: Sending attachments

[Richard Stallman]

I can maintain and extend Mail mode.  I cannot maintain Message mode;
it is too hairy and depends on too much.

Etach, once documented in the Emacs manual
(which is very simple to do),
will show Emacs users how to send attachments.

Etach also decodes Mime.  I have not tried that yet
but I will soon.

Re: Sending attachments

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Etach, once documented in the Emacs manual (which is very simple to
> do), will show Emacs users how to send attachments.
>
> Etach also decodes Mime.  I have not tried that yet but I will soon.

We should not add yet another mime library to Emacs, when we already
have one (mml.el).

Re: Sending attachments

[Glenn Morris]

Richard Stallman wrote:

> Etach also decodes Mime. I have not tried that yet but I will soon.

Have you looked at rmailmm.el, which is part of Emacs?

;;; rmailmm.el --- MIME decoding and display stuff for RMAIL

Re: Sending attachments

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Mon, 06 Jul 2009 13:54:03 +0900
> Cc: ding@gnus.org
> 
>                              In the case non-ASCII character case
>       mentioned above, he may not even _know_ that he needs to do
>       anything or look at any documentation -- he'll just send
>       incorrect mail.

Did you actually try that?  Mail mode will not let you send such
messages, it will prompt for a proper encoding.

Re: Sending attachments

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: eliz@gnu.org, yandros@MIT.EDU, yamaoka@jpl.org, ding@gnus.org,
>         emacs-devel@gnu.org
> Date: Mon, 06 Jul 2009 16:47:22 +0900
> 
> does mail-mode support any non-8-bit transfer encodings?

Yes.

> Does it work if the message encoding isn't utf-8, and the user uses
> multiple languages?

No.  It supports only a single encoding for the whole body (and will
insist on getting one, before it sends).

Re: Sending attachments

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Miles Bader <miles@gnu.org>, yamaoka@jpl.org, yandros@MIT.EDU,
>         ding@gnus.org, emacs-devel@gnu.org
> Date: Sun, 05 Jul 2009 18:56:04 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Is adding layers and layers of poorly integrated leaky bandaids to
> >> mail-mode really the path we want to follow?
> >
> > I have no idea why you thought I was about to add ``leaky bandaids''.
> 
> RMS has suggested adding simple attachment functionality to mail-mode,
> e.g. via etach.  I haven't had time to look at the code of etach, but I
> suspect that all this will accomplish is an incremental and incomplete
> extension of mail-mode's feature set---not enough to catch up with
> message-mode, but adding more code duplication.

Even if I would agree with your point, it's still a far cry from leaky
bandaids.

Re: Sending attachments

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sun, 05 Jul 2009 10:47:32 -0400
> Cc: emacs-devel@gnu.org, miles@gnu.org
> 
> As has been pointed out, message-mode has more features than mail-mode.

Yes.  And Gnus has much more features than Rmail.  So what?  We all do
agree that much more features means more complexity in setting things
up.  Why impose that on people who are happy with simple modes?

> Even if we wanted to bring mail-mode up to par

No one suggested that.

> that would turn it into something just as complex, or more (since,
> as you noted, message-mode already relies on other libraries to much
> of its functionality).

Encoding a file uses only core Emacs features (base64-encode-region),
so no libraries should be involved.

Re: Sending attachments

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Miles Bader <miles@gnu.org>, eliz@gnu.org, yandros@MIT.EDU,
>         yamaoka@jpl.org, ding@gnus.org, emacs-devel@gnu.org
> Date: Mon, 06 Jul 2009 10:13:51 -0400
> 
> "Alfred M. Szmidt" <ams@gnu.org> writes:
> 
> > Seeing that we have already rcirc vs. erc, rmail vs. gnus vs. vm
> > vs. mh (which each has their own mail sending mode!), viper
> > vs. vi-mode vs. vile; a small _derived_ mode can't be the problem.
> > You already have people who prefer it, and are more than happy to fix
> > any bugs it has.  Maintaince is clear not the issue here.
> 
> Apart from Miles' reply to this (with which I fully agree), it should be
> noted that rcirc/erc/gnus/mh have dedicated maintainers, while mail-mode
> is maintained in-tree.

For some value of ``maintained''.  Cursory scan of the logs shows that
it gets one simple change every 3 months or so, sometimes even less
(modulo doc fixes).  So much for a ``burden''.

Re: Sending attachments

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> In the case non-ASCII character case mentioned above, he may not even
>> _know_ that he needs to do anything or look at any documentation --
>> he'll just send incorrect mail.
>
> Did you actually try that?  Mail mode will not let you send such
> messages, it will prompt for a proper encoding.

You may be thinking of a different case.

I did test sending a message with non-ASCII text in the header, which
mail-mode sent incorrectly, without any prompting or warning (you can't
just encode header text using the body's encoding, you need to use the
special "?=" encoding stuff).

-Miles

-- 
We have met the enemy, and he is us.  -- Pogo

Re: Sending attachments

[Kenichi Handa]

In article <87y6r1san7.fsf@catnip.gol.com>, Miles Bader <miles@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>>> In the case non-ASCII character case mentioned above, he may not even
>>> _know_ that he needs to do anything or look at any documentation --
>>> he'll just send incorrect mail.
> >
> > Did you actually try that?  Mail mode will not let you send such
> > messages, it will prompt for a proper encoding.

> You may be thinking of a different case.

> I did test sending a message with non-ASCII text in the header, which
> mail-mode sent incorrectly, without any prompting or warning (you can't
> just encode header text using the body's encoding, you need to use the
> special "?=" encoding stuff).

I've been believed that mail-mode (and the new rmail code)
supports non-ASCII Subject: correctly, but it was not.  I've
just noticed that I'm using these setups in my .emacs.  The
similar codes should be installed (of course, not as hooks).

(require 'rfc2047)

(defun rmail-decode-header ()
  (save-excursion
    (goto-char (point-min))
    (search-forward "\n\n")
    (if (re-search-backward "^subject:" nil t)
	(let ((buffer-read-only nil)
	      (pos (match-end 0)))
	  (forward-line 1)
	  (while (looking-at "[ \t]")
	    (forward-line 1))
	  (rfc2047-decode-region pos (1- (point)))))))

(add-hook 'rmail-show-message-hook 'rmail-decode-header)

(require 'rmailsum)

(defun mail-decode-summary-line (line)
  (rfc2047-decode-string line))

(setq rmail-summary-line-decoder 'mail-decode-summary-line)

(require 'sendmail)

(defun mail-encode-header ()
  (save-excursion
    (goto-char (point-min))
    (search-forward mail-header-separator nil 'move)
    (let ((case-fold-search t)
	  pos)
      (when (re-search-backward "^subject:" nil t)
	(setq pos (point))
	(forward-line 1)
	(while (looking-at "[ \t][^ \t\n]")
	  (forward-line 1))
	(rfc2047-encode-region pos (1- (point)))))))

(add-hook 'mail-send-hook 'mail-encode-header)

(defun mail-decode-header ()
  (save-excursion
    (mail-position-on-field "Subject" t)
    (if (not (bobp))
	(let ((pos (point)))
	  (beginning-of-line)
	  (while (looking-at "[ \t]")
	    (forward-line -1))
	  (rfc2047-decode-region (point) pos)))))

(add-hook 'mail-setup-hook 'mail-decode-header)

---
Kenichi Handa
handa@m17n.org

Re: Sending attachments

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> As has been pointed out, message-mode has more features than mail-mode.
>
> Yes.  And Gnus has much more features than Rmail.  So what?  We all do
> agree that much more features means more complexity in setting things
> up.  Why impose that on people who are happy with simple modes?

How, exactly, is message-mode an "imposition" on "people who are happy
with simple modes"?

  * Its user-interface?  [As far as I can tell, message-mode's UI
    _isn't_ complex, and indeed is pretty much exactly the same as
    mail-mode's (its additional functionality being largely invisible
    unless you use it).  I've used both many times over the years, and
    never noticed anything obviously different (there are random trivial
    differences like header-filling whitespace, etc, but those are not
    significant -- if they actually bother people, they can easily be
    changed).]

  * Its resource consumption?  [It doesn't seem any slower (which makes
    sense, as the great bulk of the extra functionality is only used
    with explicitly invoked).  It's more code, but doesn't seem horribly
    large by emacs standards, and additional memory used by its code
    seems small compared to the rest of emacs, and shouldn't be an issue
    on any modern system.]

  * Is it more buggy?  [Never noticed any obvious difference in this respect.]

  * Is it missing useful user-customization hooks or settings that
    mail-mode has?

  * Does it interface badly with some other Emacs code (e.g., rmail)?

Please, please, somebody who asserts that mail-mode is necessary, give
some concrete examples as to _why_.  The amount of hand-waving in this
thread is maddening...

-Miles

-- 
Future, n. That period of time in which our affairs prosper, our friends
are true and our happiness is assured.

Re: Sending attachments

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Chong Yidong <cyd@stupidchicken.com>, rms@gnu.org, emacs-devel@gnu.org
> Date: Tue, 07 Jul 2009 10:12:57 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> As has been pointed out, message-mode has more features than mail-mode.
> >
> > Yes.  And Gnus has much more features than Rmail.  So what?  We all do
> > agree that much more features means more complexity in setting things
> > up.  Why impose that on people who are happy with simple modes?
> 
> How, exactly, is message-mode an "imposition" on "people who are happy
> with simple modes"?

If you insist on everyone switching to message-mode and making
mail-mode obsolete, you are imposing message-mode on them.

> Please, please, somebody who asserts that mail-mode is necessary, give
> some concrete examples as to _why_.

Maybe someone else will.  This old fart simply doesn't want to learn a
new mode unless it's absolutely necessary.  Is this so hard to
understand?

Re: Sending attachments

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> How, exactly, is message-mode an "imposition" on "people who are happy
>> with simple modes"?
>
> If you insist on everyone switching to message-mode and making
> mail-mode obsolete, you are imposing message-mode on them.

"imposition" is pejorative; it implies that the people being imposed
upon will suffer in some way.  Since I don't see any obvious negative
effect from switching to message-mode (counter-examples welcome!), using
a pejorative term doesn't really seem warranted.

>> Please, please, somebody who asserts that mail-mode is necessary, give
>> some concrete examples as to _why_.
>
> Maybe someone else will.  This old fart simply doesn't want to learn a
> new mode unless it's absolutely necessary.  Is this so hard to
> understand?

What if the new mode is effectively indistinguishable from the old mode?

See, _that's_ why I'm so confused -- message-mode is not some kind of
wacky new UI, it seems to me to be pretty much _the same_ as mail-mode
from the user's point of view.

If I'm wrong about this, I'd like to know.  I've used both, so I think I
have _some_ clue, but maybe I'm missing something.

Thanks,

-Miles

-- 
Consult, v.i. To seek another's disapproval of a course already decided on.

Re: Sending attachments

[Giorgos Keramidas]

On Mon, 06 Jul 2009 02:37:32 -0400, "Alfred M. Szmidt" <ams@gnu.org> wrote:
> For such a feature to be properly implmented they wouldn't be in
> mail-mode (or any such mode), but in a seperate mode that handles MIME
> attachment exclusivly.  If message-mode handles this itself, then it
> is a sign that it was not properly thought through.

It's a library already, IIRC.  The mml-* functions can parse a simple
meta-language from plain text buffers and generate MIME messages:

,---[ (emacs-mime)Top > Composing ----------------------------------
|
| 2 Composing
| ***********
|
| Creating a MIME message is boring and non-trivial.  Therefore, a
| library called `mml' has been defined that parses a language called MML
| (MIME Meta Language) and generates MIME messages.
|
`-----------------------------------------------------------------------

Perhaps mail-mode can be tweaked to use `mml-' functions too?

Re: Sending attachments

[Alfred M. Szmidt]

       I'll see if I can wip up something that we can included in
       Emacs, that replaces mail-attach-file in mail-mode so that it
       will use MIME instead.

   Other than some simplifications, because it would not need to work
   in old Emacs versions, why is any change needed?

If etach is added to emacs, then I suppose it would be unneeded work.

Re: Sending attachments

[Alfred M. Szmidt]

That is really neat, thank you.

Re: Sending attachments

[Alfred M. Szmidt]

Please, lets drop this discussion.  Richard volunteered to maintain
mail-mode, so do I, and Eli I suspect will be more than happy to do it
as well.

Re: Sending attachments

[Richard Stallman]

    Have you looked at rmailmm.el, which is part of Emacs?

    ;;; rmailmm.el --- MIME decoding and display stuff for RMAIL

Thanks for reminding me about this.

Etach has code for making attachments and for decoding attachments,
but they are separate in implementation.  If rmailmm is better for
decoding, we could install only the Etach encoding support.

I looked at, and tried, both rmailmm and Etach's mime decoding code.

I just tried rmailmm on a message which had a text part and an HTML
part.  It made a temporary buffer and showed both of them in it.  If I
changed it to put some separator between the two parts, it would be
usable.

etach-detach is more convenient because does one attachment at a time.
It also understands mime more.  For instance, it understands that the
text and HTLM are alternatives and you only want to see one.

I needed to make a few changes to get it to work with rmail-mbox, but
they were simplifications.  It now displays the textual attachments
right in the rmail view buffer.

I concluded that the etach-detach code is superior.  I think it should
replace rmailmm.  With a little more work I could give it a mode
of behavior similar to rmailmm, so as to make the replacement smoother.

Re: Sending attachments

[Richard Stallman]

    As has been pointed out, message-mode has more features than mail-mode.
    Even if we wanted to bring mail-mode up to par, that would turn it into
    something just as complex,

If "par" means all the same features, nobody wants to do that.  It is not
necessary or useful.

What I want to do is install Etach.  Specifically, the part of Etach
that creates mime attachments.  This would provide the facility of
sending attachments in Mail mode, but without any actual change to
sendmail.el.

There may be a few other features that it would be nice to provide in
Mail mode, and some of them might involve adding some code in that file.
But this would not involve anything like the complexity of Message mode.

Etach attachment is a modular feature which does not directly interact
with the code in sendmail.el.  Users could load it or not.

message.el forces the loading of many other packages (I sent the list
before).  So its effective complexity includes all of them.  It is
tied in with Gnus, and can't be maintained on its own.  Mail mode is nice
and simple, and I will maintain it myself if you don't want to.

Re: Sending attachments

[Richard Stallman]

    We should not add yet another mime library to Emacs, when we already
    have one (mml.el).

Etach and mml both deal with puttimg mime into a message, but in very
different ways.  mml.el requires the user to write text in the MML
language and then convert it into mime.

Etach has a convenient interface M-x attach which attaches a file in
the message in the current buffer.  That is a simple feature and
easy to use.

Etach and MML are complementary, so it is better to have them both.

Re: Sending attachments

[Richard Riley]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Please, lets drop this discussion.  Richard volunteered to maintain
> mail-mode, so do I, and Eli I suspect will be more than happy to do it
> as well.
>

Reading this discussion is quite interesting. I have to ask why you are
so keen to duplicate efforts when it seems relatively clear that
message-mode is a non intrusive superset of mail-mode. Getting more
familiar with emacs I have to say that its frequently an issue for new
adopters as well as seasoned users that there are too many versions of
effectively the same thing leading to duplicated efforts as well as
confusion in both code usage and documentation. In addition, quoting properly
might add more force to your argument. Miles has asked multiple times
for something that mail-mode provides that message mode does not, he has
pointed out how there is no real learning curve. I would be very
interested, from the developer point of view, to know why you seem to be
so dead set against retiring what is effectively a sub-set of a more
commonly used and better maintained mode like message-mode. Especially
in the context of adding things to mail-mode which are blatantly
unproven in this thread. 

Excuse me my 3 seconds, but, well, the arguments for maintaining
mail-mode seem, to me who has no agenda, nothing more than "because I
say so".

Re: Sending attachments

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     We should not add yet another mime library to Emacs, when we already
>     have one (mml.el).
>
> Etach and mml both deal with puttimg mime into a message, but in very
> different ways.  mml.el requires the user to write text in the MML
> language and then convert it into mime.

It doesn't.  There are front-end functions that do all that for you.

> Etach has a convenient interface M-x attach which attaches a file in
> the message in the current buffer.

As does MML (mml-attach-file).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Sending attachments

[Jason Rumney]

Richard Stallman wrote:
> mml.el requires the user to write text in the MML
> language and then convert it into mime.
>   

Most users would use mml-attach-file, though some might find writing 
text in MML faster if they are familiar with it. And the conversion to 
MIME is the major part of what mml.el handles, as part of a send hook 
(or maybe directly called by message-mode's send function).

Re: Sending attachments

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> What I want to do is install Etach.  Specifically, the part of Etach
> that creates mime attachments.  This would provide the facility of
> sending attachments in Mail mode, but without any actual change to
> sendmail.el.

Since there is existing, actively-maintained code in Emacs for sending
attachments, it's incorrect to add yet another library for this.
Assuming the status quo, with mail-mode and message-mode separate,
adding mime functionality to mail-mode should involve calling this
existing code.

> message.el forces the loading of many other packages (I sent the list
> before).  So its effective complexity includes all of them.  It is
> tied in with Gnus, and can't be maintained on its own.

Message mode is actively maintained by the Gnus maintainers, so this
point is irrelevant.  And there is no other salient objection to message
mode, as far as I can tell.

Re: Sending attachments

[Chong Yidong]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Please, lets drop this discussion.  Richard volunteered to maintain
> mail-mode, so do I, and Eli I suspect will be more than happy to do it
> as well.

The problem is that further development of mail-mode will likely involve
adding code that directly duplicates the existing code used in message
mode, with inferior results (e.g. mml vs etach).

Re: Sending attachments

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: cyd@stupidchicken.com, rms@gnu.org, emacs-devel@gnu.org
> Date: Tue, 07 Jul 2009 13:54:25 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> How, exactly, is message-mode an "imposition" on "people who are happy
> >> with simple modes"?
> >
> > If you insist on everyone switching to message-mode and making
> > mail-mode obsolete, you are imposing message-mode on them.
> 
> "imposition" is pejorative

So is ``leaky bandaids''.

> > This old fart simply doesn't want to learn a new mode unless it's
> > absolutely necessary.  Is this so hard to understand?
> 
> What if the new mode is effectively indistinguishable from the old mode?

My gray hair says there ain't no such thing.  If it's more powerful
and sophisticated, there's some price to pay.

Re: Sending attachments

[Richard Stallman]

    > message.el forces the loading of many other packages (I sent the list
    > before).  So its effective complexity includes all of them.  It is
    > tied in with Gnus, and can't be maintained on its own.

    Message mode is actively maintained by the Gnus maintainers, so this
    point is irrelevant.

It is not a good thing that message mode can only be maintained by the
Gnus maintainers.

Re: Sending attachments

[Richard Stallman]

    > Etach has a convenient interface M-x attach which attaches a file in
    > the message in the current buffer.

    As does MML (mml-attach-file).

It isn't in the emacs-mime manual so I did not know about it.  I tried
it just now.  It asked me a lot of questions and then inserted this
text.

<#part type="text/x-sh" filename="~/foo.sh" disposition=inline description=foo>
<#/part>

I suppose this is MML and needs to get converted later.
However, when I sent the message with C-c C-c, it did not convert.
I don't see that it set up any hook to do so.

After a lot of searching thru that manual I found the function
mml-to-mime.

If mml-to-mime were put on a hook so that C-c C-c would call it, this
feature would be usable.  A suitable front-end to mml-attach-file
could avoid asking all the annoying questions.  It would only be
necessary to document it.

However, that hook could also cause trouble, since it might
trigger by accident when users did not intend it.

Another drawback, compared with etach-detach, is that you don't see
what is really going to appear in the message.

Re: Sending attachments

[Richard Stallman]

I can adapt and install Handa's code.  Before I do,
does anyone see a problem with the change he proposes?

Re: Sending attachments

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> Another drawback, compared with etach-detach, is that you don't see
> what is really going to appear in the message.

That's what mml-preview is for.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Sending attachments

[Jason Rumney]

Richard Stallman wrote:
> <#part type="text/x-sh" filename="~/foo.sh" disposition=inline description=foo>
> <#/part>
>   

> A suitable front-end to mml-attach-file
> could avoid asking all the annoying questions.

It is probably reasonable to use a type of application/octet-stream, 
disposition of attachment and have no description for simple 
attachments.  So the only absolutely necessary question is the 
filename.  We could have another command for attaching inline images and 
text files if that is a goal also, and such a function could determine 
the type automatically from the file type (which seems to be done now, 
but the user is prompted to change it), always have a disposition of 
inline, and again not use description.

Re: Sending attachments

[Miles Bader]

Jason Rumney <jasonr@gnu.org> writes:
> always have a disposition of inline, and again not use description.

Hmm, I think disposition=inline is often (usually?) wrong...
My impression is that most people, when they attach something, want it
attached as a separate downloadable thingie.

-Miles

-- 
Brain, n. An apparatus with which we think we think.

Re: Sending attachments

[Teemu Likonen]

On 2009-07-08 22:41 (+0900), Miles Bader wrote:

> Jason Rumney <jasonr@gnu.org> writes:
>> always have a disposition of inline, and again not use description.
>
> Hmm, I think disposition=inline is often (usually?) wrong...
> My impression is that most people, when they attach something, want it
> attached as a separate downloadable thingie.

It's very useful to have a choice. For small textual file the "inline"
type is good because it can be seen and read without further action. An
example:

    http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3437#10

Inline MIME part is better than putting the content to the message body
because it is protected from possible word-wrapping of the editor or
mail client. Inline parts can be saved to disk too.

Real attachment is obviously better for binary files and large textual
files. It would waste too much space if a large textual attachment was
an "inline".

In my opinion mml-attach-file does not ask "annoying question". Other
than choosing the file user can just press Enter to all the questions.

Re: Sending attachments

[Miles Bader]

Teemu Likonen <tlikonen@iki.fi> writes:
>>> always have a disposition of inline, and again not use description.
>>
>> Hmm, I think disposition=inline is often (usually?) wrong...
>> My impression is that most people, when they attach something, want it
>> attached as a separate downloadable thingie.
>
> It's very useful to have a choice. For small textual file the "inline"
> type is good because it can be seen and read without further action.

Sure, I agree there are times when inline can be useful -- my objection
was to the (apparent) idea of having inline be the default without
prompting (I think _if_ people want to avoid prompting, inline is the
wrong default).

-Miles

-- 
自らを空にして、心を開く時、道は開かれる

Re: Sending attachments

[Teemu Likonen]

On 2009-07-08 23:27 (+0900), Miles Bader wrote:

> Teemu Likonen <tlikonen@iki.fi> writes:
>> It's very useful to have a choice. For small textual file the
>> "inline" type is good because it can be seen and read without further
>> action.
>
> Sure, I agree there are times when inline can be useful -- my
> objection was to the (apparent) idea of having inline be the default
> without prompting (I think _if_ people want to avoid prompting, inline
> is the wrong default).

Oh yes, I agree very much, inline would be wrong default if the question
was totally hidden. I wanted to point out that those "annoying
questions" (according to Richard) are _useful_ questions to me.

Re: Sending attachments

[Jason Rumney]

I wrote:

    It is probably reasonable to use a type of application/octet-stream,
    disposition of attachment and have no description for simple
    attachments.
    ....
    We could have another command for attaching inline images and text
    files if that is a goal also, and such a function could ....


Miles Bader quoted:
>>>> always have a disposition of inline, and again not use description.
>>>>         
> Sure, I agree there are times when inline can be useful -- my objection
> was to the (apparent) idea of having inline be the default without
> prompting (I think _if_ people want to avoid prompting, inline is the
> wrong default).
>   


It seems you only read the last bit of what I wrote.

Re: Sending attachments

[Richard Stallman]

    That's what mml-preview is for.

It isn't mentioned in the Emacs-Mime manual.  Its doc string seems to
say it displays the message with Gnus, which is not what I want to do.

I did manage to preview the mime text by executing (mml-to-mime).
(That interface is not satisfactory.)  But now, after looking at the
code of mml-preview, I wonder whether that is enough.  The code of
mml-preview does things I do not understand the purpose of.

Here's what the code does, leading up to the call to mml-to-mime.
Why is this needed?  What does this do?

      (mml-preview-insert-mail-followup-to)
      (let ((message-deletable-headers (if (message-news-p)
					   nil
					 message-deletable-headers)))
	(message-generate-headers
	 (copy-sequence (if (message-news-p)
			    message-required-news-headers
			  message-required-mail-headers))))
      (if (re-search-forward
	   (concat "^" (regexp-quote mail-header-separator) "\n") nil t)
	  (replace-match "\n"))
      (let ((mail-header-separator ""));; mail-header-separator is removed.
	(message-sort-headers)
	(mml-to-mime))

Re: Sending attachments

[Reiner Steib]

On Wed, Jul 08 2009, Jason Rumney wrote:

> Richard Stallman wrote:
[...]
>> A suitable front-end to mml-attach-file could avoid asking all the
>> annoying questions.
>
> It is probably reasonable to use a type of application/octet-stream,

Please don't follow the bad behavior of MS Outlook.  mml-attach-file
figures out the suitable default by consulting the MIME type / Mailcap
files.  application/octet-stream is more or less a fallback for
arbitrary binary data, see RFC 2046
<http://tools.ietf.org/html/rfc2046#section-4.5.1>.

> disposition of attachment and have no description for simple
> attachments.  So the only absolutely necessary question is the
> filename.

We could add an option as we do when using drag and drop to attach a
file:

,----[ <f1> v mml-dnd-attach-options RET ]
| mml-dnd-attach-options is a variable defined in `mml.el'.
| Its value is nil
| 
| Documentation:
| Which options should be queried when attaching a file via drag and drop.
| 
| If it is a list, valid members are `type', `description' and
| `disposition'.  `disposition' implies `type'.  If it is nil,
| don't ask for options.  If it is t, ask the user whether or not
| to specify options.
| 
| You can customize this variable.
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sending attachments

[Reiner Steib]

On Wed, Jul 08 2009, Richard Stallman wrote:

>     As does MML (mml-attach-file).
>
> It isn't in the emacs-mime manual so I did not know about it.  

It is documented in the Message manual:

,----[ (info "(message)MIME") ]
|    The most typical thing users want to use the multipart things in
| MIME for is to add "attachments" to mail they send out.  This can be
| done with the `C-c C-a' command (`M-x mml-attach-file'), which will
| prompt for a file name and a MIME type.
| 
|    If your Emacs supports drag and drop, you can also drop the file in
| the Message buffer.  [...]
`----

> I tried it just now.  It asked me a lot of questions and then
> inserted this text.
>
> <#part type="text/x-sh" filename="~/foo.sh" disposition=inline description=foo>
> <#/part>
>
> I suppose this is MML and needs to get converted later.
> However, when I sent the message with C-c C-c, it did not convert.
> I don't see that it set up any hook to do so.

message-mode does the conversion automatically

,----[ (info "(message)MIME") ]
| Message is a MIME-compliant posting agent.  The user generally doesn't
| have to do anything to make the MIME happen--Message will automatically
| add the `Content-Type' and `Content-Transfer-Encoding' headers.
`----

> After a lot of searching thru that manual I found the function
> mml-to-mime.

Well, it under Composing -> Conversion, which seem quite suitable to
me.  

,----[ (info "(emacs-mime)Conversion") ]
|    An MML message can be converted back to MIME by the `mml-to-mime'
| function.
`----

message-mode uses mml-generate-mime, though:

,----[ (info "(emacs-mime)Composing") ]
|    The main interface function is `mml-generate-mime'.  It will examine
| the contents of the current (narrowed-to) buffer and return a string
| containing the MIME message.
`----

> If mml-to-mime were put on a hook so that C-c C-c would call it, this
> feature would be usable.  A suitable front-end to mml-attach-file
> could avoid asking all the annoying questions.  

mml-attach-file is the front-end used in message-mode for many years.
I quite often adjust type and disposition (inline vs. attachment).  I
don't recall any complains about the questions from our users.  Just
hit RET if you are happy with.

> It would only be necessary to document it.
>
> However, that hook could also cause trouble, since it might
> trigger by accident when users did not intend it.

It quite unlikely that users insert MML markup by accident.  When
writing about it, there is `mml-quote-region'.

> Another drawback, compared with etach-detach, is that you don't see
> what is really going to appear in the message.

C-u M-x mml-preview RET, M-x mml-preview RET

,----[ <f1> f mml-preview RET ]
| mml-preview is an interactive compiled Lisp function in `mml.el'.
| It is bound to <menu-bar> <Attachments> <Preview>, C-c RET P.
| (mml-preview &optional RAW)
| 
| Display current buffer with Gnus, in a new buffer.
| If RAW, display a raw encoded MIME message.
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sending attachments

[Reiner Steib]

On Wed, Jul 08 2009, Richard Stallman wrote:

> I did manage to preview the mime text by executing (mml-to-mime).
> (That interface is not satisfactory.)  But now, after looking at the
> code of mml-preview, I wonder whether that is enough.  The code of
> mml-preview does things I do not understand the purpose of.
>
> Here's what the code does, leading up to the call to mml-to-mime.
> Why is this needed?  

The purpose is to display the mail message more like it would be sent.

> What does this do?

Removing/adding suitable headers, stripping mail-header-separator,
sorting headers.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sending attachments

[Miles Bader]

Jason Rumney <jasonr@gnu.org> writes:
> It seems you only read the last bit of what I wrote.

Whatever....  If people want to waste their time duplicating code and
making Emacs harder to use and understand for silly reasons, it's their
business, but I'm not going spend any more effort on it.

So, I'm going to plonk this thread.

If at some point real issues start to be addressed (for instance,
actually figuring out a coherent plan for making mail/news sending in
Emacs better for everybody, not just rms and ams), could someone give me
a ping, so I can start paying attention again?

Thanks,

-Miles

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Re: Sending attachments

[Richard Stallman]

    The purpose is to display the mail message more like it would be sent.

    > What does this do?

    Removing/adding suitable headers, stripping mail-header-separator,
    sorting headers.

I see that that is true as regards mail-header-separator.
However, the rest seems not to be right for Mail mode.
It looks like this code is written only for use in Gnus.

Re: Sending attachments

[Richard Stallman]

    It is probably reasonable to use a type of application/octet-stream, 
    disposition of attachment and have no description for simple 
    attachments.

For most files, the type can be determined from the file name and
contents.  The simple interface should be able to do everything
automatically.  Maybe just accepting mml's default type would
do the right job.  If not, the code to do this is available in Etach.

Re: Sending attachments

[Richard Stallman]

I searched several weeks of incoming mail and disposition=inline never
appears.

Viewing text inline is very useful, but that doesn't mean sending
disposition=inline is useful.  Both rmailmm and Etach display some
text parts inline, and they don't need to see disposition=inline to do
it.

Re: Sending attachments

[Reiner Steib]

On Thu, Jul 09 2009, Richard Stallman wrote:

> I searched several weeks of incoming mail and disposition=inline
> never appears.

There are many examples in emacs-devel:

/var/spool/news/gmane/emacs/devel# grep '^Content-Disposition:.*inline.*filename' *|wc -l
40

Most MUAs (Mail User Agents) probably don't offer to any choice to
the user.

> Viewing text inline is very useful, but that doesn't mean sending
> disposition=inline is useful.  

"disposition" is more or less a recommendation for the receiving agent
how to display it.

> Both rmailmm and Etach display some text parts inline, and they
> don't need to see disposition=inline to do it.

Neither does Gnus (and probably MH-E, too).  Viewing inline
vs. attachment can be toggled interactively or specified through
`mm-inline-override-types'.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sending attachments

[Reiner Steib]

On Thu, Jul 09 2009, Richard Stallman wrote:

> For most files, the type can be determined from the file name and
> contents.  

That is what mml.el does.

> The simple interface should be able to do everything automatically.
> Maybe just accepting mml's default type would do the right job.

For most types, it is okay.  But e.g. for "README" text/plain +
disposition=inline is much more suitable than application/octet-stream
+ disposition=attachment.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sending attachments

[Richard Stallman]

    There are many examples in emacs-devel:

    /var/spool/news/gmane/emacs/devel# grep '^Content-Disposition:.*inline.*filename' *|wc -l
    40

If I search my incoming mail over a long enough period,
I suppose I would see them.

    "disposition" is more or less a recommendation for the receiving agent
    how to display it.

    > Both rmailmm and Etach display some text parts inline, and they
    > don't need to see disposition=inline to do it.

    Neither does Gnus (and probably MH-E, too).  Viewing inline
    vs. attachment can be toggled interactively or specified through
    `mm-inline-override-types'.

In theory, that kind of recommendation might be useful.
But in practice, since the readers decide heuristically
whether to display inline, users mostly have no reason
to go out of their way to offer a recommendation.
It is better normally not to ask.

Re: Sending attachments

[Stephen J. Turnbull]

Richard Stallman writes:

 >     Neither does Gnus (and probably MH-E, too).  Viewing inline
 >     vs. attachment can be toggled interactively or specified through
 >     `mm-inline-override-types'.
 > 
 > In theory, that kind of recommendation might be useful.
 > But in practice, since the readers decide heuristically

True, but shouldn't we focus on users of smarter readers, and on our
own use cases?  Most Emacs users don't use such dumb readers.  They
use Gnus or another advanced implementation which will normally
respect the recommendation.

 > whether to display inline, users mostly have no reason
 > to go out of their way to offer a recommendation.
 > It is better normally not to ask.

That may be true in many users' practice.  However, I find myself
offering a recommendation about 10-20% of the time, because I disagree
with the default.  For example, some projects include images.  I
generally do not want a new version of an image displayed in the
buffer, I want it saved to the project tree.  But when I'm sending
mail to a local users' group of the last meeting with pix of
somebody's system, I often do want it inlined.  I've been asked how I
do that by non-Emacs users on several occasions, so I know that there
are readers out there that do respect this header.

Patches are another example.  Sometimes patches are intended to be
reviewed, but discouraging cut and paste from mail buffers (of
non-Emacs MUAs) is a good idea since they often munge the text of both
patches and 

Sure, the user can (if they're lucky or wilful enough to be using a
good MUA like Gnus) toggle the display or save an inlined attachment
to a file if they want.  But it takes me ~0.2 seconds (1 keystroke) to
accept the default 80% of the time when it really doesn't matter, ~1
second (1 keystroke) to accept the default when it matters, and ~2
seconds (2 keystrokes with completion) to change it.

I think that's a small cost to advertise this feature, and give the
expert user the option by default.

I realize that there are users with disabilities etc such that the
cost is much higher.  However, I suggest they may be better served by
a feature that evaluates the quality of the default offered, and short
circuits the question when the program is "pretty sure" the default is
correct.  Eg, I don't think anybody really would want tar.gz displayed
inline by default.  Ditto large PDFs.

It would also be possible to specify a customizable alist of MIME
types with values 'attachment or 'inline, allowing the user to specify
ones that should automatically be given a particular disposition.
Something like that must already be part of MML, although if it's
customizable I didn't find it.

This may be way more complex than you would like, of course.

Thing is, that complexity is going to pop up at every turn as you
develop these features.

Re: Sending attachments

[Jason Rumney]

Richard Stallman wrote:
> But in practice, since the readers decide heuristically
> whether to display inline, users mostly have no reason
> to go out of their way to offer a recommendation.
> It is better normally not to ask.
>   

A good interface might  be to normally only prompt for the filename, but 
if a prefix argument is given then prompt for disposition, content-type 
and description also.  Then users would have a simple interface, but can 
still access the full functionality if they want.

Re: Sending attachments

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 10 Jul 2009 18:02:28 +0900
> Cc: Reiner Steib <Reiner.Steib@gmx.de>, emacs-devel@gnu.org
> 
> Thing is, that complexity is going to pop up at every turn as you
> develop these features.

True.  Which is why I thought the intent was to create something
exceedingly simple, e.g.:

  . a single command to attach a file, perhaps with C-u that allows
    finer control on MIME headers (see Jason's proposal not long ago)

  . a single command to save one attachment to a disk file, perhaps
    with C-u that would run a program on the data rather than saving
    it

Anything more complex than that is really going to resemble existing
code in mml and elsewhere, and is not worth another from-scratch
effort, IMO.

Re: Sending attachments

[Jason Rumney]

Eli Zaretskii wrote:
> Anything more complex than that is really going to resemble existing
> code in mml and elsewhere, and is not worth another from-scratch
> effort, IMO.
>   

Even the simple case involves a lot of code in the background to encode 
and provide the correct headers, so it is not worth another from-scratch 
effort. My suggestion was intended to be about putting a simple 
interface in front of mml, since the main objection to using that for 
mail-mode seems to be that the interface is too complex, and if we can 
overcome that, we can avoid adding yet another mime library into Emacs.

The other things to address are hiding the mml code it inserts (I'd 
suggest a file icon image for graphical displays, or buttonized 
[Attached File] for text mode, but RMS has expressed a preference for 
seeing the actual base64 or quoted-printable content that would be sent, 
so another option is to immediately call the function that transforms 
mml to actual mime instead of calling it in the send hook).

Re: Sending attachments

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Date: Fri, 10 Jul 2009 18:02:28 +0900
 > > Cc: Reiner Steib <Reiner.Steib@gmx.de>, emacs-devel@gnu.org
 > > 
 > > Thing is, that complexity is going to pop up at every turn as you
 > > develop these features.
 > 
 > True.  Which is why I thought the intent was to create something
 > exceedingly simple, e.g.:

That simplicity drove me nuts as a Mule maintainer, because it didn't
try to defend against users who went beyond the parameters sendmail.el
was ready to deal with.  Eg, I would tell somebody to send a bug
report using M-x report-xemacs-bug.  That uses sendmail.el because
Gnus and VM are both in the package distribution of XEmacs.  They'd
put non-ASCII in the header because it was a phrase they were having
problems getting Mule to handle correctly, Mule would encode it to
(raw, not RFC 2047) KOI8 or something, and it would take down the bug
list because (at that time) Mailman assumed ASCII in the headers of
mail coming off the wire, and threw an exception if it didn't get it.
(Now we just get mojibake, but we've fixed our bug reporter to say "if
possible we would really appreciate if you would kill this buffer,
customize `mail-composition-agent' and start your report over" because
really people do want to attach files, sometimes with non-ASCII names,
with their reports.)

OK, so now you fix mail-mode to deal with this.  You have two options:
error on non-ASCII in the headers, or RFC 2047 encode.  This is
non-trivial if you want to be RFC conformant, because you SHOULD use
quoted printable encoding for languages like French that use ASCII
supersets, and SHOULD use BASE64 for languages like Hebrew that don't.
(In practice this is usually done by looking at the fraction of ASCII
characters, rather than by determining the language.)  See RFC 2119
for the official definitions of requirement levels of capitalized
terms like SHOULD and MUST; IMHO a SHOULD is pretty strong.

Good, good, we're making progress (at the expense of a couple hundred
lines of code unless you grab rfc2047.el from Gnus -- which is what
Ken'ichi's 10-line .emacs hook does), whose usage assume several other
libraries in the usual Gnus-y way, and is 35KB or so by itself).

OK, so now we add an attachment feature.  No problem, right?  We
already handle RFC 2047, so our headers are OK, right?  Wrong.  RFC
2047 *specifically* forbids use of the encoding it defines to specify
file names in MIME headers.  This is a MUST NOT; a failure to conform
means you have a non-conformant MUA.  This is a boolean standard, your
MUA flunks, it's not "a little bit non-conformant".

OK. so now we have a choice.  You can error on an attempt to use a
non-ASCII filename, or you can implement RFC 2231.  More complexity,
rfc2231.el is 10KB.  Or you could munge the file name in some way and
instruct the recipient to change it back, or ask the sender to change
it.

Sure, you could stop short of a full implementation of all the RFCs
related to these "minimal features" you want, but where?  Figuring out
what to to include and what not to include, and introducing code to
check for and refuse unsupported requests from the user is
non-trivial, itself, and IMO should be based on an even better
knowledge of the RFCs than simply implementing the whole RFC.

You could say, oh, we don't have to do that.  And you're right ... but
IMO a non-RFC-conforming product really isn't something you want to
distribute as part of Emacs.

Is it really worth dealing with all this when as far as Miles and I
can tell, the sendmail.el UI (including hooks and keyboard macros) is
a 100% compatible subset of the Message mode UI?  Wouldn't it be a
better idea for one of the few serious Mail mode users to just try
Message mode for a few days, and fix any problems that show up?
Reading the RFCs is not easy.

Richard's point about complexity and modularity is a good one, of
course, but Message mode isn't that complex and is reasonably
well-factored.  The complexity comes in on the reader side of Gnus,
and I admit that's an impenetrable thicket of code.  But then, it's
much much easier to write something that just produces conformant
messages in RFC 822 format than it is to have a multibackend reader
that not only deals with netnews and a host of mail formats, but also
the hideous stuff that is produced by Microsoft and Yahoo! mailers,
not to mention spammers.

Re: Sending attachments

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     > message.el forces the loading of many other packages (I sent the list
>     > before).  So its effective complexity includes all of them.  It is
>     > tied in with Gnus, and can't be maintained on its own.
>
>     Message mode is actively maintained by the Gnus maintainers, so this
>     point is irrelevant.
>
> It is not a good thing that message mode can only be maintained by the
> Gnus maintainers.

Proper maintenance requires a familiarity with the relevant RFCs; the
Gnus maintainers have this expertise, and we should leverage this to the
greatest extent possible.

Thus, even if we keep mail-mode, due to vested interests, I am opposed
to adding a "simple" (and possibly standards-noncompliant) mime library.
We should instead make use of mml.el, because the Gnus maintainers have
already expended effort making it standards-compliant.

Re: message-mode / mail-mode

[Stefan Monnier]

>>>> Context-sensitive commands are good but in message-mode they seem to
>>>> require that the "--text follows this line--" separator line exists.
> [...]
>>> You should set the variable `mail-header-separator' to ""; message-mode
>>> also pays attention to this variable.
>> Still, message-mode needs to be fixed so this is not necessary.
> Please elaborate.

message-mode should accept both the empty line and "--text follows this
line--" as a header-terminator.


        Stefan

Re: Sending attachments

[Stefan Monnier]

>> As far as I'm concerned, mail-mode should be moved to the
>> `obsolete' directory.
> I hope that's a joke.

It's most definitely not.  AFAIK, message-mode is a proper superset of
mail-mode, so mail-mode is a prime candidate for obsolescence.

> Especially since there's no mail-mode.el to move.

I see you've figured out why I said mail-mode and not mail-mode.el.


        Stefan

Re: Sending attachments

[Stefan Monnier]

>     As far as I'm concerned, mail-mode should be moved to the
>     `obsolete' directory.
> Please don't do that!

Why not?  More specifically, what do you think would break if we did
something along the lines of:

   (define-obsolete-function-alias 'mail-mode 'message-mode)


-- Stefan

Re: Sending attachments

[Stefan Monnier]

> I can adapt and install Handa's code.  Before I do,
> does anyone see a problem with the change he proposes?

Feel free to install it.  Note that it brings mail-mode closer to
message-mode, relying on the same MIME code, so I'm very favorable
to it.  I'd go even further and implement all the remaining missing
features.  It can be done with even less code (just a defalias).


        Stefan

Re: Sending attachments

[Richard Stallman]

     > In theory, that kind of recommendation might be useful.
     > But in practice, since the readers decide heuristically

    True, but shouldn't we focus on users of smarter readers, and on our
    own use cases?

The readers that decide heuristically are the smarter readers, at
least in my opinion.  I would not want to use one that always obeys
the specified disposition.

    That may be true in many users' practice.  However, I find myself
    offering a recommendation about 10-20% of the time, because I disagree
    with the default.

I am not opposed to having a more complex interface like the current one
of mml-attach-file.  I just want a simpler one to be the usual one.
Using C-u to make it ask the other questions seems fine.

Re: Sending attachments

[Richard Stallman]

    The other things to address are hiding the mml code it inserts (I'd 
    suggest a file icon image for graphical displays, or buttonized 
    [Attached File] for text mode, but RMS has expressed a preference for 
    seeing the actual base64 or quoted-printable content that would be sent, 
    so another option is to immediately call the function that transforms 
    mml to actual mime instead of calling it in the send hook).

I think it would be clearer that way, but I don't think it's important
enough to make a big deal about.

This can be done with a simple extension to mml.
mml-attach-file could optionally convert to mime when it finishes.

mml-attach-file could also detect that the message has already been
converted to mime, in which case it could unconvert using mime-to-mml
before attaching the file.

This, together with the suggestion to ask all the questions only with
C-u, would make it do what I have in mind.

Re: Sending attachments

[Stefan Monnier]

> My gray hair says there ain't no such thing.  If it's more powerful
> and sophisticated, there's some price to pay.

So your argument is hypothetical, rather than based on concrete
problems.  To me that counts as "one vote to make mail-mode obsolete".


        Stefan

Re: Sending attachments

[Stefan Monnier]

>> message.el forces the loading of many other packages (I sent the list
>> before).  So its effective complexity includes all of them.  It is
>> tied in with Gnus, and can't be maintained on its own.

Then the conclusion should be that we should work with the Gnus
maintainers to improve the modularity of the code relevant to
message-mode.  AFAIK they are in favor of such an effort (the intention
of message-mode has always been to supercede mail-mode and stay
independent from Gnus, IIUC, which is why it has its own manual).

As a matter of fact I think message-mode is already fairly well
modularized, when you consider the fact that it's developed by people
who have no real need to care about other MUAs than Gnus.

>     Message mode is actively maintained by the Gnus maintainers, so this
>     point is irrelevant.
> It is not a good thing that message mode can only be maintained by the
> Gnus maintainers.

FWIW, I'm not a Gnus maintainer, but I have made changes to message-mode
and to the MIME code of Gnus, so I don't think it's fair to say that it
can only be maintained by the Gnus maintainers.


        Stefan

Re: Sending attachments

[Stefan Monnier]

> The real issue that I raised is sending attachments with Mail mode.

Actually, not really.  I think "the real issue" if sending attachments
(and non-ASCII text, including in headers) in "the default
mail-composition interface".  *Very* few users actually choose
mail-mode.

> Installing Etach will deal with that.  This actually does not involve
> a change in sendmail.el, since Etach is modular.

A simpler change is to make message-mode the default UI.
This thread seems to show that noone knows of any actual difference that
users would notice (other than being able to attach files and stuff, of
course).

So I think the first step should be to change mail-user-agent to
default to message-user-agent.
The next step will then be to make Rmail use message-mode as well
(which may require some changes to message-mode, of course).


        Stefan

Re: Sending attachments

[Alfred M. Szmidt]

   So I think the first step should be to change mail-user-agent to
   default to message-user-agent.  The next step will then be to make
   Rmail use message-mode as well (which may require some changes to
   message-mode, of course).

PLEASE DO NOT DO THIS!  People using mail-mode have already expressed
that they prefer it over message-mode, please respect that!

Re: Sending attachments

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Miles Bader <miles@gnu.org>,  cyd@stupidchicken.com,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 11 Jul 2009 14:50:59 -0400
> 
> > My gray hair says there ain't no such thing.  If it's more powerful
> > and sophisticated, there's some price to pay.
> 
> So your argument is hypothetical, rather than based on concrete
> problems.

Not hypothetical, based on experience.

> To me that counts as "one vote to make mail-mode obsolete".

Yes, I used to hold such naive ideas as well: that an argument isn't
valid unless it is based on provable facts.  I'm much better now,
thank you.

Re: Sending attachments

[Leo]

On 2009-07-11 20:41 +0100, Alfred M. Szmidt wrote:
>    So I think the first step should be to change mail-user-agent to
>    default to message-user-agent.  The next step will then be to make
>    Rmail use message-mode as well (which may require some changes to
>    message-mode, of course).
>
> PLEASE DO NOT DO THIS!  People using mail-mode have already expressed
> that they prefer it over message-mode, please respect that!

Don't worry.
We can put it in emacswiki so that it will be available for good.

-- 
Leo's Emacs uptime: 31 days, 13 hours, 21 minutes, 13 seconds

Re: Sending attachments

[Lennart Borgman]

On Sun, Jul 12, 2009 at 5:05 AM, Leo<sdl.web@gmail.com> wrote:
> On 2009-07-11 20:41 +0100, Alfred M. Szmidt wrote:
>>    So I think the first step should be to change mail-user-agent to
>>    default to message-user-agent.  The next step will then be to make
>>    Rmail use message-mode as well (which may require some changes to
>>    message-mode, of course).
>>
>> PLEASE DO NOT DO THIS!  People using mail-mode have already expressed
>> that they prefer it over message-mode, please respect that!
>
> Don't worry.
> We can put it in emacswiki so that it will be available for good.

I think you are misunderstanding. The code will still be distributed
with Emacs but will not be used by default.

If you think something is missing in message-mode then please consider
contributing code for what you miss.

Re: Sending attachments

[Richard Stallman]

    Why not?  More specifically, what do you think would break if we did
    something along the lines of:

       (define-obsolete-function-alias 'mail-mode 'message-mode)

I may need to maintain Emacs again; past history shows other
maintainers come and go.  If that happens, I want to have Mail mode,
not depend on something that is part of Gnus.

Please don't mess this up.


I am considering moving some code (including mml) outside Gnus so that
Gnus will not be an issue for its future maintenance.  (I've done that
to other packages before.)

Re: Sending attachments

[Stefan Monnier]

>    So I think the first step should be to change mail-user-agent to
>    default to message-user-agent.  The next step will then be to make
>    Rmail use message-mode as well (which may require some changes to
>    message-mode, of course).

> PLEASE DO NOT DO THIS!  People using mail-mode have already expressed
> that they prefer it over message-mode,

Most of the people who use mail-mode have not expressed any opinion.
The vast majority of them have no idea they're using mail-mode and that
they have a choice to use something else.

> please respect that!

The very few users who have expressed a preference for mail-mode have
not given any concrete argument for why.  Some developers/maintainers of
mail-mode have expressed their preference for it, indeed, but that's
a different issue.


        Stefan


PS: And to reply to Lennart, when I say "obsolete" that means I have the
intention to get rid of the corresponding code as well, tho as we know
such things take time, and even more so in cases like this one where the
maintainers are emotionally atached to their code and happen to be some
of the most important Emacs developers.

Re: Sending attachments

[Stefan Monnier]

>     Why not?  More specifically, what do you think would break if we did
>     something along the lines of:
>        (define-obsolete-function-alias 'mail-mode 'message-mode)
> I may need to maintain Emacs again; past history shows other
> maintainers come and go.  If that happens, I want to have Mail mode,
> not depend on something that is part of Gnus.

Please explain why you consider "part of Gnus" to be a negative attribute.

> I am considering moving some code (including mml) outside Gnus so that
> Gnus will not be an issue for its future maintenance.  (I've done that
> to other packages before.)

As I said, making message-mode (and related libraries) more generic
is good.  I fully support it, and I think the Gnus maintainers would
not oppose it either.


        Stefan

Re: Sending attachments

[Richard Stallman]

    > I may need to maintain Emacs again; past history shows other
    > maintainers come and go.  If that happens, I want to have Mail mode,
    > not depend on something that is part of Gnus.

    Please explain why you consider "part of Gnus" to be a negative attribute.

There are two reasons.  First, its primary source is maintained
outside of Emacs.  Second, the people who work on it do not hesitate
to add dependencies between one part and another, with results that
one quickly sees on studying files from Gnus.

Another problem with Gnus maintenance is that, whenever they see the
need for some other feature, they add it to Gnus, without discussing
it with the Emacs maintainer, and without attempting to make the
package independent of Gnus.

Another problem is that a lot of the code is ugly and hard to
understand.  While this CAN happen to any code, I think the separate
maintenance of Gnus encourages it, since it discourages other people
than the Gnus developers from working on the code at all.

I decided to make rfc2047.el work outside Gnus.  Most of the
dependence on other Gnus files existed for no good reason at all.
However, a couple of functions in mm-util do real work that seems
important.  They are a specialized facility in the same file with lots
of low-level XEmacs compatibility functions used in Gnus.  Perhaps I
will just split that file.

Re: Sending attachments

[Leo]

On 2009-07-14 11:44 +0100, Richard Stallman wrote:
> There are two reasons. First, its primary source is maintained outside
> of Emacs. Second, the people who work on it do not hesitate to add
> dependencies between one part and another, with results that one
> quickly sees on studying files from Gnus.
> 
> Another problem with Gnus maintenance is that, whenever they see the
> need for some other feature, they add it to Gnus, without discussing
> it with the Emacs maintainer, and without attempting to make the
> package independent of Gnus.
>
> Another problem is that a lot of the code is ugly and hard to
> understand. While this CAN happen to any code, I think the separate
> maintenance of Gnus encourages it, since it discourages other people
> than the Gnus developers from working on the code at all.
>
> I decided to make rfc2047.el work outside Gnus. Most of the dependence
> on other Gnus files existed for no good reason at all. However, a
> couple of functions in mm-util do real work that seems important. They
> are a specialized facility in the same file with lots of low-level
> XEmacs compatibility functions used in Gnus. Perhaps I will just split
> that file.

What Richard has said makes a lot of sense. There are different
standards on the quality of code that can be included in Emacs.
Unfortunately many think that 'it works' is the standard. Also many libs
stop developing because they have been included. We shouldn't be afraid
to recycle them if that's where they belong.

-- 
Leo's Emacs uptime: 33 days, 23 hours, 24 minutes, 49 seconds

Re: Sending attachments

[Stephen J. Turnbull]

Richard Stallman writes:

 > There are two reasons.  First, its primary source is maintained
 > outside of Emacs.

I don't see how that's a reason not to use the perfectly good Message
mode that is a part of Emacs.  If you can't persuade them to go along
with your refactorings, you still will be starting from a much more
featureful MUA, one which is well-debugged and highly conformant.

 > Another problem is that a lot of the code is ugly and hard to
 > understand.  While this CAN happen to any code, I think the
 > separate maintenance of Gnus encourages it, since it discourages
 > other people than the Gnus developers from working on the code at
 > all.

That's certainly not my experience.  I'd say about half of the hackers
closest to me over the last 10 years have been at least occasional
contributors to Gnus.  And they've been really good citizens in
general even though their main interests are rather different from
"core" Emacs developers.

It seems to me that both Gnus and Emacs would benefit from you
pow-wowing with Miles Bader and anybody else who works on Gnus-Emacs
integration, and make the points about refactoring and maintainability
to them.  Ask them to represent your needs (ie, only the basic
features, more emphasis on refactoring and maintainability in Message
mode).  It's worth trying to avoid the duplication, for Message mode,
at least.

Re: Sending attachments

[Jonathan Rockway]

* On Tue, Jul 14 2009, Richard Stallman wrote:

> Another problem with Gnus maintenance is that, whenever they see the
> need for some other feature, they add it to Gnus, without discussing
> it with the Emacs maintainer, and without attempting to make the
> package independent of Gnus.

I think they want something that works first.  Once the code works, it
can be refactored to be generic.

Some people don't want to discuss every minute detail of the code before
they implement it.  The bike shed can be painted after it's built.

(Look at how long this thread is.  Did all this discussion actually
accomplish anything, or was it mostly a waste of time?)

Anyway, I think the solution is to cleanup the Gnus code as needed
rather than completely rewrite it from scratch and call it something
else.  I can't speak for the Gnus developers, but I'm sure they would
appreciate the help.  The point of free software is that the users can
improve the code; so that it works better, or so that it can be used
somewhere else more generically.  Right?

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"

Re: Sending attachments

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> Another problem with Gnus maintenance is that, whenever they see the
> need for some other feature, they add it to Gnus, without discussing
> it with the Emacs maintainer, and without attempting to make the
> package independent of Gnus.
>
> Another problem is that a lot of the code is ugly and hard to
> understand.  While this CAN happen to any code, I think the separate
> maintenance of Gnus encourages it, since it discourages other people
> than the Gnus developers from working on the code at all.

Would Gnus maintainers strongly resist to the idea of maintaining Gnus
within Emacs?  

-- 
 Bastien

Re: Sending attachments

[Stefan Monnier]

>> I may need to maintain Emacs again; past history shows other
>> maintainers come and go.  If that happens, I want to have Mail mode,
>> not depend on something that is part of Gnus.

>     Please explain why you consider "part of Gnus" to be
>     a negative attribute.

> There are two reasons.  First, its primary source is maintained
> outside of Emacs.  Second, the people who work on it do not hesitate
> to add dependencies between one part and another, with results that
> one quickly sees on studying files from Gnus.

I'm sure they'll appreciate help in reducing dependencies between modules.

> Another problem with Gnus maintenance is that, whenever they see the
> need for some other feature, they add it to Gnus, without discussing
> it with the Emacs maintainer, and without attempting to make the
> package independent of Gnus.

Actually, they originally did make a specific effort to make
message-mode independent from Gnus so that it can replace mail-mode.
And then mail-mode stayed and so message-mode evolved under the pressure
of nothing else than Gnus.

> Another problem is that a lot of the code is ugly and hard to
> understand.  While this CAN happen to any code, I think the separate
> maintenance of Gnus encourages it, since it discourages other people
> than the Gnus developers from working on the code at all.

I don't know about you, but I'm a lot more afraid of CC-mode's code than
of Gnus's.  If you agree with that and following your reasoning, we
should have kept the old c-mode.el.


        Stefan

Re: Sending attachments

[Alfred M. Szmidt]

Nobody (atleast I do not) has no issues with setting mail-user-agent
to message-user-agent; since that allows people who prefer mail-mode
to continue to use it.  And can be easily reverted at a later date.

But your insistance to remove a perfectly usable mode that people
actually prefer, and wish to continue to use _and_ maintain, is not
productive.


There are far more important things to work on in Emacs.  Org mode has
many modes that already exist in Emacs which are not very popular.  I
am in particular thinking of table-mode and footnote-mode, which are
very useful modes, but Org mode has similar modes that are better.

Re: Sending attachments

[Richard Riley]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Nobody (atleast I do not) has no issues with setting mail-user-agent
> to message-user-agent; since that allows people who prefer mail-mode
> to continue to use it.  And can be easily reverted at a later date.
>
> But your insistance to remove a perfectly usable mode that people
> actually prefer, and wish to continue to use _and_ maintain, is not
> productive.

As an observer this argument you keep putting up is very weak.

Not one person has offered a reason why they can not use the subset of
message-mode which encompasses mail-mode.

It appears, from the outside, simply ludicrous to maintain TWO suites of
SW one of which is a *poorer* and less meticulous subset of the other
purely because, well,  - actually there have been zero usability reasons
put forwards - only "because I said so" foot stomping reasons.

Re: Sending attachments

[Stefan Monnier]

> Nobody (atleast I do not) has no issues with setting mail-user-agent
> to message-user-agent;

Which is wy I did it.

> But your insistance to remove a perfectly usable mode that people
> actually prefer, and wish to continue to use _and_ maintain, is not
> productive.

Where did I insist to remove it?  It's still there, isn't it?
I do indeed want to obsolete it.  I also want to make strings and
defconst immutable, and let be lexically scoped, and ...
Some of those will hopefully happen within my lifetime, others not.

Obsoleting mail-mode actually requires some amount of technical work,
and I have better things to do, so don't expect it to happen any time
soon, especially since it would require an enormous amount of
social-work along side.

But I do oppose very strongly the addition of etach: if someone wants to
add MIME features to mail-mode, it should be by bringing mail-mode and
message-mode closer to each other.


        Stefan

Re: Sending attachments

[Ted Zlatanov]

On Tue, 14 Jul 2009 11:17:33 -0500 Jonathan Rockway <jon@jrock.us> wrote: 

JR> * On Tue, Jul 14 2009, Richard Stallman wrote:

>> Another problem with Gnus maintenance is that, whenever they see the
>> need for some other feature, they add it to Gnus, without discussing
>> it with the Emacs maintainer, and without attempting to make the
>> package independent of Gnus.

JR> Anyway, I think the solution is to cleanup the Gnus code as needed
JR> rather than completely rewrite it from scratch and call it something
JR> else.  I can't speak for the Gnus developers, but I'm sure they would
JR> appreciate the help.  The point of free software is that the users can
JR> improve the code; so that it works better, or so that it can be used
JR> somewhere else more generically.  Right?

(speaking as a Gnus and Emacs contributor)

Right.  I have not seen anything concrete about what needs to be fixed,
refactored, etc. in Gnus.  There aren't many developers actively
contributing to Gnus, either, so making major changes will take a long
time and needs to be well-justified.  Gnus welcomes new developers with
open hooves...er...arms, but the code complexity is probably
intimidating to most.

Pulling code out of Gnus has the downside that it then needs to be
inside Emacs, but XEmacs may not have it.  XEmacs compatibility has (as
long as I can remember) been a Gnus goal.  How should Gnus and Emacs
deal with this?  I hope "drop XEmacs support" is not an option.

Ted

Re: Sending attachments

[Frank Schmitt]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Pulling code out of Gnus has the downside that it then needs to be
> inside Emacs, but XEmacs may not have it.  XEmacs compatibility has (as
> long as I can remember) been a Gnus goal.  How should Gnus and Emacs
> deal with this?  I hope "drop XEmacs support" is not an option.

Is XEmacs compatibility really worth the trouble? How many XEmacs users
are still out there?

-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.

Re: Sending attachments

[Stefan Monnier]

> Pulling code out of Gnus has the downside that it then needs to be
> inside Emacs, but XEmacs may not have it.

Don't worry about this part: the changes (supposedly) needed don't
intend to remove any code, just better modularize it (e.g. so that
message-mode can be self-standing without importing (transitively)
gnus-*.el packages).


        Stefan

Reducing Gnus dependencies in message.el (was: Sending attachments)

[Reiner Steib]

On Sat, Jul 04 2009, Richard Stallman wrote:

>     > I object strenuously to the idea of replacing the very simple Mail
>     > mode with something complex from Gnus.
>
>     It's a question of necessary complexity.
>
> I don't think so.  Look at all the libraries message.el loads.
>
>
>     (require 'hashcash)
>     (require 'canlock)

We can eliminate these by using autoloads.  canlock is used for news
postings in Gnus by default.  Hashcash is an optional feature for
mail.

>     (require 'mailheader)

[mailheader.el is not part of Gnus, but part of Emacs.]  Required to
insert correctly formated (quoting, folding, ...) headers into mail
message buffers.

;;; mailheader.el --- mail header parsing, merging, formatting
[...]
;;; Commentary:

;; This package provides an abstraction to RFC822-style messages, used in
;; mail, news, and some other systems.  The simple syntactic rules for such
;; headers, such as quoting and line folding, are routinely reimplemented
;; in many individual packages.  This package removes the need for this
;; redundancy [...]

>     (require 'gmm-utils)

;;; gmm-utils.el --- Utility functions for Gnus, Message and MML

... is an attempt to reduce Gnus dependencies from Message and MML
files.

>     (require 'nnheader)
>
>       That loads
> 	(require 'mail-utils)

[mailutils.el is not part of Gnus, but part of Emacs].  It provides
utility functions for mail handling.  Both, rmail.el and sendmail.el
use it.  I see no point in avoiding using it.

;;; mail-utils.el --- utility functions used both by rmail and rnews
[...]
;; Utility functions for mail and netnews handling.  These handle fine
;; points of header parsing.

> 	(require 'mm-util)

;;; mm-util.el --- Utility functions for Mule and low level things
... needed for MIME.

> 	(require 'gnus-util)

I will try to eliminate this dependency.

>     ;; This is apparently necessary even though things are autoloaded.
>     ;; Because we dynamically bind mail-abbrev-mode-regexp, we'd better
>     ;; require mailabbrev here.
>     (if (featurep 'xemacs)
> 	(require 'mail-abbrevs)
>       (require 'mailabbrev))

Handling expansions of mail aliases.

>     (require 'mail-parse)

For parsing and encoding headers and body correctly.

>     (require 'mml)

Required for MIME handling (e.g. sending attachments).

>     (require 'rfc822)

[rfc822.el is not part of Gnus, but part of Emacs.]  Uses to ensure that
address headers are RFC822-compliant.  Is also used in rmail.el.

>     (require 'ecomplete)

We can eliminate these by using autoloads.  ecomplete is optional.

> I don't want to replace the simple sendmail.el with this tremendous
> pile of complexity.
>
> message.el is also 8000 lines long, where sendmail.el is under 2000
> lines.  I expect that sending attachments won't require more than 200
> lines.

Doing all aspects of MIME mostly correct is not quite simple.  Many
MUAs (Mail User Agent) have severe bugs WRT this.  When reading about
non-trivial topics in the relevant newsgroups, most of the time only
mutt and Gnus do the right thing.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sending attachments

[Richard Stallman]

     > There are two reasons.  First, its primary source is maintained
     > outside of Emacs.

    I don't see how that's a reason not to use the perfectly good Message
    mode that is a part of Emacs.

Someone asked me why I see this as a problem, and I explained why.
You may not see it as a problem, but the point is that I do.

    It seems to me that both Gnus and Emacs would benefit from you
    pow-wowing with Miles Bader and anybody else who works on Gnus-Emacs
    integration, and make the points about refactoring and maintainability
    to them.

I would like to see progress in this direction, and I am willing to do
a certain amount of work to help it.  However, at present I have
nothing to specific suggest, because I know very little about the code
of Gnus.  Its complexity has discouraged me from looking at it except
in cases of need.

On a few occasions I have looked at part of Gnus.  Each time what I
encountered was daunting complexity, each part interacting with many
other parts.  I tried my best to reduce the amount of code I had to
look at.

I don't know how many other parts of Gnus are comparable to rfc2047.el
in that they are useful general facilities and ought to be made
separate and modular.  If Gnus developers are interested in doing work
to make these files modular, I'm interested in looking for candidates.

Re: Sending attachments

[Richard Stallman]

    I don't know about you, but I'm a lot more afraid of CC-mode's code than
    of Gnus's.  If you agree with that and following your reasoning, we
    should have kept the old c-mode.el.

CC mode stays in its own area of functionality -- it has no tendency
to spawn replacements for other parts of Emacs.  I am confident that,
if Alan thinks some new non-C-specific feature is needed for CC mode,
he will discuss the right way to develop it as a new module.

Thus, while its complexity is a problem (and will cause difficulty if
Alan disappears), it is a contained problem.

Re: Sending attachments

[Richard Stallman]

    > There are two reasons.  First, its primary source is maintained
    > outside of Emacs.  Second, the people who work on it do not hesitate
    > to add dependencies between one part and another, with results that
    > one quickly sees on studying files from Gnus.

    I'm sure they'll appreciate help in reducing dependencies between modules.

I am sure they would, but that doesn't excuse creating all those
dependencies.

    Actually, they originally did make a specific effort to make
    message-mode independent from Gnus so that it can replace mail-mode.

Maybe they wanted it to replace Mail mode, but they didn't ask me if I
wanted to replace it.  They should have talked with me first, and then
I would have said, "Please extend Mail mode, and please talk with me
about what you want to do."

Re: Sending attachments

[Stephen J. Turnbull]

Frank Schmitt writes:

 > Is XEmacs compatibility really worth the trouble? How many XEmacs users
 > are still out there?

First, XEmacs compatibility is not usually that great a burden.
Certainly, when you're trying to support bleeding edge features (viz.
preview-latex), you run into problems.  But mostly the work is already
done, and with a few exceptions where XEmacs led Emacs by 5 to 10
years in introducing an API and Emacs deliberately varied, we do
(eventually) sync by adding the feature with the Emacs-style APIs.

Second, there are still plenty of XEmacs and SXEmacs users to justify
*keeping* existing features.  Several GNU/Linux distros have tried to
drop XEmacs packages or deemphasize them in one way or another, and
gotten *strong* pushback from their users.  XEmacs also still has a
strong following in two large companies that I know of, I believe
because they consider it much easier to maintain local extensions to
XEmacs.  They don't even try with Emacs.  I have to think that there
are a lot of such users out there, who probably don't participate much
in free software channels, they just use it.

There's also the question of *contributors* vs. users.  XEmacs (and
even more so, SXEmacs) contributors have been quite loyal, due to the
large investment required to work on internals of any Emacsen.  So
making XEmacs less usable would quite likely result in a loss of
developers to the entire community rather than a flow of developers to
Emacs proper.

Anyway, the question is if merging Gnus code into Emacs would result
in a purge of XEmacs compatibility code.  Sometimes Richard uses
expressions that suggest that might happen, but AFAICT his opinion on
the matter is that he thinks mixing XEmacs compatibility code with
application implementation is unclean, and he advocates *separating*
them out.  Of course if XEmacs compatibility modules are not going to
be maintained, he prefers them to be dropped, and I'm sure he'd prefer
that the effort be devoted to Emacs proper -- but after all, that's
the contributor's choice.

Re: Sending attachments

[Jason Rumney]

Stephen J. Turnbull wrote:
> Anyway, the question is if merging Gnus code into Emacs would result
> in a purge of XEmacs compatibility code.
To clarify, the question is about merging SOME Gnus code into Emacs. I 
would see it working the same way as the code that has been merged from 
Gnus already, where the Gnus folk continue to offer their own packages 
for XEmacs and older versions of Emacs that include the files that were 
merged into Emacs plus any compatibility code that has been modularized 
and doesn't need to be in the Emacs repository.

Re: Sending attachments

[Stephen J. Turnbull]

Richard Stallman writes:

 > Someone asked me why I see this as a problem, and I explained why.
 > You may not see it as a problem, but the point is that I do.

Sure.  And my point is that I don't understand why you see it as a
problem.  I like to understand these things, and I'm at a loss to come
up with a sane rationalization.  So I feel very very stuck.  That
would be OK if it were just me, but I don't think I'm the only one who
feels that way.  In fact I think some of those who are feeling stuck
are important contributors to Emacs, and to free software.

 >     It seems to me that both Gnus and Emacs would benefit from you
 >     pow-wowing with Miles Bader and anybody else who works on Gnus-Emacs
 >     integration, and make the points about refactoring and maintainability
 >     to them.
 > 
 > I would like to see progress in this direction, and I am willing to do
 > a certain amount of work to help it.  However, at present I have
 > nothing to specific suggest, because I know very little about the code
 > of Gnus.

What you've posted about rfc2047.el already goes way beyond
"nothing". :-)

 > Its complexity has discouraged me from looking at it except in
 > cases of need.

Unfortunately, that complexity is mostly a reflection of the problem
domain.  It is *not* merely a reflection of the number of features of
Gnus; reducing the complexity of your requirements will not reduce the
complexity of a RFC conforming implementation proportionately.  For
example, you personally may have no need to send non-ASCII characters
in headers.  Nevertheless, the MUA you use must check for them,
because they might be present in an automatically generated header
(eg, a reply).  Of course you can simplify somewhat by refusing to
implement RFC 2047, and simply have `mail-send' signal an error,
leaving it to the user to clean up the header.  But the check itself
is complexity, and goes beyond what Mail mode has ever done.  And it
gets worse; RFC 2047 by itself is insufficient.  Even if you've
implemented RFC 2047, you need to check whether parameter values of
MIME headers contain non-ASCII, because RFC 2047 itself specifically
prohibits use of RFC 2047 encoded-words in parameters.  Now, you also
need RFC 2231.  Mail is rife with these corner cases.

This is not mere conformance for the sake of conformance.  To give one
example, Mailman for many years had a bug where a non-ASCII character
in a header could cause a whole installation and all of its lists to
become unusable until a sysadmin shunts the offending message out of
the queue.

 > If Gnus developers are interested in doing work to make these files
 > modular, I'm interested in looking for candidates.

Thank you!

Re: Sending attachments

[Ted Zlatanov]

On Thu, 16 Jul 2009 13:19:07 +0800 Jason Rumney <jasonr@gnu.org> wrote: 

JR> Stephen J. Turnbull wrote:
>> Anyway, the question is if merging Gnus code into Emacs would result
>> in a purge of XEmacs compatibility code.
JR> To clarify, the question is about merging SOME Gnus code into Emacs. I
JR> would see it working the same way as the code that has been merged
JR> from Gnus already, where the Gnus folk continue to offer their own
JR> packages for XEmacs and older versions of Emacs that include the files
JR> that were merged into Emacs plus any compatibility code that has been
JR> modularized and doesn't need to be in the Emacs repository.

On Wed, 15 Jul 2009 14:27:46 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Pulling code out of Gnus has the downside that it then needs to be
>> inside Emacs, but XEmacs may not have it.

SM> Don't worry about this part: the changes (supposedly) needed don't
SM> intend to remove any code, just better modularize it (e.g. so that
SM> message-mode can be self-standing without importing (transitively)
SM> gnus-*.el packages).

As long as we're talking about changes local to the Gnus project (not
pulling things out to Emacs itself) I think this is reasonable.  If,
however, we plan to pull libraries out to Emacs, as I think some of the
comments are suggesting, we need to ensure it will not break XEmacs
compatibility.  Thanks for the clarification.

Ted

Re: Sending attachments

[Ted Zlatanov]

On Wed, 15 Jul 2009 21:10:58 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS> I don't know how many other parts of Gnus are comparable to rfc2047.el
RS> in that they are useful general facilities and ought to be made
RS> separate and modular.  If Gnus developers are interested in doing work
RS> to make these files modular, I'm interested in looking for candidates.

If we establish a list of specific things, as Reiner's list for example,
it will be easier to work on it.  As I mentioned, there aren't that many
Gnus developers and refactoring code is a thankless task that tends to
take tons of time.  You should expect this to be a slow process.

Ted

Re: Sending attachments

[Richard Stallman]

    Pulling code out of Gnus has the downside that it then needs to be
    inside Emacs, but XEmacs may not have it.  XEmacs compatibility has (as
    long as I can remember) been a Gnus goal.

1. XEmacs can have these files if its developers want.

2. There could be a Gnus-XEmacs compatibility package
released alongside Gnus.

Re: Sending attachments

[Ted Zlatanov]

On Thu, 16 Jul 2009 12:17:52 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS>     Pulling code out of Gnus has the downside that it then needs to be
RS>     inside Emacs, but XEmacs may not have it.  XEmacs compatibility has (as
RS>     long as I can remember) been a Gnus goal.

RS> 1. XEmacs can have these files if its developers want.

RS> 2. There could be a Gnus-XEmacs compatibility package
RS> released alongside Gnus.

I think Reiner Steib and Stephen Turnbull, among others, need to discuss
this with you and the Emacs maintainers.  I'll go along with whatever
decision the group makes.

Ted

Re: Sending attachments

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > RS> 1. XEmacs can have these files if its developers want.
 > 
 > RS> 2. There could be a Gnus-XEmacs compatibility package
 > RS> released alongside Gnus.
 > 
 > I think Reiner Steib and Stephen Turnbull, among others, need to discuss
 > this with you and the Emacs maintainers.  I'll go along with whatever
 > decision the group makes.

Mike Kupfer should be in the mix, other than that I don't have a
particular opinion on what to do.

Re: Sending attachments

[Richard Stallman]

    If we establish a list of specific things, as Reiner's list for example,
    it will be easier to work on it.  As I mentioned, there aren't that many
    Gnus developers and refactoring code is a thankless task that tends to
    take tons of time.  You should expect this to be a slow process.

I understand that.  My point is, first do no harm.

Since it is hard work to remove these dependencies,
please avoid making more of them.  When you want to add
a new file, ask yourself whether its function is inherently
part of Gnus, or whether it is something general (like rfc2047.el
for example) that you simply want for Gnus.  And if it is the latter,
please write it in a way that doesn't depend on Gnus, and propose
it for inclusion in Emacs.

Re: Sending attachments

[Ted Zlatanov]

On Fri, 17 Jul 2009 09:30:30 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS>     If we establish a list of specific things, as Reiner's list for example,
RS>     it will be easier to work on it.  As I mentioned, there aren't that many
RS>     Gnus developers and refactoring code is a thankless task that tends to
RS>     take tons of time.  You should expect this to be a slow process.

RS> I understand that.  My point is, first do no harm.

RS> Since it is hard work to remove these dependencies,
RS> please avoid making more of them.  When you want to add
RS> a new file, ask yourself whether its function is inherently
RS> part of Gnus, or whether it is something general (like rfc2047.el
RS> for example) that you simply want for Gnus.  And if it is the latter,
RS> please write it in a way that doesn't depend on Gnus, and propose
RS> it for inclusion in Emacs.

I'll try to watch for this in new submissions and in my own work.

Ted

Re: Sending attachments

[Richard Stallman]

rfc2047.el depends on some substantial code in mm-util.el:
mm-charset-to-coding-system and mm-find-mime-charset-region.  I cannot
understand that code, and I am not sure what it is trying to do.  I
understand the doc strings, but they explain only in vague terms.

Can you separate out that functionality into a file by itself, which
does not depend on the rest of Gnus, and clean it up and/or add
comments so that it is clear?

Re: Sending attachments

[Richard Stallman]

    RS> part of Gnus, or whether it is something general (like rfc2047.el
    RS> for example) that you simply want for Gnus.  And if it is the latter,
    RS> please write it in a way that doesn't depend on Gnus, and propose
    RS> it for inclusion in Emacs.

    I'll try to watch for this in new submissions and in my own work.

Thank you.  Things will be a lot better that way.

rfc2047.el dependencies on mm-util.el (was: Sending attachments)

[Reiner Steib]

On Sat, Jul 18 2009, Richard Stallman wrote:

> rfc2047.el depends on some substantial code in mm-util.el:
> mm-charset-to-coding-system and mm-find-mime-charset-region.  I cannot
> understand that code, and I am not sure what it is trying to do.  I
> understand the doc strings, but they explain only in vague terms.

Please elaborate what is not clear...

,----[ <f1> f mm-find-mime-charset-region RET ]
| mm-find-mime-charset-region is a compiled Lisp function in `mm-util.el'.
| (mm-find-mime-charset-region B E &optional HACK-CHARSETS)
| 
| Return the MIME charsets needed to encode the region between B and E.
| nil means ASCII, a single-element list represents an appropriate MIME
| charset, and a longer list means no appropriate charset.
`----

,----[ <f1> f mm-charset-to-coding-system RET ]
| mm-charset-to-coding-system is a compiled Lisp function in `mm-util.el'.
| (mm-charset-to-coding-system CHARSET &optional LBT ALLOW-OVERRIDE SILENT)
| 
| Return coding-system corresponding to CHARSET.
| CHARSET is a symbol naming a MIME charset.  [...]
`----

MIME charsets are not the same as (Emacs) coding systems.  This
function does the mapping and also handles overrides (many MUAs
specify wrong charsets), invalid charsets, etc.

> Can you separate out that functionality into a file by itself, which
> does not depend on the rest of Gnus, and clean it up and/or add
> comments so that it is clear?

rfc2047.el implements (one of) the MIME standards.  mm-utils.el
contains utility functions for MIME.  I.e. they are closely related.
I'm not sure it is worth to separate out parts of it.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sending attachments

[Mike Kupfer]

>>>>> "ST" == Stephen J Turnbull <stephen@xemacs.org> writes:

ST> Ted Zlatanov writes:

RS> 1. XEmacs can have these files if its developers want.

RS> 2. There could be a Gnus-XEmacs compatibility package released
RS> alongside Gnus.

>> I think Reiner Steib and Stephen Turnbull, among others, need to
>> discuss this with you and the Emacs maintainers.  I'll go along
>> with whatever decision the group makes.

ST> Mike Kupfer should be in the mix, other than that I don't have a
ST> particular opinion on what to do.

Hi, folks.  I'm the Gnus maintainer for XEmacs.  Stephen T. pointed me
at this discussion.

The XEmacs-specific code in Gnus appears in one of two ways (that I'm
aware of):

1. XEmacs-specific files (gnus-xmas.el, messagexmas.el)
2. (featurep 'xemacs) checks in otherwise common code.

I just did a quick pass through the Gnus 5.10.10 sources to see how
often (featurep 'xemacs) appears.  I get 45 hits for message.el plus
mm*.el (171 hits for Gnus as a whole).  A lot of those 45 hits are in
menu generation code, leaving 18 or so places that will like require
more serious work for refactoring.

gnus-xmas.el and messagexmas.el are distributed with the Gnus releases
from gnus.org.  I'd like to see those files remain with the Gnus
sources, as separating them would increase the risk of breakage as
changes are made to the common code.

mike

Re: rfc2047.el dependencies on mm-util.el (was: Sending attachments)

[Richard Stallman]

    > rfc2047.el depends on some substantial code in mm-util.el:
    > mm-charset-to-coding-system and mm-find-mime-charset-region.  I cannot
    > understand that code, and I am not sure what it is trying to do.  I
    > understand the doc strings, but they explain only in vague terms.

    Please elaborate what is not clear...

If only a piece of it were unclear, that would be a reasonable question.
However, the problem is that I can't even begin to understand most
of those functions.  The necessary info is not present.

    MIME charsets are not the same as (Emacs) coding systems.  This
    function does the mapping and also handles overrides (many MUAs
    specify wrong charsets), invalid charsets, etc.

That is just the beginning of the necessary explanation for
understanding what this code does.  To state the purpose in general
terms like this is not enough.

To make the code clear means explaining the specifics of what it does.
Each group of a few lines needs comments to explain why those lines
are there.  Lots of background information needs to be provided.

    rfc2047.el implements (one of) the MIME standards.  mm-utils.el
    contains utility functions for MIME.  I.e. they are closely related.

Only part of mm-utils.el is closely related to rfc2047.el.  That part
is what I am talking about here.  It consists of the two functions
mm-find-mime-charset-region and mm-charset-to-coding-system, and their
subroutines and data.

    I'm not sure it is worth to separate out parts of it.

I don't think you and I are talking about the same "it".  The things
you think I want to separate, actually I want to keep together.

I am going to move rfc20457.el outside Gnus to make it a regular part
of Emacs.

What I want to do is keep the two functions
mm-find-mime-charset-region and mm-charset-to-coding-system (and their
subroutines and data) together with rfc2047.el, making them too a
regular part of Emacs.  This requires separating them from the rest of
mm-utils.el which will remain inside Gnus.  It also requires making
them clean and understandable.

I am asking Gnus developers to help me by do this by splitting mm-utils
and cleaning up this part.

If I have to do this on my own, then since I can't understand all the
code of these functions, I will have to delete parts of the code until
I can understand what remains.  Some features will be lost, but at
least it will be clear and maintainable.  Whatever features I had to
discard could be re-added later if someone can write them cleanly.

However, if you help, maybe we can achieve a better outcome in which
we get clean code that implements all the existing features of
mm-charset-to-coding-system and mm-find-mime-charset-region, and thus
have no inconvenience for anyone.

Re: Sending attachments

[Richard Stallman]

     > Its complexity has discouraged me from looking at it except in
     > cases of need.

    Unfortunately, that complexity is mostly a reflection of the problem
    domain.

I think you are mistaken.  I think most of the complexity has nothing
to do with this.

Re: rfc2047.el dependencies on mm-util.el

[Stefan Monnier]

> If only a piece of it were unclear, that would be a reasonable question.
> However, the problem is that I can't even begin to understand most
> of those functions.  The necessary info is not present.

I'm not familar with those functions, but they don't look particularly
unclear to me.  So I don't know what "necessary info" you're looking for.

>     rfc2047.el implements (one of) the MIME standards.  mm-utils.el
>     contains utility functions for MIME.  I.e. they are closely related.

> Only part of mm-utils.el is closely related to rfc2047.el.  That part
> is what I am talking about here.  It consists of the two functions
> mm-find-mime-charset-region and mm-charset-to-coding-system, and their
> subroutines and data.

They're used in other places as well (basically to encode message
bodies), so they don't really belong to rfc2047.el.

> I am going to move rfc20457.el outside Gnus to make it a regular part
> of Emacs.

It's been part of Emacs since Emacs-21.  And I don't think you can
prevent the Gnus maintainers from distributing rfc2047.el along
with Gnus.

> What I want to do is keep the two functions
> mm-find-mime-charset-region and mm-charset-to-coding-system (and their
> subroutines and data) together with rfc2047.el, making them too
> a regular part of Emacs.  This requires separating them from the rest
> of mm-utils.el which will remain inside Gnus.  It also requires making
> them clean and understandable.

Rather than focus on code-ownership, I'd rather we focus on this latter
part: "clean and understandable".

> I am asking Gnus developers to help me by do this by splitting mm-utils
> and cleaning up this part.

Maybe one way to look at it is to split mm-utils.el into a part that
deals with compatibility between different Emacsen
(e.g. mm-string-to-multibyte) and the other that provides actual
functionality (e.g. mm-find-mime-charset-region).

I'm still wondering why someone would want to do that since it seems
pretty far from the goal of improving the user's experience.
IOW, another way to look at this problem would be: what changes would it
take to make Rmail use message-mode for composition?  I'm sure this will
take less time and make more people happier.


        Stefan

Re: rfc2047.el dependencies on mm-util.el (was: Sending attachments)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 19 Jul 2009 00:36:49 -0400
> Cc: tzz@lifelogs.com, ding@gnus.org, emacs-devel@gnu.org
> 
> What I want to do is keep the two functions
> mm-find-mime-charset-region and mm-charset-to-coding-system (and their
> subroutines and data) together with rfc2047.el, making them too a
> regular part of Emacs.

Do we really need these two functions?  I think we have the necessary
infrastructure in Emacs:

  . find-charset-region

  . find-coding-systems-region

  . find-coding-systems-for-charsets

  . (coding-system-get FOO :mime-charset)

  . coding-system-list

  . sort-coding-systems

If these are not enough to write a much cleaner, leaner versions of
those two mm-utils functions, please tell what else is missing.

Re: rfc2047.el dependencies on mm-util.el

[Richard Stallman]

    I'm not familar with those functions, but they don't look particularly
    unclear to me.

If you can manage to understand them, can you please add comments explaining
their code clearly?

    > Only part of mm-utils.el is closely related to rfc2047.el.  That part
    > is what I am talking about here.  It consists of the two functions
    > mm-find-mime-charset-region and mm-charset-to-coding-system, and their
    > subroutines and data.

    They're used in other places as well (basically to encode message
    bodies), so they don't really belong to rfc2047.el.

I would not say they "belong to" it, but they are closely related to
it.

    > I am going to move rfc20457.el outside Gnus to make it a regular part
    > of Emacs.

    It's been part of Emacs since Emacs-21.

I am going to make it a regular part of Emacs -- no longer part of Gnus.

      And I don't think you can
    prevent the Gnus maintainers from distributing rfc2047.el along
    with Gnus.

I have no wish to stop them.  I'm concerned with what's in Emacs.  How
Gnus is distributed outside of Emacs is not the issue.

      This requires separating them from the rest
    > of mm-utils.el which will remain inside Gnus.  It also requires making
    > them clean and understandable.

    Rather than focus on code-ownership, I'd rather we focus on this latter
    part: "clean and understandable".

Part of making them clean and understandable is making the code not
depend on Gnus.

This won't stop Gnus from using these facilities.  It could use them
just as it uses any other Emacs facilities.

    Maybe one way to look at it is to split mm-utils.el into a part that
    deals with compatibility between different Emacsen
    (e.g. mm-string-to-multibyte) and the other that provides actual
    functionality (e.g. mm-find-mime-charset-region).

That could be the first step.  Then the next step is to make the
second part clear and independent of Gnus.

    I'm still wondering why someone would want to do that since it seems
    pretty far from the goal of improving the user's experience.

The goal is to move rfc2047.el outside of Gnus so that other parts
of Emacs can use it without using Gnus.

Re: rfc2047.el dependencies on mm-util.el (was: Sending attachments)

[Richard Stallman]

    > What I want to do is keep the two functions
    > mm-find-mime-charset-region and mm-charset-to-coding-system (and their
    > subroutines and data) together with rfc2047.el, making them too a
    > regular part of Emacs.

    Do we really need these two functions?  I think we have the necessary
    infrastructure in Emacs:

      . find-charset-region

      . find-coding-systems-region
    ...

I don't know whether they do 100% of the job.  I asked Handa basically
that question a week ago, but he has not answered yet.

I have been working on extracting the actually needed parts of mm-util.el.
That code often consists of wrappers around these standard functions.
But it does not have comments explaining why do something different,
or which cases  are intended to get different treatment, etc.

Re: rfc2047.el dependencies on mm-util.el

[Stefan Monnier]

>     I'm not familar with those functions, but they don't look particularly
>     unclear to me.

> If you can manage to understand them, can you please add comments explaining
> their code clearly?

Not really, because I don't know what's unclear about it.

>> I am going to move rfc20457.el outside Gnus to make it a regular part
>> of Emacs.
>     It's been part of Emacs since Emacs-21.
> I am going to make it a regular part of Emacs

I don't know what that means.

> -- no longer part of Gnus.

Isn't this out of your control?

>       And I don't think you can prevent the Gnus maintainers from
>     distributing rfc2047.el along with Gnus.
> I have no wish to stop them.  I'm concerned with what's in Emacs.  How
> Gnus is distributed outside of Emacs is not the issue.

Then I don't know what you mean by "no longer part of Gnus".

>     Rather than focus on code-ownership, I'd rather we focus on this latter
>     part: "clean and understandable".
> Part of making them clean and understandable is making the code not
> depend on Gnus.

What do you mean by "Gnus" in this context?  E.g., in my view,
mm-util.el is not part of Gnus (C-s gnus in this file shows it does
appear, but mostly in comments).

>     I'm still wondering why someone would want to do that since it seems
>     pretty far from the goal of improving the user's experience.
> The goal is to move rfc2047.el outside of Gnus so that other parts
> of Emacs can use it without using Gnus.

These words don't mean much to me since AFAICT rfc2047.el is already
independent from Gnus.


        Stefan

Re: rfc2047.el dependencies on mm-util.el

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I am going to make it a regular part of Emacs
>
> I don't know what that means.
>
>> -- no longer part of Gnus.
>
> Isn't this out of your control?

I think Richard is talking about moving the rfc2047.el file outside of
the gnus/ directory in Emacs.

-- 
 Bastien

Re: rfc2047.el dependencies on mm-util.el

[Chong Yidong]

Bastien <bastienguerry@googlemail.com> writes:

> I think Richard is talking about moving the rfc2047.el file outside of
> the gnus/ directory in Emacs.

If the Gnus maintainers are actively maintaining and developing the
rfc*.el files, it's not worthwhile to move those files from gnus/ into
net/, if that would make it harder for them to do thir job (due to the
repository synch issues etc.)  But if these files are more or less
"stable", then I don't see why not.

In the meantime, there's no reason to avoid `require'ing a package just
because that package happens to live in the gnus/ directory.

Re: rfc2047.el dependencies on mm-util.el

[Richard Stallman]

    In the meantime, there's no reason to avoid `require'ing a package just
    because that package happens to live in the gnus/ directory.

Indeed, the reason isn't tht it's in `gnus', but rather that it is
part of Gnus and dependent on lots of other parts of Gnus.

Re: rfc2047.el dependencies on mm-util.el (was: Sending attachments)

[Kevin Ryde]

Eli Zaretskii <eliz@gnu.org> writes:
>
> necessary infrastructure in Emacs:

And of course locale-charset-to-coding-system.  I've had some joy with
that on mime-ish names, doing the job of mm-charset-to-coding-system.

In bits of my code I've called locale- when available (emacs 22 up),
then try the mm-.  The mm- one has more variables to setup synonyms and
aliasing, but locale- might cover much of that already (and not need the
`codepage-setup' stuff for msdos any more at all).