Drawing to cairo context from within emacs module?

Drawing to cairo context from within emacs module?

[David Engster]

There's probably a million things I'm missing here, but would it be
possible to access the cairo context from within an emacs module, so
that one could simply draw stuff using the Cairo API (on Cairo-enabled
Emacsen only, of course)? I'm sure this won't play well at all with
redisplay, but it'd be fun playing around with it...

-David

Re: Drawing to cairo context from within emacs module?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > There's probably a million things I'm missing here, but would it be
  > possible to access the cairo context from within an emacs module, so
  > that one could simply draw stuff using the Cairo API (on Cairo-enabled
  > Emacsen only, of course)? I'm sure this won't play well at all with
  > redisplay, but it'd be fun playing around with it...

The primary purpose of GNU Emacs, or any other GNU program, is to
contribute to what the GNU operating system can do.

The feature you are asking for would operate only on a non-GNU
operating system.  Emacs with that feature would give a non-GNU system
(even worse, a non-free system) better support than it gives to GNU.
That would detach it from the GNU Project and work against our goal.

Sorry, but we must not implement this.

It would be ok to implement the feature so that it works on GNU with
GTK2 and work on MacOS with Cairo.  That way, the feature would
enhance the GNU system and we could continue to say validly that Emacs
"runs best on GNU."

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Drawing to cairo context from within emacs module?

[Eli Zaretskii]

On December 5, 2019 6:42:55 AM GMT+02:00, Richard Stallman <rms@gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>  > There's probably a million things I'm missing here, but would it be
> > possible to access the cairo context from within an emacs module, so
> > that one could simply draw stuff using the Cairo API (on
> Cairo-enabled
>  > Emacsen only, of course)? I'm sure this won't play well at all with
>   > redisplay, but it'd be fun playing around with it...
> 
> The primary purpose of GNU Emacs, or any other GNU program, is to
> contribute to what the GNU operating system can do.
> 
> The feature you are asking for would operate only on a non-GNU
> operating system.  Emacs with that feature would give a non-GNU system
> (even worse, a non-free system) better support than it gives to GNU.
> That would detach it from the GNU Project and work against our goal.
> 
> Sorry, but we must not implement this.
> 
> It would be ok to implement the feature so that it works on GNU with
> GTK2 and work on MacOS with Cairo.  That way, the feature would
> enhance the GNU system and we could continue to say validly that Emacs
> "runs best on GNU."

I think you are mistaking Cairo for something else.  Emacs supports Cairo on GNU systems.

Re: Drawing to cairo context from within emacs module?

[Pankaj Jangid]

Eli Zaretskii <eliz@gnu.org> writes:
> On December 5, 2019 6:42:55 AM GMT+02:00, Richard Stallman <rms@gnu.org> wrote:
>> The feature you are asking for would operate only on a non-GNU
>> operating system.  Emacs with that feature would give a non-GNU system
>> (even worse, a non-free system) better support than it gives to GNU.
>> That would detach it from the GNU Project and work against our goal.
>> 
>> It would be ok to implement the feature so that it works on GNU with
>> GTK2 and work on MacOS with Cairo.  That way, the feature would
>> enhance the GNU system and we could continue to say validly that Emacs
>> "runs best on GNU."
>
> I think you are mistaking Cairo for something else.  Emacs supports Cairo on GNU systems.

Cocoa probably. 

Regards,
--
Pankaj Jangid

Re: Drawing to cairo context from within emacs module?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

It looks like I did confuse Cairo with something else.
The general point is valid, but it seems that it doesn't
apply to Cairo.

Please forgive my confusion.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Drawing to cairo context from within emacs module?

[Eivind Fonn]

A related but different question. Would it be possible to get access to
the raw buffer data from dynamic modules? (That is, pointer to the start,
length and gap information.) I'm only interested in read-only access,
and I'd be happy to patch it in myself if it's deemed generally acceptable.

Eivind

