Gnus development mailing list
 help / color / mirror / Atom feed
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)
Cc: tbennett@nvidia.com
Subject: [gnu.emacs.gnus] Re: Group parameters and gnus-boring-article-headers
Date: 18 Oct 2000 17:12:24 +0200	[thread overview]
Message-ID: <vaflmvmji93.fsf@lucy.cs.uni-dortmund.de> (raw)

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

What do you guys (and gals?) think about the following patch by Tony?
I think it is the right thing to do.

kai
-- 
I like BOTH kinds of music.



[-- Attachment #2: Type: message/rfc822, Size: 3287 bytes --]

From: tbennett@nvidia.com (Tony E. Bennett)
Subject: Re: Group parameters and gnus-boring-article-headers
Date: 18 Oct 2000 09:57:34 -0400
Message-ID: <m3snpuz1yp.fsf@uh-oh.nvidia.com>


Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> On 16 Oct 2000, Tony E. Bennett wrote:
> 
> > Here is a patch that seems to fix this for me.
> 
> One thing to try is this: suppose you have group A which sets local
> variable foo to 1, and you have group B which sets local variable bar
> to 1.  And then you enter group A, display a message, enter group B,
> also display a message.  Does the article buffer then have both local
> variables?

Whoops, it was accumulating local variables.

This replacement patch works for me and fixes the problem you mention
where later article buffers see superset of all previously set locals.

If there are any locals that should persist in *article* buffer, then
this patch would break them.


{~/.../gnus/gnus/lisp}. diff -u ORIG/gnus-5.8.7/lisp/gnus-art.el .
--- ORIG/gnus-5.8.7/lisp/gnus-art.el	Sat Jul  1 07:10:43 2000
+++ ./gnus-art.el	Wed Oct 18 09:19:34 2000
@@ -2663,6 +2663,10 @@
     (if (get-buffer name)
 	(save-excursion
 	  (set-buffer name)
+          ;; destroy all locals in the *Article* buffer
+          ;; so that group parameters copied from the *Summary* buffer
+          ;; don't accumulate from group to group
+          (kill-all-local-variables)
 	  (when gnus-article-mime-handles
 	    (mm-destroy-parts gnus-article-mime-handles))
 	  (buffer-disable-undo)
@@ -2710,6 +2714,10 @@
       (save-excursion
 	(gnus-article-setup-buffer)
 	(set-buffer gnus-article-buffer)
+        ;; Copy all locals from *Summary* buffer to our *Article* buffer.
+        ;; Primary benefit is to allow article-buffer specific variables
+        ;; to be set in the group parameters, eg: gnus-treat-hide-boring-headers.
+        (message-clone-locals gnus-summary-buffer)
 	;; Deactivate active regions.
 	(when (and (boundp 'transient-mark-mode)
 		   transient-mark-mode)
-- 
--tony              tbennett@nvidia.com

             reply	other threads:[~2000-10-18 15:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-18 15:12 Kai Großjohann [this message]
2000-11-02 14:54 ` ShengHuo ZHU

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=vaflmvmji93.fsf@lucy.cs.uni-dortmund.de \
    --to=kai.grossjohann@cs.uni-dortmund.de \
    --cc=tbennett@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).