Re: shr using `make-xwidget' incorrectly

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> BTW, it's impossible to cause an xwidget to become unavailable by
> deleting text in a buffer: it'll always be available via
> get-buffer-xwidgets, and there could be references to the xwidget in
> other places.

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.

> Making xwidgets "evaporable" would cause a lot of overhead, I think.
>
> For example, WebKitGTK may elect to save or delete cached resources, if
> the reference count of the context and settings reaches zero.
>
> (Which will always happen if the widget did not have another widget
> passed to it as the `related' parameter to make-xwidget, and may happen
> regardless.)

I'm not sure what you mean here.  Are you saying that a widget in a
buffer might just spontaneously disappear?

> Another solution (that doesn't involve attaching xwidgets to the buffer
> currently being rendered in) would be have shr attach xwidgets to a
> buffer used only for shr to manage xwidgets, and for shr to "recycle"
> the xwidgets each time something is rendered.

I don't think the functions that use xwidgets should have to know about
any of this stuff.  Imagine if you'd have to jump through these hoops to
display images?

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