bug#28402: 25.2; shr.el uses shr-tag-img despite set shr-external-rendering-functions

[Vasilij Schneidermann <v.schneidermann@gmail.com>]

> In a thing like shr, it's really the case of a death by a thousand cuts:
> Each single improvement adds a slight performance hit, and then after a
> couple of years you end up with something that's pretty, but completely
> unusable.  (It's already too slow as it is.)  So I protect `shr-descend'
> fiercely.  :-)

How deeply nested does typical HTML get anyways?  I recall an exemplary
comment from an article on browser rendering that pointed out that they
bail out on degenerate cases, so perhaps it's better to add that to shr
rather than hoping you never hit the stack limit by following a
conservative coding style.

Regarding speed, I only notice it being an issue for documents with
tables, everything else is fine.

> (But late, as always...  Sorry for not saying this before you applied
> the patch; it would have been less work for all of us.)

I can imagine other variations of defsubst (such as defmacro and
define-inline), but it would indeed be the easiest to roll back that
part of the code.  What I'd additionally do is adding a comment
explaining why there's two very similar snippets of code doing the same
thing, otherwise the next person proposing a patch will change only one
of them and be left head-scratching why it doesn't quite work.