From: Eli Zaretskii <eliz@gnu.org>
To: Anand Tamariya <atamariya@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: SVG hack for display engine
Date: Mon, 15 Nov 2021 16:02:05 +0200 [thread overview]
Message-ID: <83sfvxsejm.fsf@gnu.org> (raw)
In-Reply-To: <CADm7Y4=DjY7_wPgSzWkyXsB0ujFYUViK5nB5JwS-qx+z1htrRw@mail.gmail.com> (message from Anand Tamariya on Mon, 15 Nov 2021 18:57:20 +0530)
> From: Anand Tamariya <atamariya@gmail.com>
> Date: Mon, 15 Nov 2021 18:57:20 +0530
> Cc: Emacs Devel <emacs-devel@gnu.org>
>
> In this hack, the elisp code navigates from (window-start) to (window-end) reading a line of text from the
> associated buffer and displays the same in SVG. I've used (read-event) and (lookup-key) to allow for key
> translations for navigation commands. Hopefully with a tighter integration, all of this will not be required.
So you use the results of the display engine to display the same stuff
differently, is that right?
If so, I'm not sure I understand how to do it "properly". The Emacs
display engine performs the layout calculations (which determine, for
example, where each screen line ends and the next one begins, or what
stuff fits into a window) by examining each character of buffer text
in turn. Without this examination, how can we know how to display the
text as SVG? And if we use the current code to produce this
information, then what did we gain?
I'm probably missing something.
next prev parent reply other threads:[~2021-11-15 14:02 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 [this message]
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
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=83sfvxsejm.fsf@gnu.org \
--to=eliz@gnu.org \
--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).