From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/9539 Path: main.gmane.org!not-for-mail From: Jan Vroonhof Newsgroups: gmane.emacs.gnus.general Subject: Re: [Article display mess up] SOLVED! (-> FAQ ???) Date: 22 Jan 1997 14:51:31 +0100 Sender: vroonhof@math.ethz.ch Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.94) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035149550 19095 80.91.224.250 (20 Oct 2002 21:32:30 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:32:30 +0000 (UTC) Cc: dsiu@Adobe.COM.Wesley.Hardaker@sphys.unil.ch.larsi Return-Path: Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.8.4/8.8.4) with SMTP id GAA11091 for ; Wed, 22 Jan 1997 06:26:38 -0800 Original-Received: from frege.math.ethz.ch (root@frege-d-math-north-g-west.math.ethz.ch [129.132.145.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id ; Wed, 22 Jan 1997 14:52:39 +0100 Original-Received: from fresnel.math.ethz.ch (vroonhof@fresnel [129.132.145.6]) by frege.math.ethz.ch (8.6.12/Main-STAT-mailer) with ESMTP id OAA21022; Wed, 22 Jan 1997 14:51:19 +0100 Original-Received: (vroonhof@localhost) by fresnel.math.ethz.ch (8.6.9/D-MATH-client) id OAA10667; Wed, 22 Jan 1997 14:51:32 +0100 Original-To: ding@ifi.uio.no In-Reply-To: Wesley.Hardaker@sphys.unil.ch's message of 20 Jan 1997 09:46:51 +0100 Original-Lines: 70 X-Mailer: Red Gnus v0.82/XEmacs 19.14 Xref: main.gmane.org gmane.emacs.gnus.general:9539 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:9539 writes: [From a discussion about a problem where the group name gets insert by the picons all over the headers on the very firt message you read] > Lars> Guessing wildly, I think this sounds like a glyph glitch. Is the text > Lars> really there, or does it just look like it's there? > > I'm guessing something similiar... A lot of people (ok, 5 or 6) have > reported similar problems too me but I've never been able to reproduce > it or see it happen so I'm a bit confused really... I guessed it was > probably a bug with XEmacs not picons or gnus, but I can't be sure... I solved it.. It is a RTFM type operator error. It is produced by something like the following in .gnus (setq gnus-picons-display-where 'article) (add-hook 'gnus-article-display-hook 'gnus-article-display-picons t) (add-hook 'gnus-summary-prepare-hook 'gnus-group-display-picons t) You get this if you copy the example out of the Info file and then change the first line to say 'article without reading the documentations for the other functions. I did exactly that and I think there are some others with the above lines in their .gnus's It SHOULD read of course (setq gnus-picons-display-where 'article) (add-hook 'gnus-article-display-hook 'gnus-article-display-picons t) (add-hook 'gnus-article-prepare-hook 'gnus-group-display-picons t) which works fine. The junk is generated when upon entering a group gnus-summary-prepare-hook gets run. With the above setiings it trys to insert an annotation in the article buffer. If this is the first message you read, there is none. Therefore the following code in gnus-group-display-picons (save-excursion (set-buffer (get-buffer-create (gnus-get-buffer-name gnus-picons-display-where))) (gnus-add-current-to-buffer-list) creates the article buffer and inserts an annoation with the group name. This annotation has a "begin-glyph" property set to the group icon/name. This wouldn't be a problem, BUT the gnus article-fancification code does not expect this and creates annotations/extents itself each one inheriting the begin-glyph property. This gives a group "icon" for every extent which creates the mess. So I suggest that 1. the example in the Info files is extended by comments explaining that this choice of hooks corresponds to only this choice for g-p-d-where 2. The picon hook functions refrain from creating one of the Gnus special buffers (i.e. *Article*) itself but instead give an error. and/or 3. The picon functions are made more intelligent with a special gnus-picon-summary-hook-function and similar g-p-article-hook-function which will do the right thing automagically based on the value of g-p-d-where. Jan P.S. This extent stuff is an horror to debug.