message-subject-re

message-subject-re

[Michael.Cook]

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

i wanted to inhibit gnus from inserting "Re:" at the beginning of
subject lines.  but it seems that that behavior is hard-coded into
message.el.  here's a patch to unharden that code.

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

--- message.el~	Wed Aug 29 14:21:17 2001
+++ message.el	Wed Aug 29 14:20:52 2001
@@ -228,6 +228,11 @@
   :group 'message-various
   :type 'regexp)
 
+(defcustom message-subject-re "Re: "
+  "*The string to insert at the beginning of subject lines when replying."
+  :group 'message-various
+  :type 'string)
+
 ;;;###autoload
 (defcustom message-signature-separator "^-- *$"
   "Regexp matching the signature separator."
@@ -4181,7 +4186,8 @@
 	    subject (or (message-fetch-field "subject") "none"))
       (when gnus-list-identifiers
 	(setq subject (message-strip-list-identifiers subject)))
-      (setq subject (concat "Re: " (message-strip-subject-re subject)))
+      (setq subject (concat message-subject-re
+			    (message-strip-subject-re subject)))
 
       (when (and (setq gnus-warning (message-fetch-field "gnus-warning"))
 		 (string-match "<[^>]+>" gnus-warning))
@@ -4257,7 +4263,8 @@
 	(setq distribution nil))
       (if gnus-list-identifiers
 	  (setq subject (message-strip-list-identifiers subject)))
-      (setq subject (concat "Re: " (message-strip-subject-re subject)))
+      (setq subject (concat message-subject-re
+			    (message-strip-subject-re subject)))
       (widen))
 
     (message-pop-to-buffer (message-buffer-name "followup" from newsgroups))

Re: message-subject-re

[Paul Jarc]

Michael.Cook@cisco.com wrote:
> i wanted to inhibit gnus from inserting "Re:" at the beginning of
> subject lines.  but it seems that that behavior is hard-coded into
> message.el.  here's a patch to unharden that code.

I'd like to see something more general.  In particular, I'd like
"(was:.*" to be removed from the Subject: in responses.  Maybe a hook
is in order?


paul

Re: message-subject-re

[Michael.Cook]

prj@po.cwru.edu (Paul Jarc) writes:

> Michael.Cook@cisco.com wrote:
> > i wanted to inhibit gnus from inserting "Re:" at the beginning of
>> subject lines.  but it seems that that behavior is hard-coded into
>> message.el.  here's a patch to unharden that code.
>
> I'd like to see something more general.  In particular, I'd like
> "(was:.*" to be removed from the Subject: in responses.  Maybe a hook
> is in order?

i think you might have misunderstood.  message-subject-re is the
string that gnus inserts into the subject line when you start
composing a reply (or follow-up).

the functionality you describe sounds like
`message-subject-re-regexp'.

m.

Re: message-subject-re

[Paul Jarc]

Michael.Cook@cisco.com wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> Michael.Cook@cisco.com wrote:
>> > i wanted to inhibit gnus from inserting "Re:" at the beginning of
>>> subject lines.  but it seems that that behavior is hard-coded into
>>> message.el.  here's a patch to unharden that code.
>>
>> I'd like to see something more general.  In particular, I'd like
>> "(was:.*" to be removed from the Subject: in responses.  Maybe a hook
>> is in order?
> 
> i think you might have misunderstood.  message-subject-re is the
> string that gnus inserts into the subject line when you start
> composing a reply (or follow-up).

I understand.  I'd like to have a more general facility for modifying
the subject when composing a response.  This could incorporate adding
"Re: " and removing a trailing "(was:.*".  Maybe also remove
"Re\[[0-9]+\]:" or something.

I see we already have message-header-setup-hook; would this work?  But
we don't yet have functions to add to it to clean up the subject.  Or
do we?

> the functionality you describe sounds like
> `message-subject-re-regexp'.

I'm not sure what that does - is it used to decide when to add "Re:"?
Or to group threads by subject?  Anyway, I don't think it's what I'm
looking for.


paul

Re: message-subject-re

[Simon Josefsson]

prj@po.cwru.edu (Paul Jarc) writes:

