[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shr using `make-xwidget' incorrectly

From: Lars Ingebrigtsen
Subject: Re: shr using `make-xwidget' incorrectly
Date: Thu, 11 Nov 2021 05:56:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]