unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Anand Tamariya <atamariya@gmail.com>
Cc: alexander.adolf@condition-alpha.com, emacs-devel@gnu.org
Subject: Re: SVG hack for display engine
Date: Thu, 18 Nov 2021 16:52:55 +0200	[thread overview]
Message-ID: <837dd5y0qg.fsf@gnu.org> (raw)
In-Reply-To: <CADm7Y4n5p-ENYF=mHUhkH+vKcnuVtdgALXRuoaXRx8WgAKrdJA@mail.gmail.com> (message from Anand Tamariya on Thu, 18 Nov 2021 18:59:10 +0530)

> From: Anand Tamariya <atamariya@gmail.com>
> Date: Thu, 18 Nov 2021 18:59:10 +0530
> Cc: Alexander Adolf <alexander.adolf@condition-alpha.com>, Emacs Devel <emacs-devel@gnu.org>
> 
>  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?



  reply	other threads:[~2021-11-18 14:52 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-15  2:39 SVG hack for display engine Anand Tamariya
2021-11-15 12:45 ` Eli Zaretskii
2021-11-15 13:27   ` Anand Tamariya
2021-11-15 14:02     ` Eli Zaretskii
2021-11-16  3:01       ` Anand Tamariya
2021-11-16  3:28         ` Po Lu
2021-11-16 12:56           ` Eli Zaretskii
2021-11-16 13:02             ` Po Lu
2021-11-16 12:55         ` Eli Zaretskii
2021-11-16 14:08           ` Alexander Adolf
2021-11-16 14:16             ` Eli Zaretskii
2021-11-16 14:22               ` Alexander Adolf
2021-11-17  4:33               ` Anand Tamariya
2021-11-17  4:46                 ` Po Lu
2021-11-26  1:33                   ` Gerry Agbobada
2021-11-17 13:47                 ` Eli Zaretskii
2021-11-17 23:47                   ` Anand Tamariya
2021-11-18  8:16                     ` Eli Zaretskii
2021-11-18 10:13                       ` Anand Tamariya
2021-11-18 11:21                         ` Eli Zaretskii
2021-11-18 13:29                           ` Anand Tamariya
2021-11-18 14:52                             ` Eli Zaretskii [this message]
2021-11-19  1:32                               ` Anand Tamariya
2021-11-19  7:07                                 ` Eli Zaretskii
2021-11-20 19:44                                 ` Alan Third
2021-11-22  2:48                                   ` Anand Tamariya
2021-11-22 10:59                                     ` Alan Third

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=837dd5y0qg.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=alexander.adolf@condition-alpha.com \
    --cc=atamariya@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).