> Michael.Cook@cisco.com wrote:
> > prj@po.cwru.edu (Paul Jarc) writes:
>>> Michael.Cook@cisco.com wrote:
>>> > i wanted to inhibit gnus from inserting "Re:" at the beginning of
>>>> subject lines.  but it seems that that behavior is hard-coded into
>>>> message.el.  here's a patch to unharden that code.
>>>
>>> I'd like to see something more general.  In particular, I'd like
>>> "(was:.*" to be removed from the Subject: in responses.  Maybe a hook
>>> is in order?
>> 
>> i think you might have misunderstood.  message-subject-re is the
>> string that gnus inserts into the subject line when you start
>> composing a reply (or follow-up).
>
> I understand.  I'd like to have a more general facility for modifying
> the subject when composing a response.  This could incorporate adding
> "Re: " and removing a trailing "(was:.*".  Maybe also remove
> "Re\[[0-9]+\]:" or something.

Inspired by `message-make-forward-subject-function':

Index: message.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/message.el,v
retrieving revision 6.117
diff -u -u -w -u -w -r6.117 message.el
--- message.el	2001/08/19 02:01:24	6.117
+++ message.el	2001/08/29 19:33:23
@@ -228,6 +228,29 @@
   :group 'message-various
   :type 'regexp)
 
+(defcustom message-subject-re "Re: "
+  "*The string to insert at the beginning of subject lines when replying."
+  :group 'message-various
+  :type 'string)
+
+(defcustom message-make-re-subject-function '(message-strip-list-identifiers
+					      message-strip-subject-re
+					      message-add-subject-re)
+  "*List of functions called to massage subject lines when replying.
+The subject generated by the previous function is passed into each
+successive function.
+
+The provided functions (which both are used by default) are:
+
+* `message-strip-list-identifiers' (Removes `gnus-list-identifiers'.)
+* `message-strip-subject-re' (Removes `message-subject-re-regexp'.)
+* `message-add-subject-re' (Prepends \"Re: \".)
+"
+  :group 'message-various
+  :type '(radio (function-item message-strip-subject-re)
+		(function-item message-strip-list-identifiers)
+		(repeat :tag "List of functions" function)))
+
 ;;;###autoload
 (defcustom message-signature-separator "^-- *$"
   "Regexp matching the signature separator."
@@ -1291,6 +1314,25 @@
       (substring subject (match-end 0))
     subject))
 
+(defun message-add-subject-re (subject)
+  "Prepend \"Re:\" to SUBJECT."
+  (concat message-subject-re subject))
+
+(defun message-make-re-subject (subject)
+  "Return a Subject header suitable for replying in the current buffer."
+  (let ((funcs message-make-re-subject-function))
+    ;; Make sure funcs is a list.
+    (and funcs
+	 (not (listp funcs))
+	 (setq funcs (list funcs)))
+    ;; Apply funcs in order, passing subject generated by previous
+    ;; func to the next one.
+    (while funcs
+      (when (message-functionp (car funcs))
+	(setq subject (funcall (car funcs) subject)))
+      (setq funcs (cdr funcs)))
+    subject))
+
 (defun message-remove-header (header &optional is-regexp first reverse)
   "Remove HEADER in the narrowed buffer.
 If IS-REGEXP, HEADER is a regular expression.
@@ -4179,10 +4221,7 @@
 	    date (message-fetch-field "date")
 	    from (message-fetch-field "from")
 	    subject (or (message-fetch-field "subject") "none"))
-      (when gnus-list-identifiers
-	(setq subject (message-strip-list-identifiers subject)))
-      (setq subject (concat "Re: " (message-strip-subject-re subject)))
-
+      (setq subject (message-make-re-subject subject))
       (when (and (setq gnus-warning (message-fetch-field "gnus-warning"))
 		 (string-match "<[^>]+>" gnus-warning))
 	(setq message-id (match-string 0 gnus-warning)))
@@ -4255,9 +4294,7 @@
 		 (let ((case-fold-search t))
 		   (string-match "world" distribution)))
 	(setq distribution nil))
-      (if gnus-list-identifiers
-	  (setq subject (message-strip-list-identifiers subject)))
-      (setq subject (concat "Re: " (message-strip-subject-re subject)))
+      (setq subject (message-make-re-subject subject))
       (widen))
 
     (message-pop-to-buffer (message-buffer-name "followup" from newsgroups))

Re: message-subject-re

[Henrik Enberg]

Simon Josefsson <jas@extundo.com> writes:

[...]

> Inspired by `message-make-forward-subject-function':

Ick, does this mean that we're going to see people posting with Gnus
using Sv: style subject lines and non-standard sig separators?

