...Troy Hinckley's project that I'm talking about. I was going
to mention this in my presentation, but it's possible,
theoretically, that Troy Hinckley, his project could be
used as a scheme of limitation that actually runs my own
version of Emacs. And although, you know, This is
completely theoretical, and I don't know how difficult
that would be. But if Troy Hinckley implemented enough of
the R7-RS standard in Rust, it would theoretically be
possible to run the Gypsum editor in Troy Hinckley's own
editor. I thought that was kind of interesting, and I
thought it was worth mentioning, at least in the questions
and answers.
I also mentioned this in the presentation. I wanted to see
Robin Templeton's project presentation, but
unfortunately it's going to be at like four in the morning
for me. So I'm going to try and watch that tomorrow, but
that's also going to be a very interesting project to keep an
eye on if you're interested in Scheme. That's the project
where you've got the Guylain interpreter running inside of
the Emacs process. It's dynamically linked as a library.
I'm ready for questions from anybody. You can ask or you can
type. It's up to you.
Okay, let me check the etherpad.
Let's see here.
I'm not sure if I'm doing that right.
Let me check one more time. Oh, there it goes.
Let's see, so this is...
I didn't know about that first bit of history. Oh, I've heard
RMS say that Scheme Guile is just a nicer Lisp, but I didn't
know there were concrete talks attempts to use Guile for
Emacs that early. Let's see, that was from janneke.
I'm curious to know how the hell Guile Emacs deals with all the
dynamically scoped modules out there. Is there any effort
to automatically modularize and name? Let's see.
That might be a better question for Robin Templeton. In my
own project,
there's no module system for Emacs Lisp. There is a module
system for Scheme. And the Emacs Lisp interpreter runs in
its own environment. the require system or whatever module
system that Emacs has, once it's implemented, all of that
would just happen inside of the Emacs Lisp environment,
which is inside of the Scheme environment. And
environments are objects in Scheme.
I think a more difficult question is how to handle
threading, and Scheme has very good threading built in, in
Serphe-18[??].
But I don't think it will be easy to write Emacs Lisp form
bindings to the Scheme multi-threading implementation.
Emacs Lisp was just not cut out for that kind of thing. So I
think each Emacs Lisp, you could, I suppose, have multiple
threads each running their own Emacs Lisp environment.
Scheme would make that very simple to do.
And then there'd just be a question of how you would get those
different interpreters to communicate with each other,
perhaps using the same protocol that's used by the Emacs
server. But I haven't thought that far ahead yet.
Would it be possible to support a GUI toolkit other than the
GTK? Like, how is it still supports Lucid? Yes, this is
absolutely a goal of the project. I'm trying to keep the back
end separate as possible. The scheme has what you call
parameters. And these are like global variables that are
still somewhat thread safe. And every call to the GUI goes
through a parameter. So the Emacs, the interpreter and the
editor logic is all in one module. And then that module calls
out into a separate GUI module. And then you can implement
different GUI modules. So you could have one for GTK3, one
for GTK4, if you want to write the extern C bindings around Qt
or full tick, that would certainly be possible as well. It
would be nice maybe to have an SDL implementation based
maybe on Chikiti or some kind of immediate mode GUI,
something like that. But definitely GTK3 through Guile GI
is the reference implementation. Things start there. But
I'm very interested in supporting other GUIs, yes. Let's
see.
Question, do you plan to provide improvements to ELisp
as a language or focus on a compatibility layer to
facilitate all new extensions in Scheme? Yeah, the second
one. I want to move off to Scheme. I would like for this
project to try and keep up to date with each new release of
Emacs and Emacs Lisp. That's a difficult moving target to
follow, I realize. But to the greatest extent possible, any
new features to Emacs Lisp will be pulled in from GNU Emacs.
If we happen to be able to implement something cool in
Scheme, and be able to port it over to Emacs Lisp, then sure,
it'd be nice to be able to upload or to submit that upstream to
the GNU Emacs. But I think I would prefer to have new features
written in Scheme. I would like this gypsum to be more of a
Scheme app platform that just happens to be able to also run
Emacs Lisp. That's how I see it. Of course, this will be a
community project. I'm open to debate about that if anybody
wants to convince me otherwise.
Why is being able to interpret all of that EL a useful goal?
Sure, there is a lot of code written in Elisp. Can we
consider... Oh, it's still being written. Please go ahead
and finish writing.
Can we consider a translator like utility to convert eLisp
to Scheme once Guile-Emacs has become a reality?
Certainly. For the time being, I just wanted to get the
interpreter running. So the actual, the Guile-Emacs Lisp,
the one that was written in 2011 that I didn't write, that
actually does compile to, I think it's the tree
intermediate representation It's one of the intermediate
languages that Guile uses to compile Guile scheme itself.
So the Emacs lisp that was written before actually does
that. It actually compiles and makes use of the entire Guile
compiler tool chain and actually produces like JIT
compilable binaries, which is really cool. Like I said,
that's the one that I had trouble getting to work properly.
Maybe we can follow that architecture. I'm not sure how to do
that, but I would like to be able to do some kind of
translating, keeping in mind that we want to have this be
portable, do various schemes. And so Guile makes this very
easy, but other schemes don't. Gambit might do this pretty
well as well. It compiles to C and then compiles C down to a
dynamically linkable library. So yeah, I think probably
the most portable, I'm just thinking out loud right now,
most portable implementation will just be able to
translate Emacs Lisp directly to Scheme, which is not what
the old Guile Emacs Lisp implementation does. That goes to
TreeIL, so it's very, very Guile-specific, can't be
ported. But yeah, if we could somehow get Emacs Lisp
translated to Scheme and then compiled, say, in Shea Scheme
or Gambit or MIT Scheme or one of those other compilers, that
would be very cool. And I would absolutely love to do that.
And I would very quickly accept any code into the code base
that would do that.
Oh, and to answer the question about init.el,
It's just because people spend a lot of time on their configs
and it would be nice if, you know, you're starting to use this
new editor and want it to be similar to Emacs users, just the
Emacs community in general and people who are familiar with
using Emacs. It would be more useful to everybody in the
Emacs community if this were more compatible with GNU
Emacs. And so that's why that's, I think that's an important
goal.
Question is not yet. Great. Oh, here comes another
question.
Okay, what is the plan to handle elisp packages that depend
on third-party or external libraries like git or magit
or ripgrep? So that's going to be tricky. It depends on how
these external packages are linked into emacs. If it's
going to be a dynamic library like Robin Templeton's
project which you load the libgit library into the Emacs
process, that is going to be extremely difficult. So if you
have an external library like, I don't know, libgit or
what's the GUI thing? Cabal. No, not Cabal. Cairo, libcairo
to do SVG graphics and so on.
You can do that very easily with Guile, but then on top of
that, implementing Emacs list bindings to it, I mean,
you've got two layers there, and that makes things pretty
difficult. So it's possible. And to some degree, maybe
necessary for example, Cairo, if we want to do SVG graphics
the way that Emacs Lisp does, we're going to have to have
that. So that would be necessary. We would have to have those
two layers. Yes, let's do that. But if it's like for Magit,
you can just call out to your git process, and then you're
just using the regular process APIs that Emacs Lisp has. And
that can be, already we, like Guile has some very good
implementations for process management. And so it would
just be a matter of wrapping up those in the Emacs lisp form
bindings. So yeah, dynamic libraries, I wanna try to avoid.
And I would prefer to do things more through, you know,
launching a child process in the Emacs process. and then
communicating over the standard in, standard out
channels.
That's the easier way to do things, I think, because then you
can just use the process library that Emacs already has, and
you can just reuse all of that code.
I'm not sure how ripgrep works, unfortunately, but I
believe that's also a process, a child process. So, we can
just reuse all of the Emacs Lisp code that does that already.
We just need to make sure that the process management
implementation and scheme is properly bound to Emacs Lisp,
and it works the same as GNU Emacs does. Once that's all set,
then these porcelains, like around git, should fall into
place. without too much difficulty, hopefully.
How about Schemax as a name? I like the name. I like that name.
I haven't really looked into like, is that already used or is
that going to be confusing? But certainly something we can
discuss.
Another thing I should mention,
I should probably set up a server or something like Discord
or something like that. Discourse, not Discord.
Discourse, the open source one, where we could actually
chat about this stuff. For the time being, ActivityPub,
mostly Mastodon, is how I communicate with people in real
time, that or email. So if you want to get a hold of me, check
the notes for this presentation and just send me an email.
Any question at all is fine. If you want to contribute code,
if you want to just learn how to contribute code, send me any
questions. It's fine. I'm happy to answer them. And we can
talk about the name as well.
Okay, why is it not feasible for the Emacs layer that
interprets Emacs Lisp, the core in C, have a Scheme
interpreter instead of using Guile? Let's see, I have to,
okay. Emacs layer interprets Emacs Lisp, the core in C, have
a Scheme interpreter instead of using Guile. Okay, so that,
the question xlarsx is asking, xlars, x, So Lars is asking,
is it not feasible for there to be an
Emacs layer that interprets Emacs Lisp have a scheme
interpreter? This is Robin Templeton's project. And
they're presenting later today. So check the roster and be
sure to see that presentation because that's exactly what
Robin Templeton is doing. That's not what I'm doing though.
I'm trying to create something in Scheme. But yes, there is
an attempt to get an Scheme interpreter to run inside of
Emacs itself. And it has its own method of binding to Emacs
Lisp functions and translating data like Lisp structures
between Guile Scheme and Emacs Lisp. Robin will explain all
of that in their presentation.
OK, I think I've got through all the questions on Etherpad.
But I'm going to hang out here for a bit longer. And yeah, feel
free to do a video chat with me or send me more questions on
Etherpad or here in the big blue button. And so I'm just going
to hang out. And thanks for asking all your questions. And
yeah, I look forward to working with all of you if you're
interested. take it easy. Thanks so much for the talk and
looking forward to seeing some of your progress as this
moves forward, exciting space. We'll go ahead and leave the
room open for you and thanks for offering to hang out and chat
with other people that come by. Feel free to throw something
in the chat if you want to remind people you're still here.
Meanwhile, on the stream, we have moved along to our next
talk on Rust, and that is just getting started. But again,
we're continuing to record this, and I'll just keep an eye on
it to stop the recording. Thank you. Thank you. It was
awesome.
So it seems like it's slowed down here for the Q&A. I don't see
anybody else on BBB, so I'm going to go ahead and stop the
recording. We can start it back up. I would say, yes, there's
a lot of things you can do with this. You can handle
processing. Yeah, I'm going to try and join over the chat for
the next talk. I'm not sure if I can do both big blue buttons at
the same time. You should be able to just watch your mute
settings and mute tab settings and whatever all you have to
avoid bleed through. Okay.