From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: shr using `make-xwidget' incorrectly Date: Thu, 11 Nov 2021 12:46:14 +0800 Message-ID: <87tugjz4dl.fsf@yahoo.com> References: <87sfw31mok.fsf.ref@yahoo.com> <87sfw31mok.fsf@yahoo.com> <87fss3e5kc.fsf@gnus.org> <87czn71hwi.fsf@yahoo.com> <8735o3e4u9.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3790"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 11 05:47:14 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 1ml1zW-0000o0-HN for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Nov 2021 05:47:14 +0100 Original-Received: from localhost ([::1]:59706 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ml1zU-00077r-UJ for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Nov 2021 23:47:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35206) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ml1yk-0006Oo-R9 for emacs-devel@gnu.org; Wed, 10 Nov 2021 23:46:26 -0500 Original-Received: from sonic306-22.consmr.mail.ne1.yahoo.com ([66.163.189.84]:35348) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ml1yj-0002Tn-4C for emacs-devel@gnu.org; Wed, 10 Nov 2021 23:46:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1636605983; bh=aIcJ/adqmfFoKmrlVJOpsZ+FlxijR/wCpiUhad0cha8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=pJUAJ3l1Ol1ygdH87rVQxPhMhvMV/Wb2w+faAUKhkZHmH7Yv42QsJsNtlIYFqjzHyjamtTgVS0tuyfWJDYG2AT4xGnCxxW0CWC8tjVHETBGhNbFPAxaF6cZyvHfJxYlmz6hwSqq3qcLJDEL/hSOq+USQV3GgUr9Jk5+6WiiA3ASs8Sj3pWM9Q9IjKTfM8Fk5kOhjZg4zonjnIwXQ7dKlWBYnv+RYTycz+aJAJ35fIbB2mXhiGJ9RfNjg1XfeA5SBuywX6SAiOJgiMXXAkIU64YMJuph1WK9MPKTjKvNdOTt20C5pCeQmev/ts1PbXee+WtnGpaEviQ5IbujW3ahF/g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1636605983; bh=V8OTFVv0M+L20kA9G+gLSRFC2BUScEJD05+up316jAO=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=CgAK8qCNNvu5gbK2VZKtQKnyw5MRArAWv7V8tg1t96+hOJdr+1Heesp4CmZFrugLqg5HxCa7Hq2EY+qxI46MdodAg6aHNCN6EubC2MjiLkUQDyZPqrWKxuBRL7ddKqxIeZzF7t/oEY7vVxnHrzHOW0MOWLb287oTMfa5tg9Zcb5IP9UIAKXD1agzT5uJ3XhPa7rKpnG/B5wVBQR80soQkOiRh38HyscaZlPT0cwx8ACSx3FL2havlJPI6JKd6x72uIfp5gry7f5AJaSMG7grRYjpeA5FHJE3yKf4Uy3lksOMaJKKIz5+lresoBJIaRlqEWuM9iui2WsV0HPhsxxr2w== X-YMail-OSG: EO5fjzoVM1lqmSV8L2x0OZZ4l3k8TbQ6vhOcFEN1ENF_ioW3OL9uZGczvgpLvDU u00GlG89G1df4m_.gDU78qMHCAKJpt49.MyVEFKFlRttf6Wdg8Inaer_RjuCLW.SK8YfW0LgPuQO wlXSOByOBoFgPydoJWplNh2CFta2DWa3Y23gR8HDTT4V6GXLm57Xzm7cy4jQiJJyy9nRlT5cvL64 0xshgIQk4U4KfcqGQglJJw6HS6dwb.LLJ_TiBC6p2W4rKCnByx8Uh7XzHVZEG18lD1O6874PXCNG .tttV6rUVhFkzUxkgfAT58qAjpTTEXD1OWndtm1mGP1C3mM7nLQJMHgEOWrFxC_0_WYX.W_J3.oR ruFQgNpHQ86jUglBMtff2obRW607N4OnSRndUYhcEhF2cIa7FkdPZTolpuX2_QVno.Lzdz6AdJS8 Hy2SC0pathwy.X2f0rim5setVZb6IABKhVAWuCu27rqcAA2Swm7rOhhR8A5hHXa3tsPtLdWvpjY8 C9bXMqwNSZQlPPHBjxciS7wsGIuXvrgg6vznpC4jW.h4FwMokkX2Qleqw7T8HS9BTwDYG75KWDTl ETxu3ZA6TesAiN20mjI1oFxbn.SGiQQv5huRf3BtxF.fL_arC1Q9sZ7SfpAUwzg5DoyYDrI2M8wv by.bmEPIv0_WBTUg0hXdz3QA6TocEoONz871EakLJimvv_4SRfk1HkDTZ_PeWUWEKJcI6eH8CCV0 CxhLgwRN_u8Jzu.ZajoAQ8xEPaKYF3Y0CRjA2OflemFfIebWnp_aA4tM9bYhX3Cl_tdtY8fi22Q1 R5QkvDprW3wyUHHc5hpI3IlL4sqj.5Z0VkPUygF2Nw X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Thu, 11 Nov 2021 04:46:23 +0000 Original-Received: by kubenode501.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9992946f300826fa105b5d1aee859279; Thu, 11 Nov 2021 04:46:17 +0000 (UTC) In-Reply-To: <8735o3e4u9.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 11 Nov 2021 04:41:50 +0100") X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.189.84; envelope-from=luangruo@yahoo.com; helo=sonic306-22.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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:279221 Archived-At: Lars Ingebrigtsen writes: > I don't see the similarity -- killing the buffer will kill the xwidgets, > while killing the buffer won't kill the process. On the other hand, > deleting text in a buffer won't make the process become unavailable. Sorry, I meant only processes with associated buffers. This is how it would make sense for xwidgets to behave as well. 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. At present, the only way to kill an xwidget (and to make it potentially unavailable) is to kill the buffer it's associated with. So even if we were to introduce an "evaporable" xwidget type, I think it would only make sense to have it done as part of garbage collection. >> However, randomly killing xwidgets based on whether or not they are >> displayed would be undesirable: xwidgets have a lot of state that cannot >> be reconstituted through recreating them, and creating them takes a long >> time and a lot of memory. > There's nothing random about it. If the caller has marked the widgets > as being evaporable, then the caller wants those xwidgets to go away if > they're no longer displayed. 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.) 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. Please tell me if I'm missing anything, or you have more comments to make. Thanks in advance!