Incorporate message-utils.el?

Incorporate message-utils.el?

[Kai Großjohann]

WIBNI message-utils were autoloaded and mentioned in the menus and in
the keybindings by default?

Any takers?

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Incorporate message-utils.el?

[Reiner Steib]

On Thu, Sep 12 2002, Kai Großjohann wrote:

> WIBNI message-utils were autoloaded and mentioned in the menus and in
> the keybindings by default?

ACK.

> Any takers?

For me, it's not clear how to do it. At first, I thought, that it
would be enough to add "(require 'message-utils)" and merge the menu
entries and key-bindings to `message.el' (eventually adjust the
key-bindings to the given conventions).

But Holger Schauer (the original author of message-utils) wrote [1],
that e.g. functions like `message-strip-subject-was' should be
integrated directly into the function building the subject and _not_
be called add a hook afterwards.

Bye, Reiner.

[1] In de.comm.software.gnus:
,----[ news:<whn0x6ulbj.fsf@ipanema.coling.uni-freiburg.de> ]
| Eigentlich sollte eine Funktionalitaet wie message-strip-subject-was
| direkt in der Funktion integriert sein, die das Subject baut und
| nicht als Hook hintendran aufgerufen werden. Es gibt noch mehr
| Kleinigkeiten in dieser Richtung.
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Incorporate message-utils.el?

[Kai Großjohann]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> For me, it's not clear how to do it. At first, I thought, that it
> would be enough to add "(require 'message-utils)" and merge the menu
> entries and key-bindings to `message.el' (eventually adjust the
> key-bindings to the given conventions).

Maybe it's enough to add autoload cookies to message-utils.el.  Or
maybe move the defuns to message.el.

> But Holger Schauer (the original author of message-utils) wrote [1],
> that e.g. functions like `message-strip-subject-was' should be
> integrated directly into the function building the subject and _not_
> be called add a hook afterwards.

Hm.  It's a point.  Would you like to do that?

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Incorporate message-utils.el?

[Reiner Steib]

On Thu, Sep 12 2002, Kai Großjohann wrote:

> Reiner Steib <4uce.02.r.steib@gmx.net> writes:

>> [...] I thought, that it would be enough to add "(require
>> 'message-utils)" and merge the menu entries and key-bindings to
>> `message.el' (eventually adjust the key-bindings to the given
>> conventions).

> Maybe it's enough to add autoload cookies to message-utils.el.  Or
> maybe move the defuns to message.el.

>> [...] functions like `message-strip-subject-was' should be
>> integrated directly into the function building the subject and _not_
>> be called add a hook afterwards.
>
> Hm.  It's a point.  Would you like to do that?

Sorry, I don't think that I'm able to do what Holger suggested, or I
didn't understand it ;-), see (c) below. My knowledge about the
control flow in Gnus (and about lisp in general) is probably not
sufficient.

What *I* could do is:

(a) move the defuns to message.el or/and add autoload cookies to
    message-utils.el.

(b) add the menu entries and key-bindings. I suppose this has to be
    done in `message.el' no matter whether or not we put all functions
    in `message.el' or leave them in `message-utils.el'.
  
(c) put the function call of `message-strip-subject-was' to the spot
    in `message.el' where `message-header-setup-hook' is called. Would
    this be enough?

(d) What about the behavior of `message-strip-subject-was'? Should it
    be enabled by default? I'd suggest the following (I just added the
    behavior described in the doc-string to the function
    `message-strip-subject-was' and it works for me):

