From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/35553 Path: main.gmane.org!not-for-mail From: Christoph Conrad Newsgroups: gmane.emacs.gnus.general Subject: Suggestion: tell `gnus-part-display-hook'-functions whether header/body Date: 01 Apr 2001 21:58:47 +0200 Organization: Church of Emacs Message-ID: Reply-To: Christoph Conrad NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035171278 3704 80.91.224.250 (21 Oct 2002 03:34:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 03:34:38 +0000 (UTC) Return-Path: Original-Received: (qmail 18677 invoked by alias); 1 Apr 2001 20:01:31 -0000 Original-Received: (qmail 18672 invoked from network); 1 Apr 2001 20:01:29 -0000 Original-Received: from a63e1.pppool.de (HELO mutzel.brumpf.de) (213.6.99.225) by gnus.org with SMTP; 1 Apr 2001 20:01:29 -0000 Original-Received: (from cc@localhost) by mutzel.brumpf.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA19943; Sun, 1 Apr 2001 21:58:48 +0200 Original-To: ding@gnus.org X-Public-Key: http://pgp5.ai.mit.edu:11371/pks/lookup?op=get&search=0x1B488DEA User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 Original-Lines: 89 Xref: main.gmane.org gmane.emacs.gnus.general:35553 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:35553 Hi, ******* Motivation I wanted to add a function which washes message/news which of content-type "text/html". I saw that a function `gnus-article-wash-html' (on "W h" in summary) does this and the manual states that it Treat HTML (`gnus-article-wash-html'). Note that the this is USUALLY DONE AUTOMATICALLY by Gnus if the message in question has a `Content-Type' header that says that this type has been done. (emphasizing by me) But: 1) It uses w3. This is too slow for me (P133), i wanted to use lynx as with multipart messages (displaying the html part) 2) It doesn't work for me (any hint?) ******* Solution So i searched around and found that `gnus-part-display-hook' seems to be ideal for that task, cause the manual mentions: You can, of course, write your own functions to be called from `gnus-part-display-hook'. The functions are called narrowed to the part, and you can do anything you like, pretty much. ******* Problem But one problem remains: The functions in `gnus-part-display-hook' are called TWICE. call chain: gnus-article-prepare-display -> gnus-display-mime-function (gnus-display-mime) ->gnus-treat-article (1x body, 1x header) But there's no guaranted mechanism to distinguish whether we are called with the article narrowd to the body or to the headers. There are some possibilities: Body part when: ;; (let* ( (buffer-read-only nil) ;; (ct (message-fetch-field "content-type")) ;; (ctg (gnus-fetch-field "content-type")) ) ;; ;; ct is nil when in body part ;; (when (and (null ct) ;; ctg ;; (string-match "^text/html" ctg)) or ;; (let* ( (buffer-read-only nil) ;; (content-type (gnus-fetch-field "content-type")) ) ;; ;; condition == 'head when in head / nil in body ;; (when (and (null condition) ;; content-type ;; (string-match "^text/html" content-type)) The second "solution" relies on variables which are defined from the function calling the functions in `gnus-part-display-hook'. ******* Question So i ask for defining a guranteed way of knowing whether in header or body when called in `gnus-part-display-hook'. A good way could to not run the hook with `run-hooks' but with `run-hook-with-args' and to deliver one arg (a list) saying whether we are in header or body part. I see, this would break compatibility. Another solution could be to define a variable which is guaranteed to be defined when in functions in `gnus-part-display-hook'. The best way would be to extend the built-in mechanism for "gnus-treat-*"-variables for userdefined functions. (see node "Customizing Articles" in gnus manual). Best regards, cu, -cc- -- => GNU Emacs Webring @ <= Look Ma, this man can twist his fingers as if they were made of rubber, isn't that amazing? -- Not really, he's been using emacs for years...!