From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Rethinking the design of xwidgets Date: Tue, 13 Oct 2020 17:16:20 +0300 Message-ID: <835z7e2ouj.fsf@gnu.org> References: <864kmzupp0.fsf@akirakyle.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38467"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Akira Kyle Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 13 16:17:19 2020 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 1kSL78-0009tB-DX for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Oct 2020 16:17:18 +0200 Original-Received: from localhost ([::1]:45064 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSL77-000120-Ca for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Oct 2020 10:17:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58230) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSL67-0008Hc-Kx for emacs-devel@gnu.org; Tue, 13 Oct 2020 10:16:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36066) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSL66-0007lV-NS; Tue, 13 Oct 2020 10:16:14 -0400 Original-Received: from [176.228.60.248] (port=4768 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kSL65-0006xL-To; Tue, 13 Oct 2020 10:16:14 -0400 In-Reply-To: <864kmzupp0.fsf@akirakyle.com> (message from Akira Kyle on Mon, 12 Oct 2020 14:58:19 -0600) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:257534 Archived-At: > From: Akira Kyle > Date: Mon, 12 Oct 2020 14:58:19 -0600 > > One of my primary uses of emacs is as a scientific notebook > utilizing org mode's support for literate programming to > interweave prose, LaTeX, and code. I find this to be far more > powerful and comfortable than using the Jupyter notebooks which > have quickly become incredibly popular for such scientific > computing. However the biggest pain point I have is due to Emacs' > relatively poor capabilities for interfacing with objects other > than text. Sure Emacs can display images ok, but I'm not aware of > any way to get emacs to display more dynamic content. Can you tell more about the dynamic content you had in mind, and why you thought to use xwidgets as the basis for that? There's IMO a leap of logic here that I cannot follow, perhaps because I don't have the necessary background information. >From my POV, xwidgets have several problems which don't allow me to easily see them as the basis for some much more general set of features or infrastructure: . they depend on GTK and webkit, whose development leaves a lot to be desired, and some say parts of that have no future; they are definitely less portable than I'd like to see in Emacs . their integration in the Emacs display code "needs work", there's at least one or two places where the code which handles them is clearly wrong -- this is semi-okay for a minor niche feature, but not for something on which we want to build our future So before we decide that xwidgets is the way to go, I'd like to make a step back and see what other alternatives we can think of, if any, and carefully consider which alternative is best in the long run. > That leads me to my following proposal to rethink the design of > xwidgets. Given that Emacs now has support for dynamic modules and > it is now enabled by default, I propose exposing an interface for > dynamic modules to define custom xwidgets. I believe this would be > a good way to solve the two fundamental issues with the current > xwidgets implementation that I described above. Having a well > defined interface means one wouldn't have to deal with debugging > subtle redisplay and lisp interpreter issues when creating a > custom xwidget type. Furthermore any external library needed for a > custom xwidget type will only be required if one chooses to use > that xwidget type and would keep such dependencies out of Emacs > itself. Here, too, I'd like first to consider a design that doesn't require dynamic modules as a prerequisite for the feature. If we can come up with something that requires only Lisp (like image display does, for example), then I think we all win, because it is much easier to write a Lisp package than a package that requires a module in C or similar language. Bottom line, I'd like to understand the problem you are trying to solve better before we conclude that xwidgets and dynamic modules are the way to go. Thanks.