--8<------------------------schnipp------------------------->8---
(defcustom message-strip-subject-was 'ask
  "*What to do with trailing \"(was: <old subject>)\" in subject lines.
If nil, leave the subject unchanged.  If it is the symbol `ask', ask the use
what do do.  If it is t, always strip the trailing old subject.  See the
variable `message-subject-was-regexp' how an old subject may look like."
[...]
  :group 'message-various)
--8<------------------------schnapp------------------------->8---

I could do it, if people think that this makes sense. But I don't want
to spend time on this, if it's unclear how the Gnus developers want it
to be done. What do you (Kai or others) suggest?

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

Re: Incorporate message-utils.el?

[Daniel Pittman]

On Thu, 12 Sep 2002, Reiner Steib wrote:
> On Thu, Sep 12 2002, Kai Großjohann wrote:
>> Reiner Steib <4uce.02.r.steib@gmx.net> writes:

[...]

>>> [...] functions like `message-strip-subject-was' should be
>>> integrated directly into the function building the subject and _not_
>>> be called add a hook afterwards.

[...]

> (d) What about the behavior of `message-strip-subject-was'? Should it
>     be enabled by default?

No, absolutely not. Modifying data without the user asking for it to be
modified is not a good thing. At the very least default to asking, not
just doing.

     Daniel

-- 
like torches in the aeon flow
  even suns flicker and die
  forgotten as the ages grow
   eternity is not for you
        -- Covenant, _Flux_

Re: Incorporate message-utils.el?

[Mark Trettin]

* On: Thu, 12 Sep 2002 22:12:25 +0200 Reiner Steib writes:
> On Thu, Sep 12 2002, Kai Großjohann wrote:
>> Reiner Steib <4uce.02.r.steib@gmx.net> writes:

[...]

>>> [...] functions like `message-strip-subject-was' should be
>>> integrated directly into the function building the subject and _not_
>>> be called add a hook afterwards.
>> 
>> Hm.  It's a point.  Would you like to do that?

[...]

> (d) What about the behavior of `message-strip-subject-was'? Should it
>     be enabled by default? I'd suggest the following (I just added the
>     behavior described in the doc-string to the function
>     `message-strip-subject-was' and it works for me):

IMHO the default should be `ask'.

[...]

bye
	 Mark

-- 
Mark Trettin · Aachen · Germany · Where is Aachen? --> N: 50°46' E: 06°05'
BOFH excuse #159:

Stubborn processes

Re: Incorporate message-utils.el?

[Kai Großjohann]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> What *I* could do is:
>
> (a) move the defuns to message.el or/and add autoload cookies to
>     message-utils.el.

Good.

> (b) add the menu entries and key-bindings. I suppose this has to be
>     done in `message.el' no matter whether or not we put all functions
>     in `message.el' or leave them in `message-utils.el'.

I think so.  Good.

> (c) put the function call of `message-strip-subject-was' to the spot
>     in `message.el' where `message-header-setup-hook' is called. Would
>     this be enough?

There should be a function which creates the subject by putting "Re:"
in front of it.  So search for the spot where it puts "Re:" in front
of the subject and then make hooks that frob the subject
correspondingly.

What do you think?

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Incorporate message-utils.el?

[Reiner Steib]

On Fri, Sep 13 2002, Kai Großjohann wrote:

> There should be a function which creates the subject by putting "Re:"
> in front of it.  So search for the spot where it puts "Re:" in front
> of the subject 

Ah, I see. One in `message-reply' and the other in `message-followup'.

> and then make hooks that frob the subject correspondingly.

Okay, I think I have to do something similar to this line:

  (setq subject (concat "Re: " (message-strip-subject-re subject)))

> What do you think?

I'll try to do it. 

Concerning item (d) of my previous message (default behavior strip or
not strip the was:...-part) there are different opinions. So I think
we need a user-variable for it at least. Whether the default of this
variable should be 'ask or nil (never do a change) can be decided by
the person committing the patch if we cannot find a consensus on
this. ;-)

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

Re: Incorporate message-utils.el?

[Kai Großjohann]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> On Fri, Sep 13 2002, Kai Großjohann wrote:
>
>> and then make hooks that frob the subject correspondingly.
>
> Okay, I think I have to do something similar to this line:
>
>   (setq subject (concat "Re: " (message-strip-subject-re subject)))

One suggestion: invoke message-make-reply-subject instead, and do
something like

(defcustom message-make-reply-subject-functions
  '(message-strip-subject-re message-util-strip-was)
  "Some useful docstring"
  ...other.custom.stuff...)

(defun message-make-reply-subject (subject)
  (let ((funcs message-make-reply-subject-functions))
    (while funcs
      (setq subject (funcall (pop funcs) subject)))
    subject))

>> What do you think?
>
> I'll try to do it. 
>
> Concerning item (d) of my previous message (default behavior strip or
> not strip the was:...-part) there are different opinions. So I think
> we need a user-variable for it at least. Whether the default of this
> variable should be 'ask or nil (never do a change) can be decided by
> the person committing the patch if we cannot find a consensus on
> this. ;-)

How about message-make-reply-subject-functions?  With a suitably
clever :type declaration, users could easily switch on/off a list of
known functions and also add their own.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Incorporate message-utils.el?