I think some stuff _should_ be hardcoded.

Henrik
-- 
Could I have a drug overdose?

Re: message-subject-re

[Paul Jarc]

Henrik Enberg <henrik@enberg.org> wrote:
> Ick, does this mean that we're going to see people posting with Gnus
> using Sv: style subject lines and non-standard sig separators?
> 
> I think some stuff _should_ be hardcoded.

It's already possible to do those things.  Maybe
message-make-re-subject-function makes it easier to do bad things, but
the defaults encourage good behavior.


paul

Re: message-subject-re

[Michael.Cook]

prj@po.cwru.edu (Paul Jarc) writes:

> the defaults encourage good behavior.

the help text could actively discourage people from changing the
reply prefix:

(defcustom message-subject-re "Re: "
  "*The string to insert at the beginning of subject lines when replying.
The standard value is \"Re: \" regardless of what language you use elsewhere
in your email messages.  Most mail readers look for \"Re: \" at the beginning
of subject lines and handle that prefix specially.  Selecting a different
prefix value would likely confuse most mail readers."
  :group 'message-various
  :type 'string)

m.

Re: message-subject-re

[Frank Schmitt]

Henrik Enberg <henrik@enberg.org> writes:
 
>Ick, does this mean that we're going to see people posting with Gnus
>using Sv: style subject lines and non-standard sig separators?
>
>I think some stuff _should_ be hardcoded.

100% acknowledge.

-- 
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
19. Dezember 2001

Re: message-subject-re

[Michael.Cook]

Frank Schmitt <Azzrael@rz-online.de> writes:

> Henrik Enberg <henrik@enberg.org> writes:
>
>>Ick, does this mean that we're going to see people posting with Gnus
>>using Sv: style subject lines and non-standard sig separators?
>>
>>I think some stuff _should_ be hardcoded.
>
> 100% acknowledge.

well, all i really wanted to do was suppress the "Re:".
that seems reasonable, no?

Re: message-subject-re

[Daniel Pittman]

On Wed, 29 Aug 2001, Michael Cook wrote:
> Frank Schmitt <Azzrael@rz-online.de> writes:
> 
>> Henrik Enberg <henrik@enberg.org> writes:
>>
>>>Ick, does this mean that we're going to see people posting with Gnus
>>>using Sv: style subject lines and non-standard sig separators?
>>>
>>>I think some stuff _should_ be hardcoded.
>>
>> 100% acknowledge.
> 
> well, all i really wanted to do was suppress the "Re:".
> that seems reasonable, no?

It's certainly not in the category of "best practice" and, while I can't
find an RFC reference that mandates it for email, it's strongly
suggested by RFC822...

...and it does mean that it's not going to be possible for some email
clients that use the subject line to sort threads to tell that your
messages are part of one.

Er, /why/ do you want to do that?
        Daniel

-- 
If Americans can be divorced for "incompatibility of temper" I cannot conceive
why they are not all divorced. I have known many happy marriages, but never a
compatible one.
        -- _What is Wrong with the World_ (1910)

Re: message-subject-re

[Michael.Cook]

Daniel Pittman <daniel@rimspace.net> writes:

> ...and it does mean that it's not going to be possible for some email
> clients that use the subject line to sort threads to tell that your
> messages are part of one.

that's not really possible in general anyhow.  mailers and remailers
mangle subject lines in many various ways that make sorting by
subject line challenging at best.

> Er, /why/ do you want to do that?

after seeing one too many subject lines that looked like

  Subject: Re: Fwd: FW: [list-name] RE: Fwd: foo

it occurred to me that the Re prefix has no real value.  that it's
probably just a hold-over from way back before mail readers were
sophisticated enough to use the References and other headers.  one
of those things that mailers do because, well, they've just always
done it that way.  and for no other reason.  this kind of meta-data
doesn't need to be encoded into the subject line.  there are other
headers for that.

m.

Re: message-subject-re

[Daniel Pittman]

On Wed, 29 Aug 2001, Michael Cook wrote:
> Daniel Pittman <daniel@rimspace.net> writes:
> 
>> ...and it does mean that it's not going to be possible for some email
>> clients that use the subject line to sort threads to tell that your
>> messages are part of one.
> 
> that's not really possible in general anyhow.  mailers and remailers
> mangle subject lines in many various ways that make sorting by
> subject line challenging at best.

Oh, it's possible. It's not /effective/, but it's possible. It's also
the only mode of operation for many of the Win32 mailers out there.

Oddly, enough, it's the default mode of operation for all the ones that
can't get the References header right, generally, which are the *cause*
of the inability to thread any other way... *sigh*

>> Er, /why/ do you want to do that?
> 
> after seeing one too many subject lines that looked like
> 
>   Subject: Re: Fwd: FW: [list-name] RE: Fwd: foo
> 
> it occurred to me that the Re prefix has no real value.  that it's
> probably just a hold-over from way back before mail readers were
> sophisticated enough to use the References and other headers.  one
> of those things that mailers do because, well, they've just always
> done it that way.  and for no other reason.  this kind of meta-data
> doesn't need to be encoded into the subject line.  there are other
> headers for that.

Ah, but it /does/ contain more than just a hold-over value, just like
the cited text: it tells me, as a human, what this message is.

Specifically, it *does* contain the information that this is a message
in reference to another, not an original message itself. It also serves
to identify which message it was.

Now, Gnus /could/ insert that bit of text itself based on the References
header ... but that's not going to work unless the world gets that
right.

Maybe it's even part of the new SMTP/RFC822 codification RFC documents
that went out recently. Let's check, shall we?

...time passes...

Ah, here we are. <http://www.imc.org/rfc2822>

So, they say that the subject field MAY be prefixed with "Re: " when
it's a reply. I guess that the authors felt that this was not quite
vital to the operation of the mail system, but that it's not a bad idea.

So, your "not insert Re" is legal by the new mail format RFC. Cool. I
still don't think it's a good idea, but that's because my mailer doesn't
do it for me, which it legitimately could.


I strongly agree that the various mailing list tags and mangling, etc,
reduce the value of the field, though. There should be Gnus
functionality to clean those up so that we can see and send well formed
messages.

        Daniel

-- 
Hocine Bibo Aut In Eum Digitos Insero?

Re: message-subject-re

[Paul Jarc]

Michael.Cook@cisco.com wrote:
> after seeing one too many subject lines that looked like
> 
>   Subject: Re: Fwd: FW: [list-name] RE: Fwd: foo
> 
> it occurred to me that the Re prefix has no real value.

Well, preserving all that without adding another Re: isn't a big
improvement.  Maybe it would be best to first strip away all Re:s,
Fwd:s, and such, and then prepend a single Re:.  So a response to the
above would get "Re: [list-name] foo".

Yes, the list tag should be preserved in outgoing messages, after the
Re:.  Otherwise, when it passes through the list manager, it'll come
out like "[list-name] Re: foo", which breaks everything that expects
to find an existing Re: only at the beginning.  Such programs would
then tend to add another Re: at the beginning, which exacerbates the
problem we're trying to ameliorate.

You might hide the tag from yourself when *viewing* messages, but when
responding, it'd be nice to make things come out right for people who
don't hide it.  I think doing this might be rather nontrivial, though -
when setting up the response buffer, Gnus would have to re-fetch the
article to find the tag, if any.  Or else it'd have to stash the tag
somewhere (a buffer-local variable, maybe?) when removing it.


paul

Re: message-subject-re

[Michael.Cook]

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

prj@po.cwru.edu (Paul Jarc) writes:

> Michael.Cook@cisco.com wrote:
> > after seeing one too many subject lines that looked like
>> 
>>   Subject: Re: Fwd: FW: [list-name] RE: Fwd: foo
>> 
>> it occurred to me that the Re prefix has no real value.
>
> Well, preserving all that without adding another Re: isn't a big
> improvement.  Maybe it would be best to first strip away all Re:s,

ok, but that's a separate issue -- cleaning up subject lines that
have already been mangled.  sure, it'd be nice if gnus could wash
the subject line for display in the summary buffer (can gnus be
configured to do that already?).  but all i really wanted to do when
i started this thread was to keep gnus from inserting "Re:" into the
subject line in new messages i compose.

ok, here's another patch.  this one adds a boolean
`message-subject-inhibit-re'.

m.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: message-subject-inhibit-re.patch --]
[-- Type: text/x-patch, Size: 1354 bytes --]

--- message.el~	Thu Aug 30 12:26:08 2001
+++ message.el	Thu Aug 30 12:29:43 2001
@@ -228,6 +228,11 @@
   :group 'message-various
   :type 'regexp)
 
+(defcustom message-subject-inhibit-re nil
+  "Non-nil means don't insert Re: in the subject line when replying."
+  :group 'message-various
+  :type 'boolean)
+
 ;;;###autoload
 (defcustom message-signature-separator "^-- *$"
   "Regexp matching the signature separator."
@@ -4181,7 +4186,9 @@
 	    subject (or (message-fetch-field "subject") "none"))
       (when gnus-list-identifiers
 	(setq subject (message-strip-list-identifiers subject)))
-      (setq subject (concat "Re: " (message-strip-subject-re subject)))
+      (setq subject (concat (and (not message-subject-inhibit-re)
+				 "Re: ")
+			    (message-strip-subject-re subject)))
 
       (when (and (setq gnus-warning (message-fetch-field "gnus-warning"))
 		 (string-match "<[^>]+>" gnus-warning))
@@ -4257,7 +4264,9 @@
 	(setq distribution nil))
       (if gnus-list-identifiers
 	  (setq subject (message-strip-list-identifiers subject)))
-      (setq subject (concat "Re: " (message-strip-subject-re subject)))
+      (setq subject (concat (and (not message-subject-inhibit-re)
+				 "Re: ")
+			    (message-strip-subject-re subject)))
       (widen))
 
     (message-pop-to-buffer (message-buffer-name "followup" from newsgroups))

Re: message-subject-re

[Jesper Harder]

Michael.Cook@cisco.com writes:

> ok, but that's a separate issue -- cleaning up subject lines that
> have already been mangled.  sure, it'd be nice if gnus could wash
> the subject line for display in the summary buffer (can gnus be
> configured to do that already?).

Yep, look at 'nnmail-remove-list-identifiers' and 'gnus-list-identifiers'.

-- 
Cheers,
Jesper Harder

Re: message-subject-re

[Per Abrahamsen]

Frank Schmitt <Azzrael@rz-online.de> writes:

> Henrik Enberg <henrik@enberg.org> writes:
>  
>>Ick, does this mean that we're going to see people posting with Gnus
>>using Sv: style subject lines and non-standard sig separators?
>>
>>I think some stuff _should_ be hardcoded.
> 
> 100% acknowledge.

Me to.  Please leave this hardcoded.

Re: message-subject-re

[Paul Jarc]

Simon Josefsson <jas@extundo.com> wrote:
>+The provided functions (which both are used by default) are:
>+
>+* `message-strip-list-identifiers' (Removes `gnus-list-identifiers'.)
>+* `message-strip-subject-re' (Removes `message-subject-re-regexp'.)
>+* `message-add-subject-re' (Prepends \"Re: \".)

Err, "both"? :)  Here's one to get rid of "(was:.*".  I think there's
an RFC that says this should be done, but I can't remember anything
concrete.

(defun message-subject-strip-was (subject)
  "Remove \" +(was:.*\" from SUBJECT."
  (save-match-data
    (if (string-match " +(was:" subject)
        (substring subject 0 (match-beginning 0))
      subject)))


paul

Re: message-subject-re

[Simon Josefsson]

Simon Josefsson <jas@extundo.com> writes:

> +  :type '(radio (function-item message-strip-subject-re)
> +		(function-item message-strip-list-identifiers)
> +		(repeat :tag "List of functions" function)))

This :type isn't perfect, replacing `radio' with `checklist' would be
better (if `checklist' existed..), but the following seem to be as
close as you can get:

  :type '(repeat :tag "List of functions" function))

Wouldn't it be nice if the `function' behaved like `function-item' and
displayed the documentation for the function currently entered?

(Maybe there is a Custom list for this..)

Re: message-subject-re

[Per Abrahamsen]

Simon Josefsson <jas@extundo.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
> 
>> +  :type '(radio (function-item message-strip-subject-re)
>> +		(function-item message-strip-list-identifiers)
>> +		(repeat :tag "List of functions" function)))
> 
> This :type isn't perfect, replacing `radio' with `checklist' would be
> better (if `checklist' existed..), but the following seem to be as
> close as you can get:
> 
>  :type '(repeat :tag "List of functions" function))

