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: SVG hack for display engine Date: Thu, 18 Nov 2021 16:52:55 +0200 Message-ID: <837dd5y0qg.fsf@gnu.org> References: <83zgq41cra.fsf@gnu.org> <83k0h818zw.fsf@gnu.org> <83mtm2zyf6.fsf@gnu.org> <83pmqxyj3j.fsf@gnu.org> <83czmxyaio.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18852"; mail-complaints-to="usenet@ciao.gmane.io" Cc: alexander.adolf@condition-alpha.com, emacs-devel@gnu.org To: Anand Tamariya Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 18 15:56:52 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 1mniqJ-0004g8-J9 for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Nov 2021 15:56:51 +0100 Original-Received: from localhost ([::1]:50150 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mniqI-0003Qq-KN for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Nov 2021 09:56:50 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50870) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnimZ-0007oX-Vf for emacs-devel@gnu.org; Thu, 18 Nov 2021 09:53:00 -0500 Original-Received: from [2001:470:142:3::e] (port=51720 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnimY-00074Z-Lp; Thu, 18 Nov 2021 09:52:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=GMQecStXi3NGKP2HM3ARFvEgRWTqk4DyddQOnwMibkQ=; b=lScvxb9UWjRX pIp+tt/hTcHTpU3km+rCINyRxJ31uI2MxEQG/Q+aklNo2FN5/9ZW3QDb4A7AvfHD3DX/T4jl/gZlm BWh90FYd1K6kLt0cevxSH6FfckcjCOI/rIXX35JhV1Y8ea2/SITxXsKDKkoKHFNA0+5ELtmKECAsI h970h77V5gGUEQ2gWwwf16LLLNYEUSLAgcB4AehVoIFmNq87TAF3jGzN8yTgi9jxCBq6cR9E4LQPB 8KvFypxljB+H4ol+iQTeJdqUC2Ye5hzoVB+RLXsA4+S2+J5Tuu35BXL1Ryttk1cwofySJ4UhKpuDU 4RS/dKVgpVKo25PsntfXWg==; Original-Received: from [87.69.77.57] (port=4517 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnimY-000838-Ah; Thu, 18 Nov 2021 09:52:58 -0500 In-Reply-To: (message from Anand Tamariya on Thu, 18 Nov 2021 18:59:10 +0530) 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:279678 Archived-At: > From: Anand Tamariya > Date: Thu, 18 Nov 2021 18:59:10 +0530 > Cc: Alexander Adolf , Emacs Devel > > But that's not generally true. Redisplay has its own criteria to > decide which parts need to be redrawn, and those criteria are not > necessarily trivial to guess from buffer contents alone, because > redisplay has access to all kinds of information recorded specifically > for that purpose, and not exposed to Lisp. > > Display engine must continue to do what it does presently to not break any functionality in the terminal and > elsewhere. I'm only asking to extend the functionality to allow a developer more freedom to play with SVG > should he desire. OK, but I still don't understand what you need from the display engine for that purpose. > > . what is the "required information" to be passed to > > display-svg-hook, and how will it be generated from the information > > that exists in the display engine? > > > > "required information" in my sentence above refers to the parameters of (svg-render) API viz. svg x y > width > > height. display-svg-hook can be a no-arg function. > > What are X, Y, WIDTH and HEIGHT here? > > - svg-render (svg x y width height) > svg is a Lisp DOM object as returned by (dom-node). This should use librsvg to generate a bitmap image of > svg of size (width x height) and superimpose it at position (x, y) on the current bitmap being displayed by > Emacs. The current image API takes either a filename or XML string for SVG. This can be avoided if svg is a > Lisp DOM. Edit: (dom-node) is defined in dom.el . I know that dom-node is defined in dom.el. What I don't understand is which code will generate a DOM, and based on what information. > And how will those hooks or svg-render know what to display an where > on the screen? > > Take some simple cases like a tooltip or an auto-completion popup. They usually display near the point with > some offset. (posn-at-point) provides that information. For complete window display control like my formula > editor, they can specify to display at (0,0) an image of size (window-pixel-wdth) x (window-pixel-height). So this is only for popping up some additional image on top of the "normal" Emacs display? Or is the intent to replace some parts of the "normal" Emacs display, i.e. what we show in the windows of the regular frames? And if this is just for popups, isn't there already some hook ypou could use for that purpose? If not, what is missing in the existing hooks?