[Reiner Steib]

On Fri, Sep 13 2002, Kai Großjohann wrote:

> Reiner Steib <4uce.02.r.steib@gmx.net> writes:
[...]
> One suggestion: invoke message-make-reply-subject instead, and do
> something like
>
> (defcustom message-make-reply-subject-functions
>   '(message-strip-subject-re message-util-strip-was)
>   "Some useful docstring"
>   ...other.custom.stuff...)
>
> (defun message-make-reply-subject (subject)
>   (let ((funcs message-make-reply-subject-functions))
>     (while funcs
>       (setq subject (funcall (pop funcs) subject)))
>     subject))

Sorry Kai, I haven't received your message in time before I started to
change `message.el' (I had no net connection during the weekend), but
I think we can always add your suggestion later. Up to now, I'm
scrupling, because of the following (but I guess you will convince me
finally ;-) ):

- It would allow the user to produce strange subject like "Antwort:
  Re: ..." very easily. :-(

- Currently, I have the following code:

  (defun message-reply [...]
      (when gnus-list-identifiers
	(setq subject (message-strip-list-identifiers subject)))
      (setq subject (concat "Re: " (message-strip-subject-re subject)))
      (when message-subject-trailing-was-query
	(setq subject (message-strip-subject-trailing-was subject)))

  Should `message-strip-list-identifiers' be in
  `message-make-reply-subject-functions' too? Then m-s-l-i has to
  check for `gnus-list-identifiers' and we call m-s-l-i even if g-l-i
  is nil. For `message-strip-subject-trailing-was' it's similar:
  m-s-s-t-w does nothing when m-s-t-w-q is nil.

- Assume we add new functions later and the user has changed the
  default. If he used add-to-list it should be okay. What about
  customize? Does it respect the (changed) default or does it apply
  the (old) saved value? (Sorry, I don't use customize, so I don't
  know.)

Okay, what I have done so far is the following 

,----[ *Draft* for the ChangeLog entry ]
| 	* message.el (message-strip-subject-trailing-was,
| 	message-change-subject, message-add-archive-header,
| 	message-xpost-fup2-header, message-xpost-insert-note,
| 	message-xpost-fup2, message-reduce-to-to-cc): New functions
| 	adopted from message-utils.el.  Add functions to the keymap (TODO:
| 	in mode describtion) and menu.
| 	(message-change-subject,message-xpost-fup2): Signal error if
| 	current header is empty.
| 	(message-xpost-insert-note): Changed insert position.
| 	(message-archive-note): Ensure to insert note in message body.
| 	(message-archive-header, message-archive-note,
| 	message-xpost-default, message-xpost-note, message-fup2-note,
| 	message-xpost-note-function): New variables adopted from
| 	message-utils.el.  Changed some doc-strings.
| 	(message-mark-insert-{begin,end}): Rename from
| 	message-{begin,end}-inserted-text-mark (message-utils.el), changed
| 	values.
| 	(message-subject-trailing-was-query,
| 	message-subject-trailing-was-ask-regexp,
| 	message-subject-trailing-was-regexp): New variables.
| 	(message-to-list-only): Changed doc-string, added menu entry.
`----

As I moved everything to `message.el', `message-utils.el' can be
removed.

I'm not sure where to put the menu entries for the functions. Which
commands should be in the "Field" and which in the "Message" menu? I
would suggest to put commands acting on the headers of the message to
"Field" and others to "Message":

"Field" menu:

     ["To" message-goto-to t]
     ["From" message-goto-from t]
     ["Subject" message-goto-subject t]
+    ["Change subject" message-change-subject t]
     ["Cc" message-goto-cc t]
+    ["Bcc" message-goto-bcc t]
+    ["Fcc" message-goto-fcc t]
     ["Reply-To" message-goto-reply-to t]
+    "----"
+    ;; (typical) news stuff
     ["Summary" message-goto-summary t]
     ["Keywords" message-goto-keywords t]
     ["Newsgroups" message-goto-newsgroups t]
     ["Followup-To" message-goto-followup-to t]
-    ["Mail-Followup-To" message-goto-mail-followup-to t]
+    ;; ["Followup-To (with note in body)" message-xpost-fup2 t]
+    ["Crosspost / Followup-To" message-xpost-fup2 t]
     ["Distribution" message-goto-distribution t]
