Display glitches in sgnus 0.83 (II)

Display glitches in sgnus 0.83 (II)

[Steven L Baur]

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

Enabling gnus-article-hide-signature in the gnus-article-display-hook
is still too aggressive.  It should not cross MIME multipart
boundaries.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

[-- Attachment #2: lcylarrw.gif --]
[-- Type: image/gif, Size: 299 bytes --]

Re: Display glitches in sgnus 0.83 (II)

[Lars Magne Ingebrigtsen]

Steven L Baur <steve@miranova.com> writes:

> Enabling gnus-article-hide-signature in the gnus-article-display-hook
> is still too aggressive.  It should not cross MIME multipart
> boundaries.

To deal with that properly, Gnus would have to do some MIME parsing,
which is something I'd rather not get into.  An easy hack would be to
set `gnus-signature-limit' to "^--Multipart" or something -- that way
signatures that contain that regexp wouldn't be hidden.  Is that nice,
though?

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Display glitches in sgnus 0.83 (II)

[Per Abrahamsen]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> To deal with that properly, Gnus would have to do some MIME parsing,
LMI> which is something I'd rather not get into.  An easy hack would be to
LMI> set `gnus-signature-limit' to "^--Multipart" or something -- that way
LMI> signatures that contain that regexp wouldn't be hidden.  Is that nice,
LMI> though?

Very nice, especially if the regexp also recognized forwarded messages
and context diffs.

Re: Display glitches in sgnus 0.83 (II)

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> In <x6zq74ejfa.fsf@eyesore.no>
>>>>>	Lars Magne Ingebrigtsen <larsi@ifi.uio.no> wrote:

Lars> Steven L Baur <steve@miranova.com> writes:

Steven>> Enabling gnus-article-hide-signature in the
Steven>> gnus-article-display-hook is still too aggressive.  It should
Steven>> not cross MIME multipart boundaries.

Lars> To deal with that properly, Gnus would have to do some MIME
Lars> parsing, which is something I'd rather not get into.  An easy
Lars> hack would be to set `gnus-signature-limit' to "^--Multipart" or
Lars> something -- that way signatures that contain that regexp
Lars> wouldn't be hidden.  Is that nice, though?

  Following code is available for tm-view MIME processing. It may be
safe even if tm-view is not used:

  ;; It must be used in "*Article*" buffer.
  (if (and (boundp 'mime::preview/content-list)
	   mime::preview/content-list)
      (let ((pcinfo (car (last mime::preview/content-list))))
	(cons (mime::preview-content-info/point-min pcinfo)
	      ;; point-min of last content
	      (mime::preview-content-info/point-max pcinfo)
	      ;; point-max of last content
	      ))
    ;; not MIME message
    )

----------------------------------------------------------------------
MORIOKA Tomohiko <morioka@jaist.ac.jp>
        Japan advanced Institute of Science and Technology, Hokuriku
                Asahi-dai, Tatsu-no-kuchi chô, Nomi, Ishikawa, Japan
----------------------------------------- Frisch, Frei, Freöhlich! ---

Re: Display glitches in sgnus 0.83 (II)

[守岡 知彦 / MORIOKA Tomohiko]

[-- Attachment #1.1: Type: text/plain, Size: 1738 bytes --]

>>>>> In <s1cu3xc8tvc.fsf@jaist.ac.jp> 
>>>>>	morioka@jaist.ac.jp (MORIOKA Tomohiko) wrote:

tomo> >>>>> In <x6zq74ejfa.fsf@eyesore.no> 
tomo> >>>>>	Lars Magne Ingebrigtsen <larsi@ifi.uio.no> wrote:

Lars> Steven L Baur <steve@miranova.com> writes:

Steven>> Enabling gnus-article-hide-signature in the
Steven>> gnus-article-display-hook is still too aggressive.  It should
Steven>> not cross MIME multipart boundaries.

Lars> To deal with that properly, Gnus would have to do some MIME
Lars> parsing, which is something I'd rather not get into.  An easy
Lars> hack would be to set `gnus-signature-limit' to "^--Multipart" or
Lars> something -- that way signatures that contain that regexp
Lars> wouldn't be hidden.  Is that nice, though?

tomo>   Following code is available for tm-view MIME processing. It may be
tomo> safe even if tm-view is not used:

(snip)

  Following code is available to MIME safe signature handling using
tm-view:

(defun gnus-narrow-to-signature ()
  "Narrow to the signature."
  (widen)
  (if (and (boundp 'mime::preview/content-list)
	   mime::preview/content-list)
      (let ((pcinfo (car (last mime::preview/content-list))))
	(narrow-to-region (mime::preview-content-info/point-min pcinfo)
			  (point-max))
	))
  (goto-char (point-max))
  (when (re-search-backward gnus-signature-separator nil t)
    (forward-line 1)
    (when (or (null gnus-signature-limit)
	      (and (numberp gnus-signature-limit)
		   (< (- (point-max) (point)) gnus-signature-limit))
	      (and (gnus-functionp gnus-signature-limit)
		   (funcall gnus-signature-limit))
	      (and (stringp gnus-signature-limit)
		   (not (re-search-forward gnus-signature-limit nil t))))
      (narrow-to-region (point) (point-max))
      t)))

[-- Attachment #1.2: Type: text/plain, Size: 324 bytes --]

----------------------------------------------------------------------
MORIOKA Tomohiko <morioka@jaist.ac.jp>
        Japan advanced Institute of Science and Technology, Hokuriku
                Asahi-dai, Tatsu-no-kuchi chô, Nomi, Ishikawa, Japan
----------------------------------------- Frisch, Frei, Freöhlich! ---

[-- Attachment #2: Type: application/pgp-signature, Size: 345 bytes --]

Re: Display glitches in sgnus 0.83 (II)

[Lars Magne Ingebrigtsen]

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

> LMI> To deal with that properly, Gnus would have to do some MIME parsing,
> LMI> which is something I'd rather not get into.  An easy hack would be to
> LMI> set `gnus-signature-limit' to "^--Multipart" or something -- that way
> LMI> signatures that contain that regexp wouldn't be hidden.  Is that nice,
> LMI> though?
> 
> Very nice, especially if the regexp also recognized forwarded messages
> and context diffs.

So perhaps that variable should default to a useful value?  Could
somebody come up with a regexp that catches most common "things that
often come after signatures" stuff?

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Display glitches in sgnus 0.83 (II)

[Kai Grossjohann]

>>>>> On 19 May 1996 20:21:52 +0200, Lars Magne Ingebrigtsen
>>>>> <larsi@ifi.uio.no> said:

  Lars> So perhaps that variable should default to a useful value?
  Lars> Could somebody come up with a regexp that catches most common
  Lars> "things that often come after signatures" stuff?

FWIW, believe it or not, I have set gnus-signature-limit to "^$" and I
have yet to find a message where this fails.  I have never seen
anybody who has emtpy lines in their signatures.

kai
-- 
Life is hard and then you die.

[++] Re: Display glitches in sgnus 0.83 (II)

[Colin Rafferty]

Kai Grossjohann writes:
>>>>>> On 19 May 1996 20:21:52 +0200, Lars Magne Ingebrigtsen
>>>>>> <larsi@ifi.uio.no> said:

Lars> So perhaps that variable should default to a useful value?
Lars> Could somebody come up with a regexp that catches most common
Lars> "things that often come after signatures" stuff?

> FWIW, believe it or not, I have set gnus-signature-limit to "^$" and I
> have yet to find a message where this fails.  I have never seen
> anybody who has emtpy lines in their signatures.

That is very good advice, but nnml seems to add extra empty lines onto
the end of my messages (September Gnus v0.52).

I use "\n\n[ \t]*[^ \t]".

-- 
This posting adheres to the SELF-DISCIPLINE guidelines for better
USENET discussions. See http://www.eiffel.com/discipline.

Re: [++] Re: Display glitches in sgnus 0.83 (II)

[Lars Magne Ingebrigtsen]

craffert@ml.com (Colin Rafferty) writes:

> That is very good advice, but nnml seems to add extra empty lines onto
> the end of my messages (September Gnus v0.52).

0.90 doesn't seem to do that, at least.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."