Mail mode vs message mode

Mail mode vs message mode

[Chong Yidong]

If we are to switch to message-mode for Emacs 23.2, there remains
several issues that need to be resolved.  However, no one has done
anything.  If no one has fixed these issues during the next few weeks, I
think we should revert back to mail-mode.

I've taken a quick look, and the problems mainly come in three
categories.

1. Variables that are straightfowardly duplicated by message-mode.
   These variables should be either made into variable aliases (assuming
   no one would ever want to have different behaviors between
   message-mode and mail-mode):

   mail-from-style      message-from-style
   mail-envelope-from   message-envelope-from
   mail-interactive     message-interactive
   mail-yank-prefix     message-yank-prefix
   mail-signature       message-signature
   mail-signature-file  message-signature-file
   mail-default-headers message-default-headers
   mail-indentation-spaces         message-indentation-spaces
   mail-mailer-swallows-blank-line message-mailer-swallows-blank-line

   This will probably require compatibility code for XEmacs, too.

2. Hook variables.  I am not sure what to do about this, but the switch
   has bitten at least one use (Bug#3942).  Maybe we should make these
   variable aliases too:

   mail-mode-hook     message-mode-hook
   mail-citation-hook message-citation-hook
   mail-setup-hook    message-setup-hook
   mail-send-hook     message-send-hook

3. Variables that affect mail-mode but have no counterpart in message
   mode.  These need code changes:

   mail-specify-envelope-from  <???> message-sendmail-envelope-from
   mail-self-blind
   mail-yank-ignored-headers
   mail-archive-file-name
   mail-default-reply-to
   mail-default-directory
   mail-bury-selects-summary

Re: Mail mode vs message mode

[Xavier Maillard]

Hi,

maybe I am not the best player to speak here but why do you want
to replace mail-mode by message-mode exactly ?

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Mail mode vs message mode

[Stefan Monnier]

> maybe I am not the best player to speak here but why do you want
> to replace mail-mode by message-mode exactly ?

I think it's important that the default composition interface support
MIME and generally be able to send an email containing any chars.


        Stefan

Re: Mail mode vs message mode

[Miles Bader]

Xavier Maillard <xma@gnu.org> writes:
> maybe I am not the best player to speak here but why do you want
> to replace mail-mode by message-mode exactly ?

message-mode is, roughly-speaking, a superset of mail-mode, and offers
generally desirable features (good mime support in particular) that
mail-mode does not.

-Miles

-- 
Dictionary, n.  A malevolent literary device for cramping the growth of
a language and making it hard and inelastic. This dictionary, however,
is a most useful work.

Re: Mail mode vs message mode

[Xavier Maillard]

   > maybe I am not the best player to speak here but why do you want
   > to replace mail-mode by message-mode exactly ?

   I think it's important that the default composition interface support
   MIME and generally be able to send an email containing any chars.

Good catch. In fact I am so used to the etach package that I
almost forgot mail-mode did not have MIME support.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Mail mode vs message mode

[Miles Bader]

Xavier Maillard <xma@gnu.org> writes:
> Good catch. In fact I am so used to the etach package that I
> almost forgot mail-mode did not have MIME support.

Note that attachments are not the only function of mime, though they're
a very popular one.  Proper encoding support is also important.

-Miles

-- 
「すっごい」と呟いてる。「へんてこなもんばっかり」
「そんなにへんてこ？」
「へんてこへんてこ」
そう言われると見たくなってしまう。

Re: Mail mode vs message mode

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> 1. Variables that are straightfowardly duplicated by message-mode.
>    These variables should be either made into variable aliases (assuming
>    no one would ever want to have different behaviors between
>    message-mode and mail-mode):
>
>    mail-from-style      message-from-style
>    mail-envelope-from   message-envelope-from
>    mail-interactive     message-interactive
>    mail-yank-prefix     message-yank-prefix
>    mail-signature       message-signature
>    mail-signature-file  message-signature-file
>    mail-default-headers message-default-headers
>    mail-indentation-spaces         message-indentation-spaces
>    mail-mailer-swallows-blank-line message-mailer-swallows-blank-line

After thinking about this some more, I think using defvaralias is a bad
idea.

Would anyone object to setting the default values for the message-mode
variables to the corresponding mail-mode variables? e.g.,

(defcustom message-from-style
    (if (featurep 'xemacs) 'angles mail-from-style)
    ....)

> 2. Hook variables.  I am not sure what to do about this, but the switch
>    has bitten at least one use (Bug#3942).  Maybe we should make these
>    variable aliases too:
>
>    mail-mode-hook     message-mode-hook
>    mail-citation-hook message-citation-hook
>    mail-setup-hook    message-setup-hook
>    mail-send-hook     message-send-hook

Any objections to adding a new user option message-run-mail-hooks,
which, if non-nil, causes message mode to run the corresponding mail
hooks as well?

Re: Mail mode vs message mode

[Reiner Steib]

[ You probably meant ding@gnus not ding@gnu;  Quote not trimmed. ]

On Tue, Nov 17 2009, Chong Yidong wrote:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> 1. Variables that are straightfowardly duplicated by message-mode.
>>    These variables should be either made into variable aliases (assuming
>>    no one would ever want to have different behaviors between
>>    message-mode and mail-mode):
>>
>>    mail-from-style      message-from-style
>>    mail-envelope-from   message-envelope-from
>>    mail-interactive     message-interactive
>>    mail-yank-prefix     message-yank-prefix
>>    mail-signature       message-signature
>>    mail-signature-file  message-signature-file
>>    mail-default-headers message-default-headers
>>    mail-indentation-spaces         message-indentation-spaces

No difference here for me (Emacs 23.1).

>>    mail-mailer-swallows-blank-line message-mailer-swallows-blank-line

The latter is a defcustom.  Any other difference?

> After thinking about this some more, I think using defvaralias is a bad
> idea.
>
> Would anyone object to setting the default values for the message-mode
> variables to the corresponding mail-mode variables? e.g.,
>
> (defcustom message-from-style
>     (if (featurep 'xemacs) 'angles mail-from-style)
>     ....)

I don't like this.  The current default value of message-from-style
tries to avoid quoting if possible and therefore is preferable to
`angles'.  BTW, message-mode doesn't handle the value
`system-default'.

I'd certainly object to change the default `message-yank-prefix' to
nil!

If I understand the correctly, the goal is not to provide full
compatibility with mail-mode but to have a default mail composition
mode that handles MIME correctly.  So how about simply providing a
function, say `message-initalize-from-mail-mode' that initializes
message variables and hooks from the corresponding mail-mode ones?

Draft (we need to check if all possible values of mail-foo make sense
for message-foo):

(defun message-initalize-from-mail-mode ()
  (setq
   message-from-style                 mail-from-style
   message-envelope-from              mail-envelope-from
   message-interactive                mail-interactive
   message-yank-prefix                mail-yank-prefix
   message-signature                  mail-signature
   message-signature-file             mail-signature-file
   message-default-headers            mail-default-headers
   message-indentation-spaces         mail-indentation-spaces
   message-mailer-swallows-blank-line mail-mailer-swallows-blank-line)
  (setq
   ;; hooks
   message-mode-hook	 mail-mode-hook
   message-citation-hook mail-citation-hook
   message-setup-hook    mail-setup-hook
   message-send-hook     mail-send-hook))

>> 2. Hook variables.  I am not sure what to do about this, but the switch
>>    has bitten at least one use (Bug#3942).  Maybe we should make these
>>    variable aliases too:
>>
>>    mail-mode-hook     message-mode-hook
>>    mail-citation-hook message-citation-hook
>>    mail-setup-hook    message-setup-hook
>>    mail-send-hook     message-send-hook
>
> Any objections to adding a new user option message-run-mail-hooks,
> which, if non-nil, causes message mode to run the corresponding mail
> hooks as well?

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

Re: Mail mode vs message mode

[Xavier Maillard]

   Xavier Maillard <xma@gnu.org> writes:
   > Good catch. In fact I am so used to the etach package that I
   > almost forgot mail-mode did not have MIME support.

   Note that attachments are not the only function of mime, though they're
   a very popular one.  Proper encoding support is also important.

You are right. My main problem with rmail is the way certains
subjects are decoded (but it has nothing to do with mail-mode
:D).

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Mail mode vs message mode

[Chong Yidong]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

>> (defcustom message-from-style
>>     (if (featurep 'xemacs) 'angles mail-from-style)
>>     ....)
>
> I don't like this.  The current default value of message-from-style
> tries to avoid quoting if possible and therefore is preferable to
> `angles'.  BTW, message-mode doesn't handle the value
> `system-default'.

We should switch the mail-mode default to `angles'.  Not sure what to do
about the `system-default' setting; maybe we should deprecate it, as I'm
not sure it's useful anymore.

> If I understand the correctly, the goal is not to provide full
> compatibility with mail-mode but to have a default mail composition
> mode that handles MIME correctly.  So how about simply providing a
> function, say `message-initalize-from-mail-mode' that initializes
> message variables and hooks from the corresponding mail-mode ones?

One minor problem: Customize would complain about the value being
changed from the default.  In general, it's not nice to set the default
value of a variable outside of its defcustom, as that can lead to
confusion.

We can do it your way if you really object to making the message-mode
options default to the corresponding mail-* options, but I'd like to
know the reasoning first.  (If any of the default values for the mail-*
options grate, like mail-from-style, we can change them.)

Re: Mail mode vs message mode

[Reiner Steib]

On Wed, Nov 18 2009, Chong Yidong wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
[ derive message-from-style's default from mail-from-style ]
>> I don't like this.  The current default value of message-from-style
>> tries to avoid quoting if possible and therefore is preferable to
>> `angles'.  BTW, message-mode doesn't handle the value
>> `system-default'.
>
> We should switch the mail-mode default to `angles'.  

mail-from-style already is `angles' in Emacs 23.1, isn't it?

But deriving message-from-style from mail-from-style would change the
latter from `default' to `angles' (as I already tried to explain).

> Not sure what to do about the `system-default' setting; maybe we
> should deprecate it, as I'm not sure it's useful anymore.

AFAICS, in message-mode, setting message-from-style to
`system-default' leads to a plain "From: foo@bar" header i.e. without
the user name (user-full-name).  So probably this is not a problem.

>> If I understand the correctly, the goal is not to provide full
>> compatibility with mail-mode but to have a default mail composition
>> mode that handles MIME correctly.  So how about simply providing a
>> function, say `message-initalize-from-mail-mode' that initializes
>> message variables and hooks from the corresponding mail-mode ones?
>
> One minor problem: Customize would complain about the value being
> changed from the default.  In general, it's not nice to set the default
> value of a variable outside of its defcustom, as that can lead to
> confusion.

Well, it's not really about setting the default value since it is
change made by the user like any other setq change.

> We can do it your way if you really object to making the message-mode
> options default to the corresponding mail-* options, but I'd like to
> know the reasoning first.  (If any of the default values for the mail-*
> options grate, like mail-from-style, we can change them.)

If the message-mode defaults aren't changed by deriving from mail-*, I
don't object.

I'd certainly object to any change that makes message-mode less
"standard" compliant ("standards" like RFCs, GNKSA [1], good common
practice, ...).  Changing the default `message-yank-prefix' to nil
violates GNKSA, item 10 b and c:

,----[ http://www.newsreaders.com/gnksa/cgi/gnksa-form.cgi ]
| 10. Provides adequate quotation and attribution facilities
| 
|    b. Clearly distinguishes quoted material
|    c. Prefixes quoted material with `>' (or `> ' for the "first" followup)
`----

I didn't check all the other variables you listed.

I doubt that adjusting the mail-* default and the message-* defaults
is worth the effort: user who dislike the message-* values may ...

- stay with mail-mode (by customizing `mail-user-agent' back to
  `sendmail-user-agent')

- use the suggested `message-initalize-from-mail-mode' function.

- customize those few options that (s)he really cares about

Bye, Reiner.

[1] GNKSA (The Good Net-Keeping Seal of Approval)
    http://www.xs4all.nl/~js/gnksa/
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Mail mode vs message mode

[Teemu Likonen]

On 2009-11-18 20:20 (+0100), Reiner Steib wrote:

> On Wed, Nov 18 2009, Chong Yidong wrote:
>> We can do it your way if you really object to making the message-mode
>> options default to the corresponding mail-* options, but I'd like to
>> know the reasoning first. (If any of the default values for the
>> mail-* options grate, like mail-from-style, we can change them.)
>
> If the message-mode defaults aren't changed by deriving from mail-*, I
> don't object.
>
> I'd certainly object to any change that makes message-mode less
> "standard" compliant ("standards" like RFCs, GNKSA [1], good common
> practice, ...).  Changing the default `message-yank-prefix' to nil
> violates GNKSA, item 10 b and c:

Yes, please use "> " as *-yank-prefix. It's the only sane choice, the
only one which is compatible with the world.

Re: Mail mode vs message mode

[Chong Yidong]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> If the message-mode defaults aren't changed by deriving from mail-*, I
> don't object.
>
> I'd certainly object to any change that makes message-mode less
> "standard" compliant ("standards" like RFCs, GNKSA [1], good common
> practice, ...).

I've switched several message-mode defcustoms to the mail-* values.
I've also made some changes to the mail-* defaults, so I don't think
message mode users should see any change (mail mode users won't see much
difference, either).

Re: Mail mode vs message mode

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

>>>>> Chong Yidong wrote:
> I've switched several message-mode defcustoms to the mail-* values.
> I've also made some changes to the mail-* defaults, so I don't think
> message mode users should see any change (mail mode users won't see much
> difference, either).

>>>>> In <E1NBA9i-0007bh-Va@cvs.savannah.gnu.org>:
> -(defcustom message-from-style 'default
> +(defcustom message-from-style
> +  (if (featurep 'xemacs) 'default mail-from-style)

XEmacs is not special, there is no reason not to use the mail-*
values.  In addition, there are some mail-* variables unavailable
in old Emacsen that Gnus supports.  Is it ok to commit the following
change?  The patch is attached in this message.

2009-11-20  Katsumi Yamaoka  <yamaoka@jpl.org>

	* message.el (message-from-style, message-interactive)
	(message-signature): Always set default values from the corresponding
	mail-* variables.
	(message-cite-prefix-regexp, message-sendmail-envelope-from)
	(message-yank-prefix, message-indentation-spaces)
	(message-signature-file, message-default-headers): Use boundp rather
	than (featurep 'xemacs) to check if the corresponding mail-* variables
	exist.

I run `EMACS -batch -q' (where EMACS is Emacs 21.1, 21.2, 21.4,
22.1, 22.2, 22.3, 23.1, 23.1.50, XEmacs 21.4.22, 21.5-b29 and
SXEmacs 22.1.11) with the following script:

(princ emacs-version)
(princ "\n")
(dolist (var '(mail-from-style
	       mail-interactive
	       mail-citation-prefix-regexp
	       mail-envelope-from
	       mail-yank-prefix
	       mail-indentation-spaces
	       mail-signature
	       mail-signature-file
	       mail-default-headers
	       mail-specify-envelope-from))
  (unless (boundp var)
    (princ var)
    (princ "\n")))

And I got:

21.1.1
mail-citation-prefix-regexp
mail-envelope-from
mail-yank-prefix
mail-indentation-spaces
mail-signature-file
mail-default-headers
21.2.1
mail-citation-prefix-regexp
mail-envelope-from
mail-yank-prefix
mail-indentation-spaces
mail-signature-file
mail-default-headers
21.4.1
mail-citation-prefix-regexp
mail-envelope-from
mail-yank-prefix
mail-indentation-spaces
mail-signature-file
mail-default-headers
22.1.1
mail-envelope-from
22.2.1
mail-envelope-from
22.3.1
mail-envelope-from
23.1.1
mail-envelope-from
23.1.50.1
mail-envelope-from
21.4 (patch 22) "Instant Classic" XEmacs Lucid
mail-citation-prefix-regexp
mail-envelope-from
mail-indentation-spaces
mail-signature-file
mail-default-headers
21.5  (beta29) "garbanzo" XEmacs Lucid
mail-citation-prefix-regexp
mail-envelope-from
mail-indentation-spaces
mail-signature-file
mail-default-headers
steve@sxemacs.org--2009/sxemacs--main--22.1.11--patch-33


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 3428 bytes --]

--- message.el~	2009-11-19 21:42:51 +0000
+++ message.el	2009-11-19 23:39:32 +0000
@@ -159,8 +159,7 @@
   :group 'message-interface
   :type 'regexp)
 
-(defcustom message-from-style
-  (if (featurep 'xemacs) 'default mail-from-style)
+(defcustom message-from-style mail-from-style
   "*Specifies how \"From\" headers look.
 
 If nil, they contain just the return address like:
@@ -434,7 +433,7 @@
   :link '(custom-manual "(message)Various Commands")
   :group 'message-various)
 
-(defcustom message-interactive (if (featurep 'xemacs) t mail-interactive)
+(defcustom message-interactive mail-interactive
   "Non-nil means when sending a message wait for and display errors.
 nil means let mailer mail back a message to report errors."
   :group 'message-sending
@@ -611,7 +610,7 @@
   :type 'regexp)
 
 (defcustom message-cite-prefix-regexp
-  (cond ((not (featurep 'xemacs))
+  (cond ((boundp 'mail-citation-prefix-regexp)
 	 mail-citation-prefix-regexp)
 	((string-match "[[:digit:]]" "1")
 	 ;; Support POSIX?  XEmacs 21.5.27 doesn't.
@@ -820,7 +819,7 @@
   :type 'boolean)
 
 (defcustom message-sendmail-envelope-from
-  (if (featurep 'xemacs) nil mail-envelope-from)
+  (if (boundp 'mail-envelope-from) mail-envelope-from)
   "*Envelope-from when sending mail with sendmail.
 This only has an effect if `mail-specify-envelope-from' is non-nil.
 If this is nil, use `user-mail-address'.  If it is the symbol
@@ -998,7 +997,9 @@
   :version "23.1" ;; No Gnus
   :group 'message-insertion)
 
-(defcustom message-yank-prefix (if (featurep 'xemacs) "> " mail-yank-prefix)
+(defcustom message-yank-prefix (if (boundp 'mail-yank-prefix)
+				   mail-yank-prefix
+				 "> ")
   "*Prefix inserted on the lines of yanked messages.
 Fix `message-cite-prefix-regexp' if it is set to an abnormal value.
 See also `message-yank-cited-prefix' and `message-yank-empty-prefix'."
@@ -1024,7 +1025,7 @@
   :group 'message-insertion)
 
 (defcustom message-indentation-spaces
-  (if (featurep 'xemacs) 3 mail-indentation-spaces)
+  (if (boundp 'mail-indentation-spaces) mail-indentation-spaces 3)
   "*Number of spaces to insert at the beginning of each cited line.
 Used by `message-yank-original' via `message-yank-cite'."
   :group 'message-insertion
@@ -1053,7 +1054,7 @@
   :link '(custom-manual "(message)Insertion Variables")
   :group 'message-insertion)
 
-(defcustom message-signature (if (featurep 'xemacs) t mail-signature)
+(defcustom message-signature mail-signature
   "*String to be inserted at the end of the message buffer.
 If t, the `message-signature-file' file will be inserted instead.
 If a function, the result from the function will be used instead.
@@ -1063,7 +1064,7 @@
   :group 'message-insertion)
 
 (defcustom message-signature-file
-  (if (featurep 'xemacs) "~/.signature" mail-signature-file)
+  (if (boundp 'mail-signature-file) mail-signature-file "~/.signature")
   "*Name of file containing the text inserted at end of message buffer.
 Ignored if the named file doesn't exist.
 If nil, don't insert a signature.
@@ -1139,7 +1140,7 @@
   :error "All header lines must be newline terminated")
 
 (defcustom message-default-headers
-  (if (featurep 'xemacs) "" mail-default-headers)
+  (if (boundp 'mail-default-headers) mail-default-headers "")
   "*A string containing header lines to be inserted in outgoing messages.
 It is inserted before you edit the message, so you can edit or delete
 these lines."

Re: Mail mode vs message mode

[Reiner Steib]

On Fri, Nov 20 2009, Katsumi Yamaoka wrote:

> XEmacs is not special, there is no reason not to use the mail-*
> values.  In addition, there are some mail-* variables unavailable
> in old Emacsen that Gnus supports.  Is it ok to commit the following
> change?  The patch is attached in this message.

Seem correct to me, please install.  Maybe add a note about the
compatibility issues?

> I run `EMACS -batch -q' (where EMACS is Emacs 21.1, 21.2, 21.4,
> 22.1, 22.2, 22.3, 23.1, 23.1.50, XEmacs 21.4.22, 21.5-b29 and
> SXEmacs 22.1.11) with the following script:
>
> (princ emacs-version)
> (princ "\n")
> (dolist (var '(mail-from-style
[...]
> 	       mail-specify-envelope-from))
>   (unless (boundp var)
>     (princ var)
>     (princ "\n")))

Could you also check if any default value of the message-FOO variables
are modified by deriving them from mail-FOO in these Emacsen?

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

Re: Mail mode vs message mode

[Reiner Steib]

On Thu, Nov 19 2009, Chong Yidong wrote:

> I've also made some changes to the mail-* defaults,

I think you forgot to adjust the custom :version tags.

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

Re: Mail mode vs message mode

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

>>>>> Reiner Steib wrote:
> On Fri, Nov 20 2009, Katsumi Yamaoka wrote:

>> XEmacs is not special, there is no reason not to use the mail-*
>> values.  In addition, there are some mail-* variables unavailable
>> in old Emacsen that Gnus supports.  Is it ok to commit the following
>> change?  The patch is attached in this message.

> Seem correct to me, please install.  Maybe add a note about the
> compatibility issues?

Committed with comments.  Thanks.

[...]

> Could you also check if any default value of the message-FOO variables
> are modified by deriving them from mail-FOO in these Emacsen?

To Emacs 21, 22, and 23.1 users, the default behaviors concerning
`message-interactive' and `message-yank-prefix' will be changed.
See the table attached below.  They may not be serious, but as
for `message-yank-prefix', it may not be easy to users to find
the way to make Gnus work as before (the new behavior is that
cited lines are prefixed only with three space characters).
It's enough to let me hesitate to merge the changes to No Gnus.

Regards,

[-- Attachment #2: mail-message-vars.png --]
[-- Type: image/png, Size: 12227 bytes --]

Re: Mail mode vs message mode

[Reiner Steib]

On Tue, Nov 24 2009, Katsumi Yamaoka wrote:

> They may not be serious, but as for `message-yank-prefix', it may
> not be easy to users to find the way to make Gnus work as before
> (the new behavior is that cited lines are prefixed only with three
> space characters).

This is not acceptable IMHO.  We need to find a solution for this.
I don't have a good idea, though.

> It's enough to let me hesitate to merge the changes to No Gnus.

I agree.

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

Re: Mail mode vs message mode

[Stefan Monnier]

>> They may not be serious, but as for `message-yank-prefix', it may
>> not be easy to users to find the way to make Gnus work as before
>> (the new behavior is that cited lines are prefixed only with three
>> space characters).

> This is not acceptable IMHO.  We need to find a solution for this.
> I don't have a good idea, though.

It should be pretty easy to do something like

  (defcustom message-foo
      (let ((def mail-foo))
        (if (acceptable def) def fallback))
    ...)


-- Stefan

Re: Mail mode vs message mode

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> They may not be serious, but as for `message-yank-prefix', it may
>>> not be easy to users to find the way to make Gnus work as before
>>> (the new behavior is that cited lines are prefixed only with three
>>> space characters).
>
>> This is not acceptable IMHO.  We need to find a solution for this.
>> I don't have a good idea, though.
>
> It should be pretty easy to do something like
>
>   (defcustom message-foo
>       (let ((def mail-foo))
>         (if (acceptable def) def fallback))
>     ...)

That kind of defeats the purpose.

Re: Mail mode vs message mode

[Stefan Monnier]

>>>> They may not be serious, but as for `message-yank-prefix', it may
>>>> not be easy to users to find the way to make Gnus work as before
>>>> (the new behavior is that cited lines are prefixed only with three
>>>> space characters).
>> 
>>> This is not acceptable IMHO.  We need to find a solution for this.
>>> I don't have a good idea, though.
>> 
>> It should be pretty easy to do something like
>> 
>> (defcustom message-foo
>> (let ((def mail-foo))
>> (if (acceptable def) def fallback))
>> ...)

> That kind of defeats the purpose.

Why?


        Stefan

Re: Mail mode vs message mode

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> (defcustom message-foo
>>> (let ((def mail-foo))
>>> (if (acceptable def) def fallback))
>>> ...)
>
>> That kind of defeats the purpose.
>
> Why?

Isn't the entire purpose of using a default value of `mail-foo' to pick
up any user customizations of mail-foo in .emacs (otherwise it'd be easy
enough to just use a literal "> " as a default for message-yank-prefix)?

So if the user sets mail-yank-prefix to "   ", but your (acceptable ...)
test rejects that because it looks wrong, then the purpose has (to some
extent) been defeated...

-Miles

-- 
Discriminate, v.i. To note the particulars in which one person or thing is,
if possible, more objectionable than another.

Re: Mail mode vs message mode

[Katsumi Yamaoka]

>>>>> Reiner Steib wrote:
> On Tue, Nov 24 2009, Katsumi Yamaoka wrote:

>> They may not be serious, but as for `message-yank-prefix', it may
>> not be easy to users to find the way to make Gnus work as before
>> (the new behavior is that cited lines are prefixed only with three
>> space characters).

> This is not acceptable IMHO.  We need to find a solution for this.
> I don't have a good idea, though.

How about using the value of mail-* if and only if the value of
mail-* is customized by a user or its default value is suitable
to Gnus?

(defcustom MESSAGE-VAR
  (if (or
       ;; MAIL-VAR's value is set by a user in the ~/.emacs file but
       ;; the .el file containing the form `(defcustom MAIL-VAR ...)'
       ;; is not loaded yet.
       (and (boundp MAIL-VAR)
	    (not (get MAIL-VAR 'standard-value)))
       ;; MAIL-VAR's value is customized by a user.
       (and (get MAIL-VAR 'standard-value)
	    (not (equal (car (get MAIL-VAR 'standard-value))
			(symbol-value MAIL-VAR))))
       ;; MAIL-VAR's default value is suitable to Gnus' default.
       (and (boundp MAIL-VAR)
	    (equal (symbol-value MAIL-VAR) VALUE-SUITABLE-TO-GNUS)))
      ;; Use MAIL-VAR's value.
      (symbol-value MAIL-VAR)
    ;; Use a value suitable to Gnus' default.
    VALUE-SUITABLE-TO-GNUS)
  "doc string")

For `message-yank-prefix', it will be the following:

(defcustom message-yank-prefix
  (if (or (and (boundp 'mail-yank-prefix)
	       (not (get 'mail-yank-prefix 'standard-value)))
	  (and (get 'mail-yank-prefix 'standard-value)
	       (not (equal (car (get 'mail-yank-prefix 'standard-value))
			   mail-yank-prefix)))
	  (and (boundp 'mail-yank-prefix)
	       (equal mail-yank-prefix "> ")))
      mail-yank-prefix
    "> ")
  "doc string")

In Emacs 22, it will default to "> ", while mail-yank-prefix's
default is nil.

The above one differs from this:

(defcustom message-yank-prefix "> "
  "doc string")

User's preference to mail-* is reflected to message-*.

Regards,

Re: Mail mode vs message mode

[Chong Yidong]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> How about using the value of mail-* if and only if the value of
> mail-* is customized by a user or its default value is suitable
> to Gnus?

I would prefer a direct check for the Emacs version instead, if you want
to avoid the mail-* variables for older Emacsen.

Re: Mail mode vs message mode

[Stefan Monnier]

>>>> (defcustom message-foo
>>>> (let ((def mail-foo))
>>>> (if (acceptable def) def fallback))
>>>> ...)
>>> That kind of defeats the purpose.
>> Why?

> Isn't the entire purpose of using a default value of `mail-foo' to pick
> up any user customizations of mail-foo in .emacs (otherwise it'd be easy
> enough to just use a literal "> " as a default for message-yank-prefix)?

> So if the user sets mail-yank-prefix to "   ", but your (acceptable ...)
> test rejects that because it looks wrong, then the purpose has (to some
> extent) been defeated...

Clearly, we'd want the `acceptable' test to only reject the few default
settings of previous Emacsen that are not acceptable and accept
anything else.  So we'd only ignore user's configurations if they have
their mail-foo var customized to one of those older default values.

For those, they'll have to set message-foo explicitly instead.


        Stefan

Re: Mail mode vs message mode

[Katsumi Yamaoka]

>>>>> In <87skc03tsk.fsf@stupidchicken.com>
>>>>>	Chong Yidong <cyd@stupidchicken.com> wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:

> > How about using the value of mail-* if and only if the value of
> > mail-* is customized by a user or its default value is suitable
> > to Gnus?

> I would prefer a direct check for the Emacs version instead, if you want
> to avoid the mail-* variables for older Emacsen.

It will be something like:

(defcustom message-yank-prefix
  (if (featurep 'xemacs)
      "> "
    (if (or (string-match "\\`23\\.1\\.5[0-9]\\.[0-9]*\\'" emacs-version)
	    (>= emacs-major-version 24)
	    (and (= emacs-major-version 23) (>= emacs-minor-version 2)))
	mail-yank-prefix
      "> "))
  "doc string")

But I don't find a meaningful difference in it from:

(defcustom message-yank-prefix "> "
  "doc string")

In other words, I'd prefer to revert the recent changes in message.el.

Regards,

Re: Mail mode vs message mode

[Chong Yidong]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> It will be something like:
>
> (defcustom message-yank-prefix
>   (if (featurep 'xemacs)
>       "> "
>     (if (or (string-match "\\`23\\.1\\.5[0-9]\\.[0-9]*\\'" emacs-version)
> 	    (>= emacs-major-version 24)
> 	    (and (= emacs-major-version 23) (>= emacs-minor-version 2)))
> 	mail-yank-prefix
>       "> "))
>   "doc string")
>
> But I don't find a meaningful difference in it from:
>
> (defcustom message-yank-prefix "> "
>   "doc string")
>
> In other words, I'd prefer to revert the recent changes in message.el.

How about not synching message.el automatically?

If message-mode is to become the default mail mode for Emacs, we need to
be able to make changes to it as part of Emacs.  If that can't be done,
I'd prefer to switch back to mail-mode.

Re: Mail mode vs message mode

[Katsumi Yamaoka]

>>>>> Chong Yidong wrote:
> How about not synching message.el automatically?

No problem at least to me (I do it manually when I do).  Now not
only message.el but also parse-time.el, pgg.el, time-date.el, and
gnus.el differ.

> If message-mode is to become the default mail mode for Emacs, we need to
> be able to make changes to it as part of Emacs.  If that can't be done,
> I'd prefer to switch back to mail-mode.

Ok.  Maybe the point is that I have no understanding of the goal.
Currently, the default values of message-* variables in question
are the same as those of mail-* variables in the Emacs trunk, and
I find no advantage of message-* variables' succeeding to mail-*
variables' values.  But, it is not the goal, is it?

Regards,

Mail mode vs Message mode

[BP25]

Hello!

I'm choosing which mail composition method to use betweem mailmode
(sendmail.el) and messagemode (message.el). I wish there were a
comprehensive compare and contrast on the Emacs manual!

I gather the main difference is that one provides MIME-support (whatever
this means). Are they being developped "in parallel"? Do they have
overlapping functionalities which are implemented differently? Why not
just merge them into one single MIME-compliant mode which is compatible
with both: this will spare so much confusion to newbies!

Please let me know! (and please CC: my email address because I'm not
subscribed to this list)

Re: Mail mode vs Message mode

[Eli Zaretskii]

> From: BP25 <bp25@riseup.net>
> Date: Mon, 28 Oct 2024 18:24:14 +0000
> 
> I'm choosing which mail composition method to use betweem mailmode
> (sendmail.el) and messagemode (message.el). I wish there were a
> comprehensive compare and contrast on the Emacs manual!
> 
> I gather the main difference is that one provides MIME-support (whatever
> this means).

No, they both support MIME.

message.el is the preferred (and more modern) mode, which is why it is
the default.  So unless you have good reasons to use sendmail.el (for
example, some elaborate setup specific to sendmail.el), our
recommendation is to use message.el, per the default.