+    ["X-No-Archive:" message-add-archive-header t ]
+    "----"
+    ;; (typical) mailing-lists stuff
+    ["Send to list only" message-to-list-only t]
+    ["Mail-Followup-To" message-goto-mail-followup-to t]
+    ["Reduce To: to Cc:" message-reduce-to-to-cc t]
+    "----"
     ["Body" message-goto-body t]
     ["Signature" message-goto-signature t]))

"Message" menu:

+    ["Insert Region Marked" message-mark-inserted-region 
+    ["Insert File Marked" message-mark-insert-file 

But apparently, this is not the convention we have. Looking at the
manual, I found "Flag As (Un)important" in
<info://message/Header+Commands> and "Request Receipt" in
<info://message/Insertion>, though both are in the "Message" menu. I'm
confused. Could somebody explain the convention?

Now the key bindings: It's related to the previous question. If we
consider e.g. `message-change-subject' as a "Field"-command, it should
have a `C-c C-f' prefix, right? I'd suggest these:

+  (define-key message-mode-map "\C-c\C-fs"    'message-change-subject)
+  (define-key message-mode-map "\C-c\C-fx"    'message-xpost-fup2)
+  (define-key message-mode-map "\C-c\C-ft"    'message-reduce-to-to-cc)
+  (define-key message-mode-map "\C-c\C-fa"    'message-add-archive-header)
+  (define-key message-mode-map "\C-c\M-m" 'message-mark-inserted-region)
+  (define-key message-mode-map "\C-c\M-f" 'message-mark-insert-file)

Other suggestions for the key bindings, anyone?

If nobody has objections, I will also change the mode description (add
the key bindings) and the manual (describing the new functions and key
bindings). 

I didn't attach the patch to this message, because it's not complete
as long the above mentioned items are unclear for me.

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

Re: Incorporate message-utils.el?

[Kai Großjohann]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> Sorry Kai, I haven't received your message in time before I started to
> change `message.el' (I had no net connection during the weekend), but
> I think we can always add your suggestion later. Up to now, I'm
> scrupling, because of the following (but I guess you will convince me
> finally ;-) ):

It's the other way round, I guess.  Read on.

> - Currently, I have the following code:
>
>   (defun message-reply [...]
>       (when gnus-list-identifiers
> 	(setq subject (message-strip-list-identifiers subject)))
>       (setq subject (concat "Re: " (message-strip-subject-re subject)))
>       (when message-subject-trailing-was-query
> 	(setq subject (message-strip-subject-trailing-was subject)))
>
>   Should `message-strip-list-identifiers' be in
>   `message-make-reply-subject-functions' too? Then m-s-l-i has to
>   check for `gnus-list-identifiers' and we call m-s-l-i even if g-l-i
>   is nil. For `message-strip-subject-trailing-was' it's similar:
>   m-s-s-t-w does nothing when m-s-t-w-q is nil.

This code looks good.  It convinced me: this seems to be the right way
to do it.  Also, it appears to blend well with the gnus-treat-*
variables which provide a similar interface for article treatment
(though I don't know whether the implementation is similar).

> - Assume we add new functions later and the user has changed the
>   default. If he used add-to-list it should be okay. What about
>   customize? Does it respect the (changed) default or does it apply
>   the (old) saved value? (Sorry, I don't use customize, so I don't
>   know.)

This is the same for all list variables in Emacs, so it's not an
argument, I think.  Eventually, all these cases should be resolved in
the same way.  The current proposals from the emacs-devel list are:

(a) Create two variables, one which contains the system-provided
    stuff and a variable for the user which is always empty by
    default.

(b) Some nifty diff-list feature by Alex Schroeder (I think) which
    augments Customize.  Then, Customize can remember items-to-add to,
    and items-to-remove from, the standard variable value.

> Okay, what I have done so far is the following 

All of it looks good.  It's useless to argue about little details
ahead of time; they can still be changed if the users scream of
agony...

Good job!
kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Incorporate message-utils.el?

[Lars Magne Ingebrigtsen]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> +    ;; ["Followup-To (with note in body)" message-xpost-fup2 t]

A style note -- in Lisp, we don't abbreviate words¹.  There's a
gazillion possible abbreviations for "cross-post", but there's only
one way to write it correctly.  Could you fix the function names?

--------
¹) Unless we do, of course.

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