What do you mean "if `checklist' existed.."?

There exists a widget named 'checklist', although 'set' would be more
appropriate for a top level customize type.  However, a checklist
isn't expandable.

It would be tempting to give the option the 'hook' type, which would
work perfectly... except that it would be a lie, hook functions
doesn't take arguments.

The correct solution would probably be to create an 'expandable-list'
widget, which mimics the 'alist' and 'plist' widgets, and derive
'function-list' and 'hook' from that.  Someone remind me of that when
Emacs 21 is released.

For now, do it by hand.  Here is an example.

(defcustom message-make-re-subject-functions
  '(message-strip-list-identifiers
    message-strip-subject-re message-add-subject-re)
  "List of functions called to massage subject lines when replying.
The subject generated by the previous function is passed into each
successive function.

The provided functions (which both are used by default) are:

* `message-strip-list-identifiers' (Removes `gnus-list-identifiers'.)
* `message-strip-subject-re' (Removes `message-subject-re-regexp'.)
* `message-add-subject-re' (Prepends \"Re: \".)
"
  :group 'message-various
  :type '(list (checklist :inline t
			  :greedy t
			  (function-item message-strip-subject-re)
			  (function-item message-strip-list-identifiers))
	       (editable-list :inline t
			      :tag "List of functions" function)))

Some style notes: I believe '-functions' (not '-function') is the
conventional suffix for a list functions.  Also, the user is unlikely
to set this variable during a normal Emacs session, so there should
not be any '*' at the start of the documentation string.  The '*' does
not mean "user option".  'defcustom' means "user option".  The '*'
means it make sense to change interactively during normal use.  A good
example is 'case-fold-search'.

> Wouldn't it be nice if the `function' behaved like `function-item' and
> displayed the documentation for the function currently entered?

