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: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets) Date: Tue, 01 Dec 2020 21:41:16 +0200 Message-ID: <83h7p5gvqb.fsf@gnu.org> References: <864kmzupp0.fsf@akirakyle.com> <86pn46awrr.fsf@akirakyle.com> <87y2ise7j5.fsf@gnus.org> <86tutfwhr6.fsf@akirakyle.com> <87h7pfb76z.fsf@gnus.org> <86h7peqkt5.fsf@akirakyle.com> <83tutdsc8i.fsf@gnu.org> <86eeker01y.fsf@akirakyle.com> <83wny5naf5.fsf@gnu.org> <86o8jh9cij.fsf@akirakyle.com> <83czzwkmwk.fsf@gnu.org> <86lfeja49y.fsf@akirakyle.com> <87czzu7y5r.fsf@logand.com> <83im9likm8.fsf@gnu.org> <87eek977nf.fsf@logand.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34838"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Tomas Hlavaty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 01 20:42:21 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 1kkBXY-0008vq-Ra for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Dec 2020 20:42:20 +0100 Original-Received: from localhost ([::1]:55906 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkBXX-0000L2-Tt for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Dec 2020 14:42:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43364) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkBWb-0008Hv-TA for emacs-devel@gnu.org; Tue, 01 Dec 2020 14:41:21 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33327) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkBWb-0001xz-Bh; Tue, 01 Dec 2020 14:41:21 -0500 Original-Received: from [176.228.60.248] (port=4439 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kkBWa-0000Ak-Hk; Tue, 01 Dec 2020 14:41:21 -0500 In-Reply-To: <87eek977nf.fsf@logand.com> (message from Tomas Hlavaty on Tue, 01 Dec 2020 18:33:56 +0100) 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:260159 Archived-At: > From: Tomas Hlavaty > Date: Tue, 01 Dec 2020 18:33:56 +0100 > > w3mimgdisplay program can be run as a kind of "server", where I can say: > > - draw this image to these coordinates on the screen > > - or additionally, cache image's data and return a handle to the cache, > which will make redrawing fast. How would Emacs communicate with w3mimgdisplay? via some pipe? is that fast enough to be done in the middle of redisplay? > I think that the only issue for me is that there is no way to implement > an alternative "system API" and "call some image library" in pure elisp. Why is that an issue? And what does an implementation in pure Lisp have to do with w3mimgdisplay? > How much work would it be to enable alternative "system API" and "call > some image library" in pure elisp? If they support the same interfaces, very little. But I'm not sure we are on the same page yet, so we might be miscommunicating. > >> It would be more convenient, if an image was represented as elisp data > >> instead of C data. > > > > create-image already knows how to accept image data. > > But those must be defined in C, see lookup_image_type. You are supposed to submit data in one of the known formats. Why is that a problem? why do you care about the exact format of the image data, and why do you insist to introduce a new type instead of using existing types? > Or is there a way to define custom image format in pure elisp? No. > It would be actually enough for me if my custom image was opaque to > emacs (except probably some attributes like width and height) and > w3mimgdisplay handled the rest. That's okay, but I still don't see how all that will fit into the current framework of displaying images. > >> iirc there is no way to add new image types without touching C. > > > > No, because you need to know how to convert that into the internal > > format used to draw the image, which is platform dependent. > > I don't need to know that. w3mimgdisplay program does that. How can w3mimgdisplay know the internal format used by Emacs for storing images? > As far as emacs is concerned, it needs to give to w3mimgdisplay > filename to draw and then use a handle to cache to ask w3mimgdisplay > for redraw. I suggest to take a look at x_draw_image_foreground and its subroutines, this is where we actually put the image on the glass. Then tell in a bit more detail how to integrate an external program into that, keeping all the features we support in this regard, like masks, clipping, slices, etc. > > Why is it a problem to use one of the known image types? E.g., SVG > > (via the svg.el library). > > Because those those are not universally available, e.g. on the console. On the console you currently cannot have images in Emacs, period. This is not because of image libraries, this is because the text-mode display simply cannot currently support such display elements. > Because those might not be suitable. "Not suitable" in what ways? > >> Is there a way to turn off cursor for a buffer? > > > > There's the cursor-type variable. > > Thanks. > > This does not work on the console. (You never said you were talking about a console.) We currently don't expose console cursor control to Lisp. Should be easy to add that, if needed. > Is there a way to hook a function when a buffer looses and gains focus? Buffer cannot have focus. Do you mean when the buffer's window is the selected window? There's window-selection-change-functions. > >> Is there a way run a function after emacs changes something on the > >> screen in a buffer? > > > > That depends by what you mean by "after emacs changes something on the > > screen", since in Emacs redisplay is independent/separate of data > > changes. Please elaborate. > > Example: I am on the console. I am in dired buffer. I press my key. > w3mimgdisplay program draws my image on the screen on the specified > coordinates "over" emacs. All is well (except the blinking cursor which > we can ignore for now). Now I press another key to display the next > image in the dired buffer. Emacs redraws some characters, that have > changed. This disrupts the image drawn earlier and I need to detect, > that I need to tell w3mimgdisplay to redraw the image. I need to hook > my redraw image function after emacs is done with its drawing. I don't think we have such a hook, no. But if we had it, using it like you want would cause annoying flickering, because you'd constantly redraw the image at very high frequency. > Is there such hook? If not, would it be difficult to add it? It won't be hard to add it, but I'm not sure we want to add such a hook, see above.