selectively disabling HTML rendering?

selectively disabling HTML rendering?

[Mike Small]

Is there an easy way to selectively disable HTML rendering, dependent
upon header info? I've come up with the following, which does what I
want, but I don't like its chances across emacs upgrades:

(defun mms-gnus-mime-display-alternative (handle)
  "My own function for displaying mime multipart/alternative articles in Gnus
Use by placing in gnus-mime-multipart-functions.

Beware when upgrading. Some of this is copied out of and makes assumptions about
gnus-mime-display-part from version 5.13 of Gnus.  It also bypasses 
gnus-mime-display-multipart-as-mixed and gnus-mime-display-multipart-alternative-as-mixed."
  (let ((id (1+ (length gnus-article-mime-handle-alist)))
	(mm-discouraged-alternatives
	 (if (string= (get-text-property 0 'from (car handle))
		      "wsmith@wordsmith.org")
	     (list "text/html")
	   mm-discouraged-alternatives)))
    (push (cons id handle) gnus-article-mime-handle-alist)
    (gnus-mime-display-alternative (cdr handle) nil nil id)))

-- 
Mike Small
smallm@panix.com

Re: selectively disabling HTML rendering?

[Emanuel Berg]

Mike Small <smallm@panix.com> writes:

> Is there an easy way to selectively disable HTML
> rendering, dependent upon header info? I've come up
> with the following, which does what I want, but
> I don't like its chances across emacs upgrades:

You don't have to worry about that. Upgrades are to
fix things and add new things, they are not supposed
to break existing code which adhere to general good
practices - normal, everyday code that is good tend
to stay that way across upgrades.

It is rather like this: if the upgrade breaks your
code, either it is a bug from their side which you
should report, or you did something really unorthodox
and you should identify what and analyze why you made
it that way, and how you can make it better.

> (defun mms-gnus-mime-display-alternative (handle)
>   "My own function for displaying mime multipart/alternative articles in Gnus
> Use by placing in gnus-mime-multipart-functions.
>
> Beware when upgrading. Some of this is copied out of and makes assumptions about
> gnus-mime-display-part from version 5.13 of Gnus.  It also bypasses 
> gnus-mime-display-multipart-as-mixed and gnus-mime-display-multipart-alternative-as-mixed."
>   (let ((id (1+ (length gnus-article-mime-handle-alist)))
> 	(mm-discouraged-alternatives
> 	 (if (string= (get-text-property 0 'from (car handle))
> 		      "wsmith@wordsmith.org")
> 	     (list "text/html")
> 	   mm-discouraged-alternatives)))
>     (push (cons id handle) gnus-article-mime-handle-alist)
>     (gnus-mime-display-alternative (cdr handle) nil
> nil id)))

OK, you don't need to say it is your own function,
those are very common in the Emacs world. Also, you
should mention all arguments - in uppercase, in the
order they appear - in the docstring: i.e, you should
say HANDLE is used to... Also, "Lisp symbols" (all
function and variable names) should appear `quoted'.
If you do this (both issues), and then use help to
bring up the on-line help for this function, you'll
understand why.

You can use this function to verify. Invoke (and
ignore all things that relate to packages) and do as
it says, then invoke again to confirm:

    (defun check-pack-style ()
      (interactive)
      (checkdoc-current-buffer t) ; TAKE-NOTES
      (message "Style check done.") )

The docstring should mention what the function does
rather than get into details what it might break etc.
In particular the hard-coded "wsmith@wordsmith.org"
should be mentioned.

The idea as such is close to over-engineering - how
about to just open the message as "not HTML", then
have a key assigned to HTML-ize it?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: selectively disabling HTML rendering?

[Mike Small]

Emanuel Berg <embe8573@student.uu.se> writes:

> Mike Small <smallm@panix.com> writes:
>
>> Is there an easy way to selectively disable HTML
>> rendering, dependent upon header info? I've come up
>> with the following, which does what I want, but
>> I don't like its chances across emacs upgrades:
>
> You don't have to worry about that. Upgrades are to
> fix things and add new things, they are not supposed
> to break existing code which adhere to general good
> practices - normal, everyday code that is good tend
> to stay that way across upgrades.
>
> It is rather like this: if the upgrade breaks your
> code, either it is a bug from their side which you
> should report, or you did something really unorthodox
> and you should identify what and analyze why you made
> it that way, and how you can make it better.
>

I'm thinking I'm in this category of being unorthodox in that I'm
depending on the implementation of internal undocumented Gnus functions.
Here's the relevant part of gnus-mime-display-part for reference:

(defun gnus-mime-display-part (handle)
  (cond
   ;; Maybe a broken MIME message.
   ((null handle))
   ;; Single part.
   ((not (stringp (car handle)))
    (gnus-mime-display-single handle))
   ;; User-defined multipart
   ((cdr (assoc (car handle) gnus-mime-multipart-functions))
    (funcall (cdr (assoc (car handle) gnus-mime-multipart-functions))
	     handle))
   ;; multipart/alternative
   ((and (equal (car handle) "multipart/alternative")
	 (not (or gnus-mime-display-multipart-as-mixed
		  gnus-mime-display-multipart-alternative-as-mixed)))
    (let ((id (1+ (length gnus-article-mime-handle-alist))))
      (push (cons id handle) gnus-article-mime-handle-alist)
      (gnus-mime-display-alternative (cdr handle) nil nil id)))
...

My function gets called in the User-defined multipart cond action and
bind mm-discouraged-alternatives if it's Anu's mail.  Then it tries to
act as if I'd jumped back out into the cond again to land in the
multipart/alternative action. And in doing that it ignores the two
as-mixed variables (which I don't care about now but it could puzzle me
if I set them someday and forget about this customization).  It's bound
to break if gnus-mime-display-part and gnus-mime-display-alternative
change.  But if there's no better way to do this without having me press
extra keys to read my mail, it's not a huge deal. If something breaks
and I forget what I've done here it will give me another chance to
practice with edebug. (I'm in awe of this debugger -- can't believe it's
part of a text editor. Do any free software common lisp implementations
have anything as good? If Slime has as much it's well hidden.)

>> (defun mms-gnus-mime-display-alternative (handle)
>>   "My own function for displaying mime multipart/alternative articles in Gnus
>> Use by placing in gnus-mime-multipart-functions.
>>
>> Beware when upgrading. Some of this is copied out of and makes assumptions about
>> gnus-mime-display-part from version 5.13 of Gnus.  It also bypasses 
>> gnus-mime-display-multipart-as-mixed and gnus-mime-display-multipart-alternative-as-mixed."
>>   (let ((id (1+ (length gnus-article-mime-handle-alist)))
>> 	(mm-discouraged-alternatives
>> 	 (if (string= (get-text-property 0 'from (car handle))
>> 		      "wsmith@wordsmith.org")
>> 	     (list "text/html")
>> 	   mm-discouraged-alternatives)))
>>     (push (cons id handle) gnus-article-mime-handle-alist)
>>     (gnus-mime-display-alternative (cdr handle) nil
>> nil id)))

...

Thanks for the tips on documentation and coding style. I've applied some
of that. What I've not followed (e.g. documenting the argument and not
hard coding the from value) I ignored only because I don't see myself
publishing this function to others. Er, other than on this news group,
that is.

...

> The idea as such is close to over-engineering - how
> about to just open the message as "not HTML", then
> have a key assigned to HTML-ize it?

My usual case is to want the html rendering. It's only Anu's Word a Day
where I want the text alternative. I was manually switching it over to
text for a while, but wanted to have it happen automatically. I read his
emails every weekday so a manual step would be annoying.

-- 
Mike Small
smallm@panix.com

Re: selectively disabling HTML rendering?

[Adam Sjøgren]

Mike writes:

> My usual case is to want the html rendering. It's only Anu's Word a Day
> where I want the text alternative.

One way to handle this is to split those emails into a group by
themselves, and use group parameters to add special configuration for
just that group.

Just an idea :-)


  Best regards,

    Adam

-- 
 "I wonder if you can refuse to inherit the world."           Adam Sjøgren
 "I think if you're born, it's too late."                asjo@koldfront.dk


_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gnus-english

Re: selectively disabling HTML rendering?

[Emanuel Berg]

Mike Small <smallm@panix.com> writes:

> I'm thinking I'm in this category of being
> unorthodox in that I'm depending on the
> implementation of internal undocumented
> Gnus functions.

Actually I don't know who is unorthodox here :)

My take is:

1) all functions should be documented, and

2) there is nothing wrong relying on (any) existent
   code that is good and does what you want

If you are worried they will change, which I don't
think they will - or, if they will, the interface (the
input mapping to output) should remain the same, in
which case you *want* the changes anyway as they are
probably efficiency motivated or bugfixes - but if you
are nonetheless worried they will change, just dump
the code in a file - if upgrade breaks your stuff,
compare and see what changed. But I only advice you
this because I think it won't happen. So it is only to
relax you :)

For one (for many I should say) I use *tons* of all
kind of functions from any and all modules, and with
50+ files of Elisp I had to change one or two things
which were total details when I upgraded most
recently. So, don't worry about it!

> Thanks for the tips on documentation and coding
> style. I've applied some of that. What I've not
> followed (e.g. documenting the argument and not hard
> coding the from value) I ignored only because
> I don't see myself publishing this function to
> others. Er, other than on this news group, that is.

Remember, regardless of who the audience is, if you
behave like a pro, that's what you become - more, do
it every day it doesn't even take that long even.
Never show any weaknesses to your opponent, the
grandmaster says. Nor to yourself, his top
student says.

> My usual case is to want the html rendering.
> It's only Anu's Word a Day where I want the text
> alternative. I was manually switching it over to
> text for a while, but wanted to have it happen
> automatically. I read his emails every weekday so
> a manual step would be annoying.

OK, how about: when you see that post in the summary
buffer, you open it with another key? That way you
don't even hit an extra key, just *another* key. E.g.,
instead of RET, assign M-RET to do this. That has the
advantage of being flexible as well - perhaps some new
situation arrives, where you want the distinction
again? In principle and practice I'm a big fan of
DWIM-hacking but this seems to me too unbalanced -
i.e., one sender vs. everything else - to be sensible.
But I'm not telling you what to do, of course.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: selectively disabling HTML rendering?

[Mike Small]

asjo@koldfront.dk (Adam Sjøgren) writes:
> One way to handle this is to split those emails into a group by
> themselves, and use group parameters to add special configuration for
> just that group.
>
> Just an idea :-)

Just what I was looking for. I was even half way there, already having
had a group for it. But I didn't know about group parameters.

Thank you.

-- 
Mike Small
smallm@panix.com
_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gnus-english

Re: selectively disabling HTML rendering?

[Adam Sjøgren]

Mike writes:

> asjo@koldfront.dk (Adam Sjøgren) writes:

>> One way to handle this is to split those emails into a group by
>> themselves, and use group parameters to add special configuration for
>> just that group.

> Just what I was looking for. I was even half way there, already having
> had a group for it. But I didn't know about group parameters.

My topic parameters for gwene look like this:

  ((mm-inline-text-html-with-images t)
   (mm-discouraged-alternatives nil)
   (gnus-blocked-images "pheedo\\|feedburner.com\\|doubleclick.net\\|feeds.wordpress.com")
   (subscribe . "gwene")
   (mm-w3m-safe-url-regexp nil)
   (bbdb-silent-running t)
   (mm-automatic-display
    (union
     '("text/html")
     mm-automatic-display)))

which is probably the "opposite" of what you want, but it may give some
inspiration.


  Best regards,

    Adam

-- 
 "They didn't care that they'd seen it work in                Adam Sjøgren
  practise, because they already knew it couldn't work   asjo@koldfront.dk
  in theory."


_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gnus-english