I think it could be confusing during editing.

> (Maybe there is a Custom list for this..)

<URL: mailto:emacs-custom@sunsite.dk >

Re: message-subject-re

[Simon Josefsson]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

>>> +  :type '(radio (function-item message-strip-subject-re)
>>> +		(function-item message-strip-list-identifiers)
>>> +		(repeat :tag "List of functions" function)))
>> 
>> This :type isn't perfect, replacing `radio' with `checklist' would be
>> better (if `checklist' existed..), but the following seem to be as
>> close as you can get:
>> 
>>  :type '(repeat :tag "List of functions" function))
>
> What do you mean "if `checklist' existed.."?

It didn't work to simply replace `radio' with `checklist', so I
reckoned it didn't exist.

>   :type '(list (checklist :inline t
> 			  :greedy t
> 			  (function-item message-strip-subject-re)
> 			  (function-item message-strip-list-identifiers))
> 	       (editable-list :inline t
> 			      :tag "List of functions" function)))

This is very nice.  Thank you.

Re: message-subject-re

[Per Abrahamsen]

Simon Josefsson <jas@extundo.com> writes:

> It didn't work to simply replace `radio' with `checklist', so I
> reckoned it didn't exist.

You can use M-x widget-browse <ret> <tab> to check which widgets
exists, although the widget doc strings rarely are very useful.

