From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: shr using `make-xwidget' incorrectly Date: Thu, 11 Nov 2021 05:56:53 +0100 Message-ID: <87o86rb88a.fsf@gnus.org> References: <87sfw31mok.fsf.ref@yahoo.com> <87sfw31mok.fsf@yahoo.com> <87fss3e5kc.fsf@gnus.org> <87czn71hwi.fsf@yahoo.com> <8735o3e4u9.fsf@gnus.org> <87tugjz4dl.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12152"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 11 05:57:54 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ml29q-0002xC-87 for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Nov 2021 05:57:54 +0100 Original-Received: from localhost ([::1]:39504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ml29p-0005B0-5j for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Nov 2021 23:57:53 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38402) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ml28y-0004Ul-QD for emacs-devel@gnu.org; Wed, 10 Nov 2021 23:57:00 -0500 Original-Received: from [2a01:4f9:2b:f0f::2] (port=39430 helo=quimby.gnus.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ml28x-0004Gn-7R for emacs-devel@gnu.org; Wed, 10 Nov 2021 23:57:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=SvKVjAeMxjT5lI05wAEwqEOADkXbPYylLpoggi80Jsc=; b=lXYWv3TCV4U3fWgCVBnhZ9VS5t 87mwbUDgsu4ffeesi7A8Oz+0NyQXdY1vOS1Bc0mHHxDBKw1NqaoWD1AoAYSrMo5pABUwylOjxyOJQ CEy2SMM04ub0eWJRaqDROJPdu5q7EnvXLBCPvZ8SGTSeDEhR76c+RCKn263eLw2RPTVA=; Original-Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ml28r-0002QH-Qh; Thu, 11 Nov 2021 05:56:56 +0100 X-Now-Playing: Lolina's _Fast Fashion_: "A Really Spectacular Situation" In-Reply-To: <87tugjz4dl.fsf@yahoo.com> (Po Lu's message of "Thu, 11 Nov 2021 12:46:14 +0800") X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a01:4f9:2b:f0f::2 (failed) Received-SPF: pass client-ip=2a01:4f9:2b:f0f::2; envelope-from=larsi@gnus.org; helo=quimby.gnus.org X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:279222 Archived-At: Po Lu 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