Two gnus-posting-styles problems

Two gnus-posting-styles problems

[Hrvoje Niksic]

1. It's unclear exactly what a HEADER match in fact matches.  First I
   thought it matches the header in the message buffer.  I thought
   this would work:

     ;; Use Red Hat address when responding to Red Hat people.
     ((header "to" "redhat.com")
      (address "hniksic@redhat.com"))

   But it doesn't, because it matches the "gnus article copy" buffer.

1a. Even worse, it uses the "gnus article copy" buffer even when it is
    completely unrelated to the message currently being composed.  For
    example, I pressed `a' or `m' in the Summary buffer and was trying
    to figure out why the hell it thought that the Red Hat address
    should be used.  It turned out that my old "gnus article copy"
    buffer happened addressed to a Red Hat person.

2. I tried to fix #1 by explicitly matching the stuff from the Message
   buffer, like this:

     ((and (message-fetch-field "to")
           (string-match "redhat\\.com" (message-fetch-field "to")))
      (address "hniksic@redhat.com"))

   But that didn't work because `gnus-configure-posting-styles' is
   called from `message-mode-hook', which gets run when the Message
   buffer is still completely empty.  It should be called at a later
   stage, when the buffer has already been set up.

   The code that manages various hooks in gnus-setup-message and
   gnus-configure-posting-styles appeared quite convoluted, so I
   didn't dare try the "obvious" changes.

Has anyone else stumbled upon these problems?  Am I the only one who
is trying to use `gnus-posting-styles' in this way?

As a workaround, I think I'll just revert to using a good ol' hook.

Re: Two gnus-posting-styles problems

[Paul Jarc]

Hrvoje Niksic <hniksic@xemacs.org> wrote:
> 1a. Even worse, it uses the "gnus article copy" buffer even when it is
>     completely unrelated to the message currently being composed.

I've seen this too.

>    But that didn't work because `gnus-configure-posting-styles' is
>    called from `message-mode-hook', which gets run when the Message
>    buffer is still completely empty.  It should be called at a later
>    stage, when the buffer has already been set up.

Maybe you'd like header-action.el.


paul

Re: Two gnus-posting-styles problems

[David S Goldberg]

I ran into this ages ago and came up with this, which is very
convoluted, but works around the problem reasonably well.  Much as I
love programming in lisp, I don't consider myself very good at it, so
while this may be an appropriate framework, it could probably do with
some optimization.

	      (gnus-article-reply
	       (signature-file
		(let* ((net-from
			(save-excursion
			  (set-buffer gnus-article-buffer)
			  (car
			   (cdr
			    (mail-extract-address-components
			     (message-fetch-field "From"))))))
		       (net-to
			(save-excursion
			  (set-buffer gnus-article-buffer)
			  (or (message-fetch-field "to") "")))
		       (net-cc
			(save-excursion
			  (set-buffer gnus-article-buffer)
			  (or (message-fetch-field "cc") "")))
		       (rec (car (bbdb-search
				  (bbdb-records) nil nil
				  net-from nil nil)))
		       (sig (if rec
				(bbdb-record-getprop
				 rec 'signature))))
		  (cond ((and (string-match "@.*\\.?mitre\\.org"
					    net-from)
			      (or
			       (string-match
				"dsg@.*\\.?mitre\\.org"
				net-to)
			       (string-match
				"dsg@.*\\.?mitre\\.org"
				net-cc)))
			 "~/.signature-mitre-i")
			((or
			  (string-match "dsg@.*\\.?mitre\\.org"
					net-to)
			  (string-match "dsg@.*\\.?mitre\\.org"
					net-cc))
			 "~/.signature-mitre")
			(sig sig)				      
			((string-match
			  ".*:.*personal.*"
			  (or gnus-newsgroup-name ""))
			 "~/.signature-personal")
			((string-match
			  ".*emacs.*"
			  (or gnus-newsgroup-name ""))
			 "~/.signature-personal")
			((string-match
			  ".*fvwm.*"
			  (or gnus-newsgroup-name ""))
			 "~/.signature-personal")
			((string-match
			  "nnml:missedmail"
			  (or gnus-newsgroup-name ""))
			 "~/.signature-personal")
			(t "~/.signature-mitre"))))
	       (address
		(let* ((net-from
			(save-excursion
			  (set-buffer gnus-article-buffer)
			  (car
			   (cdr
			    (mail-extract-address-components
			     (message-fetch-field
			      "From"))))))
		       (net-to
			(save-excursion
			  (set-buffer gnus-article-buffer)
			  (or (message-fetch-field "to") "")))
		       (net-cc
			(save-excursion
			  (set-buffer gnus-article-buffer)
			  (or (message-fetch-field "cc") "")))
		       (rec (car (bbdb-search
				  (bbdb-records) nil nil
				  net-from nil nil)))
		       (mail-from (if rec
				      (bbdb-record-getprop
				       rec 'mail-from))))
		  (cond ((or
			  (string-match "dsg@.*\\.?mitre\\.org"
					net-to)
			  (string-match "dsg@.*\\.?mitre\\.org"
					net-cc))
			 ,dsg-mitre-address)
			(mail-from mail-from)
			((string-match
			  ".*:.*personal.*"
			  (or gnus-newsgroup-name ""))
			 ,dsg-personal-address)
			((string-match
			  ".*emacs.*"
			  (or gnus-newsgroup-name ""))
			 ,dsg-personal-address)
			((string-match
			  ".*fvwm.*"
			  (or gnus-newsgroup-name ""))
			 ,dsg-personal-address)
			((string-match
			  "nnml:missedmail"
			  (or gnus-newsgroup-name ""))
			 ,dsg-personal-address)
			(t ,dsg-mitre-address)))))

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: Two gnus-posting-styles problems

[Simon Josefsson]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> 1. It's unclear exactly what a HEADER match in fact matches.  First I
>    thought it matches the header in the message buffer.  I thought
>    this would work:
>
>      ;; Use Red Hat address when responding to Red Hat people.
>      ((header "to" "redhat.com")
>       (address "hniksic@redhat.com"))
>
>    But it doesn't, because it matches the "gnus article copy" buffer.

Yes -- the "header" posting style uses to the last viewed message, I
think this is documented, altough perhaps not well enough.

Perhaps

      ((header "from" "redhat.com")
       (address "hniksic@redhat.com"))

is useful?

> 1a. Even worse, it uses the "gnus article copy" buffer even when it is
>     completely unrelated to the message currently being composed.  For
>     example, I pressed `a' or `m' in the Summary buffer and was trying
>     to figure out why the hell it thought that the Red Hat address
>     should be used.  It turned out that my old "gnus article copy"
>     buffer happened addressed to a Red Hat person.