On Tue, Dec 3, 2019 at 10:27 PM David Engster <deng@randomsample.de> wrote:
>
> There's probably a million things I'm missing here, but would it be
> possible to access the cairo context from within an emacs module, so
> that one could simply draw stuff using the Cairo API (on Cairo-enabled
> Emacsen only, of course)? I'm sure this won't play well at all with
> redisplay, but it'd be fun playing around with it...
>
> -David
>

Re: Drawing to cairo context from within emacs module?

[Stefan Monnier]

> A related but different question. Would it be possible to get access to
> the raw buffer data from dynamic modules? (That is, pointer to the start,
> length and gap information.)

You might like to talk with Stephen Leake
<stephen_leake@stephe-leake.org>.
IIUC he wrote a dynamic module which parses the buffer.  AFAICT he
didn't use such a "raw" access, so it'd be interesting to hear about
his experience.

> I'm only interested in read-only access, and I'd be happy to patch it
> in myself if it's deemed generally acceptable.

It would tend to expose internal data subject to change (and offer the
ability to change this data in a way that can break some invariants), so
it's definitely not in the style of the current module interface.

But we may be able to provide a slightly less "raw" access that doesn't
suffer in the same way.  So details about your particular needs would be
helpful to try and figure out what we can do (i.e. tell us the problems
you face when using `char-after` or `buffer-substring`, which would be
the main ways I can think of to access the buffer's content with the
current module API).


        Stefan

Re: access to raw buffer text from module

[Stephen Leake]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> A related but different question. Would it be possible to get access to
>> the raw buffer data from dynamic modules? (That is, pointer to the start,
>> length and gap information.)
>
> You might like to talk with Stephen Leake
> <stephen_leake@stephe-leake.org>.
> IIUC he wrote a dynamic module which parses the buffer.  AFAICT he
> didn't use such a "raw" access, so it'd be interesting to hear about
> his experience.

No, I sent the buffer content as a string.

I was hoping to avoid that copy, but other things turned out to be way
slower (creating _lots_ of text properties), so I went back to a
separate process, and made that faster (doing more stuff in the process,
so fewer text properties are needed).

>> I'm only interested in read-only access, and I'd be happy to patch it
>> in myself if it's deemed generally acceptable.
>
> It would tend to expose internal data subject to change (and offer the
> ability to change this data in a way that can break some invariants), so
> it's definitely not in the style of the current module interface.
>
> But we may be able to provide a slightly less "raw" access that doesn't
> suffer in the same way.  So details about your particular needs would be
> helpful to try and figure out what we can do (i.e. tell us the problems
> you face when using `char-after` or `buffer-substring`, which would be
> the main ways I can think of to access the buffer's content with the
> current module API).

In my case, I wanted raw speed when lexing the source text. The lexer
I'm using can handle utf-8, when given a start address and byte length.

Allowing for a gap would mean checking for that at each byte, which
might slow things down as much as copying.

But lexing is a _very_ small portion of the total parse time, so it's
really not worth worrying about the copy either; even sending the text
to a separate process does not take a noticeable amount of time.

If I convert to LSP style (https://langserver.org/), then the full text
is sent once, and only edits are sent after that, making the copy issue
irrelevant.

-- 
-- Stephe

Re: Drawing to cairo context from within emacs module?

[Eli Zaretskii]

> From: Eivind Fonn <evfonn@gmail.com>
> Date: Thu, 5 Dec 2019 14:42:58 +0100
> 
> A related but different question. Would it be possible to get access to
> the raw buffer data from dynamic modules? (That is, pointer to the start,
> length and gap information.)

Why do you need to do that from a module?  I'm especially curious in
your reasons to know where the gap is.

Please keep in mind that Emacs relocates the gap and the buffer text
itself at will, so such pointers could easily be invalidated by the
next GC.

Re: Drawing to cairo context from within emacs module?

[Eli Zaretskii]

[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?