unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Eivind Fonn <evfonn@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Drawing to cairo context from within emacs module?
Date: Fri, 06 Dec 2019 16:55:26 +0200	[thread overview]
Message-ID: <837e39h5b5.fsf@gnu.org> (raw)
In-Reply-To: <CAKNFwoQLZpykNFnG9C4WZ12BR45pn-40kykar09UezHFm2U2jw@mail.gmail.com> (message from Eivind Fonn on Fri, 6 Dec 2019 11:20:01 +0100)

[Please keep the list on the CC, so that others could see this discussion.]

> From: Eivind Fonn <evfonn@gmail.com>
> Date: Fri, 6 Dec 2019 11:20:01 +0100
> 
> Like Stephen I'm trying to do 'live' parsing.

I don't think I understand what "live parsing" is,  and Stephen said
he would up not using any direct access to buffer text.

> Boxing and unboxing (and copying) Emacs strings over and over isn't
> impossible, but it feels like unfettered access to the buffer should
> be in scope for a text editor that has dynamic module support.

Modules were designed to be able to communicate with Emacs via Lisp
objects, they don't get direct access to the internals of those
objects.

> If the gap can move at will that is unfortunate, but I'm not after
> a very long-term view, so I was hoping something might anyway
> be possible.
> 
> I need the gap because the buffer pointer isn't very useful on its
> own without that information.

You should also be aware of the fact that the internal representation
of buffer text is a superset of UTF-8, so direct access to it will
also need to copy a lot of code that Emacs uses internally to present
characters to Lisp programs.

And I still don't think I understand the rationale.  How about if you
explain why modules should be any different from a Lisp program in
this respect?



      parent reply	other threads:[~2019-12-06 14:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03 20:28 Drawing to cairo context from within emacs module? David Engster
2019-12-05  4:42 ` Richard Stallman
2019-12-05  5:35   ` Eli Zaretskii
2019-12-05  9:02     ` Pankaj Jangid
2019-12-06  4:12     ` Richard Stallman
2019-12-05 13:42 ` Eivind Fonn
2019-12-05 14:11   ` Stefan Monnier
2019-12-06  1:01     ` access to raw buffer text from module Stephen Leake
2019-12-05 15:08   ` Drawing to cairo context from within emacs module? Eli Zaretskii
     [not found]     ` <CAKNFwoQLZpykNFnG9C4WZ12BR45pn-40kykar09UezHFm2U2jw@mail.gmail.com>
2019-12-06 14:55       ` Eli Zaretskii [this message]

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=837e39h5b5.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=evfonn@gmail.com \
    /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).