I agree it is confusing.  Does the patch below help?

> 2. I tried to fix #1 by explicitly matching the stuff from the Message
>    buffer, like this:
>
>      ((and (message-fetch-field "to")
>            (string-match "redhat\\.com" (message-fetch-field "to")))
>       (address "hniksic@redhat.com"))
>
>    But that didn't work because `gnus-configure-posting-styles' is
>    called from `message-mode-hook', which gets run when the Message
>    buffer is still completely empty.  It should be called at a later
>    stage, when the buffer has already been set up.

There's a dependency problem here, not all functions that use
information from the message buffer and modify the contents of the
message buffer can be called last.  I think the ordering has changed
several times, but it won't ever satisfy everyone.  I think the
approach should be that you shouldn't count on information being
available in the message buffers unless... err, it is available.

Index: gnus-msg.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-msg.el,v
retrieving revision 6.92
diff -u -p -u -w -r6.92 gnus-msg.el
--- gnus-msg.el	2002/05/30 10:19:30	6.92
+++ gnus-msg.el	2002/06/03 17:55:48
@@ -242,9 +242,15 @@ See also the `mml-default-encrypt-method
 (defcustom gnus-confirm-mail-reply-to-news nil
   "If non-nil, Gnus requests confirmation when replying to news.
 This is done because new users often reply by mistake when reading
-news."
+news.
+This can also be a function which should return non-nil iff a
+confirmation is needed, or a regexp, in which case a confirmation is
+asked if the group name matches the regexp."
   :group 'gnus-message
-  :type 'boolean)
+  :type '(choice (const :tag "No" nil)
+		 (const :tag "Yes" nil)
+		 (regexp :tag "Iff group matches regexp")
+		 (function :tag "Iff function evaluates to non-nil")))
 
 ;;; Internal variables.
 
