Re: shr using `make-xwidget' incorrectly

[Lars Ingebrigtsen <larsi@gnus.org>]

Po Lu <luangruo@yahoo.com> writes:

>> The same is true for overlays -- you can use `overlays-in' to find all
>> the overlays in the buffer, even if they aren't otherwise available.  I
>> think modelling xwidget behaviour on overlays makes a lot of sense from
>> an UI point of view.
>
> Hmm, I will try to think of a reasonable way to implement this.  But
> IMO, it should be optional -- the existing behavior makes sense for many
> use-cases.

Yes, indeed.

(And I was wondering why the xwidgets were still playing video when I
hit "back" in the eww history, and landed on a page with a video
again -- but they'd been updating the whole time, even if they'd not
been on screen, I understand now.)

> No, that killing a widget might take an unreasonable amount of time and
> be surprising to be implemented like evaporating overlays are.
>
> Imagine if the erasure of a few characters took upwards of 1 second,
> deleting dozens of on-disk cache files.  That is a situation that might
> result from implementing evaporation of xwidgets like with overlays.

Oh, sure.  I don't expect anybody to be doing exactly that with videos,
for instance, but I think it's a reasonable expectation that a mode that
inserts a video into the buffer shouldn't have to do ... a lot of work
to remove the video, either.  I mean, if that's feasible, it would be
nice.

> Better comparison: imagine if `struct image' was a Lisp object (and not
> an internal structure created on the basis of an image spec), held tens
> of megabytes of memory, a lot of non-replicable state, an entire
> language interpreter, and control over many cache files on-disk.

That describes animated images quite well.  :-)  (OK, the animation
itself is controlled from Lisp land, but there's a bunch of caches and
megabytes of data...)

Hm...  looking at the code in `image-animate-timeout', it may suffer
from some of the same issues...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no