Re: message-subject-re

[Steve Youngs]

|--==> "PJ" == Paul Jarc <prj@po.cwru.edu> writes:

  PJ> I'd like to see something more general.  In particular, I'd like
  PJ> "(was:.*" to be removed from the Subject: in responses.  Maybe a hook
  PJ> is in order?

I use:

(defconst steve-obsolete-subject " (?was: .*"
  "*Regexp matching obsolete subjects.")

(defun steve-clear-subject ()
  "Remove steve-obsolete-subject from subject-header."
  (interactive)
  (let ((case-fold-search nil))
    (save-excursion
      (goto-line 0)
      (re-search-forward "^Subject: ")
      (if (re-search-forward steve-obsolete-subject nil t)
	  (replace-match "")))))

(define-key message-mode-map '"\M-o" 'steve-clear-subject)

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
|            XEmacs - It's not just an editor.             |
|                    It's a way of life.                   |
|------------------------------------<youngs@xemacs.org>---|

message-change-subject-interactively (was: message-subject-re)

[Toby Speight]

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

0> In article <m3n14i3ejt.fsf@multivac.cwru.edu>,
0> Paul R. Jarc <URL:mailto:prj@po.cwru.edu> ("Paul") wrote:

Paul> ... I'd like "(was:.*" to be removed from the Subject: in
Paul> responses.  Maybe a hook is in order?

Here's what I use:



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