@@ -490,6 +496,8 @@ If ARG is 1, prompt for a group name to 
   ;; We can't `let' gnus-newsgroup-name here, since that leads
   ;; to local variables leaking.
   (let ((group gnus-newsgroup-name)
+	;; make sure last viewed article doesn't affect posting styles:
+	(gnus-article-copy)
 	(buffer (current-buffer)))
     (unwind-protect
 	(progn
@@ -519,6 +527,8 @@ network.  The corresponding backend must
   ;; We can't `let' gnus-newsgroup-name here, since that leads
   ;; to local variables leaking.
   (let ((group gnus-newsgroup-name)
+	;; make sure last viewed article doesn't affect posting styles:
+	(gnus-article-copy)
 	(buffer (current-buffer)))
     (unwind-protect
 	(progn
@@ -550,7 +560,9 @@ a news."
 		 (completing-read "Newsgroup: " gnus-active-hashtb nil
 				  (gnus-read-active-file-p))
 	       (gnus-group-group-name))
-	   "")))
+	   ""))
+	;; make sure last viewed article doesn't affect posting styles:
+	(gnus-article-copy))
     (gnus-post-news 'post gnus-newsgroup-name)))
 
 (defun gnus-summary-mail-other-window (&optional arg)
@@ -562,6 +574,8 @@ posting style."
   ;; We can't `let' gnus-newsgroup-name here, since that leads
   ;; to local variables leaking.
   (let ((group gnus-newsgroup-name)
+	;; make sure last viewed article doesn't affect posting styles:
+	(gnus-article-copy)
 	(buffer (current-buffer)))
     (unwind-protect
 	(progn
@@ -591,6 +605,8 @@ network.  The corresponding backend must
   ;; We can't `let' gnus-newsgroup-name here, since that leads
   ;; to local variables leaking.
   (let ((group gnus-newsgroup-name)
+	;; make sure last viewed article doesn't affect posting styles:
+	(gnus-article-copy)
 	(buffer (current-buffer)))
     (unwind-protect
 	(progn
@@ -991,7 +1007,11 @@ If VERY-WIDE, make a very wide reply."
   ;; Allow user to require confirmation before replying by mail to the
   ;; author of a news article.
   (when (or (not (gnus-news-group-p gnus-newsgroup-name))
-	    (not gnus-confirm-mail-reply-to-news)
+	    (not (cond ((stringp gnus-confirm-mail-reply-to-news)
+			(string-match gnus-confirm-mail-reply-to-news gnus-newsgroup-name))
+		       ((functionp gnus-confirm-mail-reply-to-news)
+			(funcall gnus-confirm-mail-reply-to-news))
+		       (t gnus-confirm-mail-reply-to-news)))
 	    (y-or-n-p "Really reply by mail to article author? "))
     (let* ((article
 	    (if (listp (car yank))

Re: Two gnus-posting-styles problems

[Hrvoje Niksic]

Simon Josefsson <jas@extundo.com> writes:

> Perhaps
>
>       ((header "from" "redhat.com")
>        (address "hniksic@redhat.com"))
>
> is useful?

It's an improvement, but it doesn't solve the #1a problem.

I have yet to try your patch.  Can you explain what it is supposed to
do?  I'm not sure I understand the intention from reading the patch.

>> 2. I tried to fix #1 by explicitly matching the stuff from the Message
>>    buffer, like this:
>>
>>      ((and (message-fetch-field "to")
>>            (string-match "redhat\\.com" (message-fetch-field "to")))
>>       (address "hniksic@redhat.com"))
>>
>>    But that didn't work because `gnus-configure-posting-styles' is
>>    called from `message-mode-hook', which gets run when the Message
>>    buffer is still completely empty.  It should be called at a later
>>    stage, when the buffer has already been set up.
>
> There's a dependency problem here, not all functions that use
> information from the message buffer and modify the contents of the
> message buffer can be called last.  I think the ordering has changed
> several times, but it won't ever satisfy everyone.  I think the
> approach should be that you shouldn't count on information being
> available in the message buffers unless... err, it is available.

I'm not sure I understand this.  Why can't it satisfy everyone?  What
is the position opposite to mine?

Re: Two gnus-posting-styles problems

[Simon Josefsson]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Perhaps
>>
>>       ((header "from" "redhat.com")
>>        (address "hniksic@redhat.com"))
>>
>> is useful?
>
> It's an improvement, but it doesn't solve the #1a problem.

No, the #1a problem is probably a bug and the patch solves it.

> I have yet to try your patch.  Can you explain what it is supposed to
> do?  I'm not sure I understand the intention from reading the patch.

I see now that the patch accidently included an unrelated patch.  The
point of the patch was simply to bind gnus-article-copy to nil in all
places where you aren't following up or replying to an article --
e.g., when pressing `a' or `m'.  If the variable is nil, the posting
styles code won't use the last viewed buffer.

>>> 2. I tried to fix #1 by explicitly matching the stuff from the Message
>>>    buffer, like this:
>>>
>>>      ((and (message-fetch-field "to")
>>>            (string-match "redhat\\.com" (message-fetch-field "to")))
>>>       (address "hniksic@redhat.com"))
>>>
>>>    But that didn't work because `gnus-configure-posting-styles' is
>>>    called from `message-mode-hook', which gets run when the Message
>>>    buffer is still completely empty.  It should be called at a later
>>>    stage, when the buffer has already been set up.
>>
>> There's a dependency problem here, not all functions that use
>> information from the message buffer and modify the contents of the
>> message buffer can be called last.  I think the ordering has changed
>> several times, but it won't ever satisfy everyone.  I think the
>> approach should be that you shouldn't count on information being
>> available in the message buffers unless... err, it is available.
>
> I'm not sure I understand this.  Why can't it satisfy everyone?  What
> is the position opposite to mine?

There are alot of hooks and functions that people use to populate
message buffers: message-mode-hook, message-setup-hook,
gnus-message-setup-hook, gnus-posting-styles, making user-mail-address
context sensitive, defadvice etc.  If we change the ordering the way
you want, the posting style is applied last, which makes it possible
to extract To/From etc from the newly composed message.  But the same
change will affect code added to, say, message-setup-hook, since it no
longer can extract the fields added by the posting styles code.  Some
code need to be called last, and changing the order now means people
will have to use different hooks depending on which Gnus version they
use and how it implements this.

To be concrete: Consider someone using message-setup-hook to extract
from headers and insert something else AND then uses posting styles,
and relies on it being called in that order will be surprised.  (Now I
don't know if message-setup-hook really is called before applying
posting styles, but I'm sure there are such hooks.)

That said, perhaps changing it to apply posting styles last is good,
but it seems difficult to tell what harm to people's customizations it
will generate.  Leaving it as is doesn't hurt anything, it seems, it
only forces you to write your customization in another way.  And since
your proposed customization didn't use anything promised by
documentation (did it?), the conservative approach would be to leave
the call order as is.

Re: Two gnus-posting-styles problems

[Kai Großjohann]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> 1. It's unclear exactly what a HEADER match in fact matches.

Somewhere in the docs it says that it matches the _original_ message
(the one you are replying to).  Maybe it should say that louder.

> 1a. Even worse, it uses the "gnus article copy" buffer even when it is
>     completely unrelated to the message currently being composed.  For
>     example, I pressed `a' or `m' in the Summary buffer and was trying
>     to figure out why the hell it thought that the Red Hat address
>     should be used.  It turned out that my old "gnus article copy"
>     buffer happened addressed to a Red Hat person.

This seems to be bad.  Hm.  It should look for whether the current
message is a reply/followup, and refrain from header matches if not.

> 2. I tried to fix #1 by explicitly matching the stuff from the Message
>    buffer, like this:
>
>      ((and (message-fetch-field "to")
>            (string-match "redhat\\.com" (message-fetch-field "to")))
>       (address "hniksic@redhat.com"))
>
>    But that didn't work because `gnus-configure-posting-styles' is
>    called from `message-mode-hook', which gets run when the Message
>    buffer is still completely empty.  It should be called at a later
>    stage, when the buffer has already been set up.

Hm.  This is a known problem.  Hm.  Hmmmm...  I think it can't be
called when the message buffer is set up, for then the From header has
been inserted already (if message-generate-headers-first is set).  Or
maybe there are other problems with changing headers in that case?
Hm.

Holger Schauer's header-action.el takes action when the message is
sent.  gnus-pers does something similar I think.

But on the whole, I think a lot of people are trying to use posting
styles the way you are using them, so maybe these people's wishes
should be accomodated.

kai
-- 
Silence is foo!

Re: Two gnus-posting-styles problems

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> That said, perhaps changing it to apply posting styles last is good,
> but it seems difficult to tell what harm to people's customizations it
> will generate.

I'm guessing a lot of people will like it, and this being Oort, we can
still change it back if there is an outcry.

Postings styles are good for people who don't want to delve deep into
Lisp.  The others can solve their problem easily enough, I guess.
(Maybe the gurus have pity on the newbies ;-)

kai
-- 
Silence is foo!

Re: Two gnus-posting-styles problems

[Hrvoje Niksic]

Simon Josefsson <jas@extundo.com> writes:

>> I have yet to try your patch.  Can you explain what it is supposed
>> to do?  I'm not sure I understand the intention from reading the
>> patch.
>
> I see now that the patch accidently included an unrelated patch.
> The point of the patch was simply to bind gnus-article-copy to nil
> in all places where you aren't following up or replying to an
> article -- e.g., when pressing `a' or `m'.  If the variable is nil,
> the posting styles code won't use the last viewed buffer.

I see.  That should work, yes.

But I won't test it for some time simply because I really need the
functionality to test the message buffer.  If that can't be done with
the posting styles, then I'll just use a hook.  Perhaps I'm simply not
the right target audience for posting styles.

>>> There's a dependency problem here, not all functions that use
>>> information from the message buffer and modify the contents of the
>>> message buffer can be called last.  I think the ordering has changed
>>> several times, but it won't ever satisfy everyone.  I think the
>>> approach should be that you shouldn't count on information being
>>> available in the message buffers unless... err, it is available.
>>
>> I'm not sure I understand this.  Why can't it satisfy everyone?  What
>> is the position opposite to mine?
>
> There are alot of hooks and functions that people use to populate
> message buffers: message-mode-hook, message-setup-hook,
> gnus-message-setup-hook, gnus-posting-styles, making user-mail-address
> context sensitive, defadvice etc.  If we change the ordering the way
> you want, the posting style is applied last, which makes it possible
> to extract To/From etc from the newly composed message.  But the same
> change will affect code added to, say, message-setup-hook, since it no
> longer can extract the fields added by the posting styles code.

I suppose the posting styles could be applied before the
message-setup-hook is run.

But Kai has a good point: doing what I want might seriously clash with
`message-generate-headers-first'.  I do not see a way to resolve that,
so I'll just keep my hook.  At least the `m'/`a' thing, which was a
genuine bug, should now be fixed, so something good came out of my
report.

Thanks for the fix.

> That said, perhaps changing it to apply posting styles last is good,
> but it seems difficult to tell what harm to people's customizations
> it will generate.  Leaving it as is doesn't hurt anything,

Well.  There *could* be a variable that controls when
`gnus-posting-styles' are applied.  It could default to applying it in
the empty message buffer, which would make sure that existing
customizations keep working.

Re: Two gnus-posting-styles problems

[Simon Josefsson]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> But I won't test it for some time simply because I really need the
> functionality to test the message buffer.  If that can't be done with
> the posting styles, then I'll just use a hook.  Perhaps I'm simply not
> the right target audience for posting styles.

Perhaps this is reason enough to change it, like Kai said.  Patches,
anyone? :-)

>>>> There's a dependency problem here, not all functions that use
>>>> information from the message buffer and modify the contents of the
>>>> message buffer can be called last.  I think the ordering has changed
>>>> several times, but it won't ever satisfy everyone.  I think the
>>>> approach should be that you shouldn't count on information being
>>>> available in the message buffers unless... err, it is available.
>>>
>>> I'm not sure I understand this.  Why can't it satisfy everyone?  What
>>> is the position opposite to mine?
>>
>> There are alot of hooks and functions that people use to populate
>> message buffers: message-mode-hook, message-setup-hook,
>> gnus-message-setup-hook, gnus-posting-styles, making user-mail-address
>> context sensitive, defadvice etc.  If we change the ordering the way
>> you want, the posting style is applied last, which makes it possible
>> to extract To/From etc from the newly composed message.  But the same
>> change will affect code added to, say, message-setup-hook, since it no
>> longer can extract the fields added by the posting styles code.
>
> I suppose the posting styles could be applied before the
> message-setup-hook is run.

That won't work if people has code in message-setup-hook that assumes
posting styles hasn't been applied yet, will it?  That was the kind of
trouble I feared would happen if we change the ordering.

> But Kai has a good point: doing what I want might seriously clash with
> `message-generate-headers-first'.

Ouch, yes.

> I do not see a way to resolve that, so I'll just keep my hook.  At
> least the `m'/`a' thing, which was a genuine bug, should now be
> fixed, so something good came out of my report.
>
> Thanks for the fix.

I'll commit it, thanks.

>> That said, perhaps changing it to apply posting styles last is good,
>> but it seems difficult to tell what harm to people's customizations
>> it will generate.  Leaving it as is doesn't hurt anything,
>
> Well.  There *could* be a variable that controls when
> `gnus-posting-styles' are applied.  It could default to applying it in
> the empty message buffer, which would make sure that existing
> customizations keep working.

Yup.