(defun message-change-subject-interactively (&optional new-subj) ;gnus-subject-interactive
  "Change the Subject, bracketing with \"(was...)\" if necessary."
  (interactive "*")
  (undo-boundary)
  (save-excursion
    (save-restriction
      (message-narrow-to-headers-or-head)
      (let* ((subject (message-fetch-field "Subject"))
             (case-fold-search t))
        (if (null subject)
            (setq new-subj (read-from-minibuffer "New Subject: "))
          ;; There was already a subject
          (when (string-match "\\s-+\\'" subject) ; remove trailing spaces
            (setq subject (replace-match "" t t subject)))
          (if (and (not new-subj) (string-match "^[Rr][Ee]\\>" subject))
              ;; only ask if it wasn't our subject
              (setq new-subj
                    (read-from-minibuffer (concat "New Subject: (was " subject ") "))))
          ;; new-subj is nil if we already have an original subject (not starting with "Re:")
          ;; It is a string if we are following-up (so might want to remove "(was ...)")
          (if (and new-subj
                   (or                  ;(re-search-forward "\\s-*\\((was\\>.*\\)" subject-end t)
                    (string-match "\\s-*\\([[(,;]\\s-*was\\>.*\\)" subject)
                    (string-match "\\s-*\\<\\(was:?\\s-+[Rr][Ee]:.*\\)" subject)
                    (string-match "\\s-*[[(,;]\\s-*\\([Rr][Ee]:.*\\)" subject))
                   (or (not (string= new-subj "")) ; if replacing, force removal
                       (y-or-n-p (concat "Remove \"" (match-string 1 subject) "\" from Subject: line? "))))
              (setq new-subj (replace-match "" t t subject)
                    subject nil))
          (if (or (null new-subj) (string= "" new-subj))
              ;; No true change in subject
              (setq new-subj subject
                    subject nil)
            ;;  User changed the subject
            ;; first undo RFC-822 line-wrap
            (while (and subject (string-match "\n[ \t]" subject))
              (setq subject (replace-match " " t t subject)))
            ;; might be a followup to a forwarded message, so trim [...] too
            (while (and subject (string-match message-change-subject-ignored-prefixes subject))
              (setq subject (replace-match "" t t subject)))
            ;; Trim subject line to 75 chars (leaving room for a recipient to add "Re: ")
            ;; "Subject: "(9) + new-subj + "(was: "(6) + subject + "...)"(1 or 4)  <=75
            ;; means subject<=(59 - new-subj) or trim to (56 - new-subj)
            (if (and subject (> (length subject) (- 59 (length new-subj))))
                (let ((maxlen (- 56 (length new-subj))))
                  (if (<= maxlen 0)
                      (setq subject "...")
                    ;; keep one extra char, so we know if last char is a word-boundary
                    (setq subject (substring subject 0 (1+ maxlen)))
                    (if (string-match "\\s-*\\(\\B.\\|\\<.\\)*\\'" subject)
                        (setq subject (replace-match "..." t t subject))))))))
        (widen)
        (when new-subj
          (if (and subject (not (string= "" subject)))
              (setq new-subj (concat new-subj " (was: " subject ")")))
          (message-goto-subject)
          (message-delete-line)
          (insert "Subject: " new-subj "\n"))))))

[-- Attachment #3: Type: text/plain, Size: 13 bytes --]


along with


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: Type: text/x-emacs-lisp, Size: 68 bytes --]

(add-hook 'message-send-hook 'message-change-subject-interactively)

[-- Attachment #5: Type: text/plain, Size: 490 bytes --]


to invoke it every time I respond to an article.

It won't change the subject if it doesn't begin with "Re:", assuming
instead that you've written your own subject line, rather than having
a generated one.


BTW the string "Re: " is important, and should never be changed to any
other value unless you want to look like an MS-luser trying to break news
(e.g. such nonstandard prefixes break gnus-gather-threads-by-subject and
avoidance of duplicate "Re: " prefixes, amongst other things).

Re: message-subject-re

[Colin Marquardt]

prj@po.cwru.edu (Paul Jarc) writes:

> I'd like to see something more general.  In particular, I'd like
> "(was:.*" to be removed from the Subject: in responses.  Maybe a hook
> is in order?

Holger Schauer's message-utils.el does that.

Colin

message-subject-re

[Michael.Cook]

Colin Marquardt <c.marquardt@alcatel.de> writes:

> Holger Schauer's message-utils.el does that.

ftr:

http://www.gnus.org/list-archives/ding/200104/msg00487.html

m.