WEBVTT timed by sachac, captioned by ramin
00:00:00.000 --> 00:00:02.780
Hi, my name is Ramin Honary,
00:00:02.781 --> 00:00:04.480
and I'm here to talk to you today
00:00:04.481 --> 00:00:08.940
about my clone of Emacs and Emacs Lisp that I've written in
00:00:08.941 --> 00:00:12.980
Scheme so far.
00:00:12.981 --> 00:00:19.102
So I am an Emacs enthusiast since 2017,
00:00:19.103 --> 00:00:22.664
currently employed as a full stack developer,
00:00:22.665 --> 00:00:25.225
mostly working with Python and JavaScript,
00:00:25.226 --> 00:00:27.079
although my true love is functional
00:00:27.080 --> 00:00:30.559
programming, especially Haskell, and Scheme. I started
00:00:30.560 --> 00:00:33.679
learning Scheme about two years ago. And for the past year,
00:00:33.680 --> 00:00:36.279
I've been working on a project that I'm tentatively calling
00:00:36.280 --> 00:00:40.794
Gypsum. Naming things is hard. It's not a great name.
00:00:40.795 --> 00:00:43.376
I'm open to suggestions.
00:00:43.377 --> 00:00:45.897
But yes, this is the project in which
00:00:45.898 --> 00:00:53.319
I am trying to write an Emacs Lisp interpreter in Scheme.
00:00:53.320 --> 00:00:58.199
There are many clones already of Emacs. You've probably
00:00:58.200 --> 00:01:04.799
heard of Edwin, Jed, Jedit, Jove, Lem, MG, Yi, Zile. Edwin
00:01:04.800 --> 00:01:10.519
itself is also written in Scheme--MIT Scheme. These only
00:01:10.520 --> 00:01:16.159
clone the key bindings of Emacs and not Emacs Lisp itself.
00:01:16.160 --> 00:01:21.199
The only alternative to GNU Emacs that I'm aware of is
00:01:21.200 --> 00:01:26.679
XEmacs, which is a fork of GNU Emacs.
00:01:26.680 --> 00:01:30.359
Most people don't use Emacs for the key bindings. I mean,
00:01:30.360 --> 00:01:34.039
this is anecdotally speaking, but the people who I've
00:01:34.040 --> 00:01:39.519
talked to, I would say don't use Emacs for the key bindings.
00:01:39.520 --> 00:01:42.679
They use it really more because of the power of Emacs Lisp.
00:01:42.680 --> 00:01:48.439
Emacs is as powerful as any system shell, perhaps even more
00:01:48.440 --> 00:01:53.105
powerful than system shells like Bash.
00:01:53.106 --> 00:01:55.207
The reason why it's so powerful is because
00:01:55.208 --> 00:01:56.959
there's a good programming language
00:01:56.960 --> 00:02:00.039
which you can use to control everything on your system. You
00:02:00.040 --> 00:02:01.732
can control processes. You can load and save files.
00:02:01.733 --> 00:02:06.416
You can create files. You can configure things.
00:02:06.417 --> 00:02:10.219
You can capture the output of processes in buffers.
00:02:10.220 --> 00:02:13.421
You can filter text through buffers.
00:02:13.422 --> 00:02:17.839
And a good programming language is what
00:02:17.840 --> 00:02:23.479
you need in order to do all of this. So one big goal of this
00:02:23.480 --> 00:02:29.239
project is to try to stick as closely as possible to the R7RS
00:02:29.240 --> 00:02:33.859
standard Scheme definition. That is the latest Scheme
00:02:33.860 --> 00:02:38.919
standard: R7. And this is just because I want my project to
00:02:38.920 --> 00:02:43.519
work on many scheme implementations, not just Guile.
00:02:43.520 --> 00:02:45.499
Although Guile certainly is the reference
00:02:45.500 --> 00:02:50.239
implementation.
00:02:50.240 --> 00:02:56.459
So another goal is to be able to run any "init.el".
00:02:56.460 --> 00:02:59.740
So you can take your existing "init.el"
00:02:59.741 --> 00:03:01.720
and run it in my program without
00:03:01.721 --> 00:03:05.340
significant changes. That's one of my goals in the end.
00:03:05.341 --> 00:03:07.315
I should be able to do that.
00:03:07.316 --> 00:03:09.119
A lot of people invest significant
00:03:09.120 --> 00:03:12.717
time in their configs, and it's kind of disruptive
00:03:12.718 --> 00:03:14.300
if you want to change editors,
00:03:14.301 --> 00:03:16.500
not be able to use your Emacs Lisp
00:03:16.501 --> 00:03:21.646
config. And so I think a useful Emacs clone
00:03:21.647 --> 00:03:25.127
would be able to clone Emacs Lisp well enough
00:03:25.128 --> 00:03:29.799
that you can run your "init.el".
00:03:29.800 --> 00:03:33.879
And so overall, why am I doing this? It's just because I like
00:03:33.880 --> 00:03:37.999
the Scheme programming language. I love its simplicity and
00:03:38.000 --> 00:03:42.439
its power. It's an extremely well thought-out language.
00:03:42.440 --> 00:03:46.159
It's one of those languages where you can understand the
00:03:46.160 --> 00:03:48.739
entire language from top to bottom. You can read the entire
00:03:48.740 --> 00:03:52.879
specification and understand it yourself.
00:03:52.880 --> 00:03:57.239
It's like the computers I grew up with when I was a kid.
00:03:57.240 --> 00:03:59.319
They were all very simple computers
00:03:59.320 --> 00:04:02.559
in the late 80s, early 90s. And back then,
00:04:02.560 --> 00:04:05.579
theoretically, an engineer could understand the entire
00:04:05.580 --> 00:04:07.959
system at the software level all the way down to the circuit
00:04:07.960 --> 00:04:12.159
level. You can't do that nowadays. And so nowadays, my
00:04:12.160 --> 00:04:16.859
computer is not really a physical computer anymore. It's
00:04:16.860 --> 00:04:21.079
the Scheme language standard itself. That is the core of
00:04:21.080 --> 00:04:25.599
computation, of all of computation for me. And I would like
00:04:25.600 --> 00:04:30.579
to use it as more than just an academic curiosity. It was
00:04:30.580 --> 00:04:36.359
originally designed for teaching at MIT, but it's found use
00:04:36.360 --> 00:04:41.399
in industry. And the R7RS standard is still
00:04:41.400 --> 00:04:44.270
relatively new. It's over 10 years old at this point,
00:04:44.271 --> 00:04:47.999
but hasn't, I mean, the
00:04:48.000 --> 00:04:52.980
Scheme ecosystem itself is already fairly small.
00:04:52.981 --> 00:04:54.341
There still, I don't think,
00:04:54.342 --> 00:04:56.359
has been a whole lot of adoption of R7RS
00:04:56.360 --> 00:04:58.785
quite yet. Kind of a shame.
00:04:58.786 --> 00:05:01.119
So I'd like a project like this, a
00:05:01.120 --> 00:05:04.009
very large scale, kind of a killer-app-like project
00:05:04.010 --> 00:05:05.920
where you're developing a text editor
00:05:05.921 --> 00:05:09.060
and perhaps even an integrated development environment
00:05:09.061 --> 00:05:11.920
in Scheme, I think would be very useful
00:05:11.921 --> 00:05:13.799
just even as a study of, you know, what
00:05:13.800 --> 00:05:18.461
can this language do? And just overall,
00:05:18.462 --> 00:05:21.220
there seems to be a lot of interest in
00:05:21.221 --> 00:05:24.320
Guile-based Emacs and well, maybe a
00:05:24.321 --> 00:05:27.163
Scheme-based Emacs, but Guile in particular.
00:05:27.164 --> 00:05:28.220
There has been talk of
00:05:28.221 --> 00:05:33.660
changing Emacs Lisp or the core of the Emacs Lisp over to
00:05:33.661 --> 00:05:38.469
Guile for about 30 years or so,
00:05:38.470 --> 00:05:41.199
talks originally in the early
00:05:41.200 --> 00:05:44.799
mid 90s. There were discussions between Richard Stallman,
00:05:44.800 --> 00:05:49.919
Tom Lord, and Aubrey Jaffer. They considered
00:05:49.920 --> 00:05:53.219
actually replacing Emacs Lisp with Scheme.
00:05:53.220 --> 00:05:56.827
In 1999, and going for about 10 years,
00:05:56.828 --> 00:06:01.079
someone named Ken Raeburn actually started
00:06:01.080 --> 00:06:07.240
a project where he started writing Emacs in Guile.
00:06:07.241 --> 00:06:11.859
My project is very similar to this.
00:06:11.860 --> 00:06:15.120
Here's a quote from his webpage, which is still up, even
00:06:15.121 --> 00:06:18.399
though it hasn't been updated in 15 years.
00:06:18.400 --> 00:06:20.519
This project that I have started
00:06:20.520 --> 00:06:23.101
is for converting GNU Emacs to Guile
00:06:23.102 --> 00:06:24.121
as its programming language.
00:06:24.122 --> 00:06:26.082
Support for Emacs Lisp will continue to exist,
00:06:26.083 --> 00:06:27.760
of course, but it may be through
00:06:27.761 --> 00:06:29.244
translation and/or interpretation.
00:06:29.245 --> 00:06:30.339
The Lisp engine itself
00:06:30.340 --> 00:06:32.906
may no longer be the core of the program.
00:06:32.907 --> 00:06:38.538
And this is my goal as well. In 2010,
00:06:38.539 --> 00:06:41.879
Andy Wingo and Ludovic Courtes
00:06:41.880 --> 00:06:46.402
took maintainership of the Guile project.
00:06:46.403 --> 00:06:52.719
From 2009, so while Andy... 2009
00:06:52.720 --> 00:06:59.399
to 2011, the first Emacs Lisp interpreter was already being
00:06:59.400 --> 00:07:02.089
implemented in Guile. And even to this day,
00:07:02.090 --> 00:07:05.651
this Emacs Lisp interpreter ships with Guile.
00:07:05.652 --> 00:07:06.599
And so this was happening
00:07:06.600 --> 00:07:10.112
while Andy Wingo took control of the project.
00:07:10.113 --> 00:07:13.833
In 2011, so shortly after Andy Wingo
00:07:13.834 --> 00:07:15.119
took control of the project,
00:07:15.120 --> 00:07:22.279
Guile 2.0 was released. And also in 2011, in the summertime,
00:07:22.280 --> 00:07:27.279
someone named Robin Templeton, I believe it was a Google
00:07:27.280 --> 00:07:33.519
Summer of Code project, started actually trying to
00:07:33.520 --> 00:07:38.719
incorporate libguile, that's the guile interpreter, as a
00:07:38.720 --> 00:07:45.199
linkable or loadable library, linking it to the Emacs
00:07:45.200 --> 00:07:49.179
executable, and then providing some built-in functions in
00:07:49.180 --> 00:07:54.759
Emacs that allows you to call the scheme
00:07:54.760 --> 00:07:58.739
interpreter, the Guile Scheme interpreter, from Emacs.
00:07:58.740 --> 00:08:02.239
And so it's not like a wrapper around the REPL like Geiser or
00:08:02.240 --> 00:08:08.959
SLIME. It's actually the whole Scheme interpreter loaded
00:08:08.960 --> 00:08:13.939
into your Emacs process. And that means your Emacs will have
00:08:13.940 --> 00:08:20.079
the ability to actually load compiled Scheme programs and
00:08:20.080 --> 00:08:25.879
actually run them and share memory with Emacs Lisp
00:08:25.880 --> 00:08:29.799
processes. And, well, Robin Templeton will explain all of
00:08:29.800 --> 00:08:33.039
this. They're presenting today, and I'm very excited to
00:08:33.040 --> 00:08:37.079
actually see their presentation. They'll explain
00:08:37.080 --> 00:08:40.179
everything.
00:08:40.180 --> 00:08:45.679
So, let's see. Moving on. 2020, someone named Vasilij
00:08:45.680 --> 00:08:49.039
Schneidermann, I'm not sure how you pronounce that, published
00:08:49.040 --> 00:08:53.639
an overview called The State of Emacs Lisp on Guile. Let's see
00:08:53.640 --> 00:08:58.399
if I have that here. Yep, it's this page right here. He goes
00:08:58.400 --> 00:09:04.879
into detail about who has done what so far, and what can you do
00:09:04.880 --> 00:09:09.759
in Guile with Emacs Lisp so far, and so on. Like, what is the
00:09:09.760 --> 00:09:12.717
state of the project overall?
00:09:12.718 --> 00:09:15.899
And so (speak of the devil)
00:09:15.900 --> 00:09:20.960
(Andy Wingo on social media).
00:09:20.961 --> 00:09:24.339
So, 2020 to present. Guile Emacs
00:09:24.340 --> 00:09:32.071
is dead? So there's GCC Emacs now.
00:09:32.072 --> 00:09:35.752
Emacs Lisp now has its own JIT compiler.
00:09:35.753 --> 00:09:39.259
And it seems like over the past few years,
00:09:39.260 --> 00:09:44.319
Emacs Lisp has kind of moved off into the direction of
00:09:44.320 --> 00:09:48.439
becoming its own programming language in its own right,
00:09:48.440 --> 00:09:51.839
and it is decidedly Common Lisp-flavored. It is
00:09:51.840 --> 00:09:54.166
very similar to Common Lisp,
00:09:54.167 --> 00:09:56.519
and that seems to be the direction
00:09:56.520 --> 00:10:00.719
that it's headed now, and I don't know if there's really any
00:10:00.720 --> 00:10:05.559
interest anymore amongst the Emacs maintainers of
00:10:05.560 --> 00:10:09.799
continuing with a Guile-based Emacs.
00:10:09.800 --> 00:10:13.319
But as far as I know, there's still a lot of interest in the
00:10:13.320 --> 00:10:19.599
community amongst Scheme and Lisp and Emacs users who are
00:10:19.600 --> 00:10:24.779
interested in maybe continuing to try to get Guile to become
00:10:24.780 --> 00:10:28.079
the core of Emacs, or if not, you know, what Robin Templeton
00:10:28.080 --> 00:10:31.639
has been doing, at least trying to get Guile a
00:10:31.640 --> 00:10:37.279
language, a first class supported language in Emacs. So
00:10:37.280 --> 00:10:39.999
that's enough talking. Let me just show you what I have so
00:10:40.000 --> 00:10:45.239
far. The GUI is barely working, because I have very little
00:10:45.240 --> 00:10:50.039
experience with GTK or GObject Introspection. It's very
00:10:50.040 --> 00:10:53.639
difficult to debug, so it's very slow to develop. Any crash
00:10:53.640 --> 00:10:58.199
at C level produces no stack traces. So far, most of the
00:10:58.200 --> 00:11:03.199
crashes that I've experienced are due to simple mistakes
00:11:03.200 --> 00:11:09.399
like passing the wrong data type. So, so far, no, not a whole
00:11:09.400 --> 00:11:14.174
lot of need for GDB or rebuilding all GTK, glib,
00:11:14.175 --> 00:11:17.877
and so on with the debugging symbols.
00:11:17.878 --> 00:11:19.319
But yes, still development's been
00:11:19.320 --> 00:11:25.499
very slow. I'm learning as I go. I've chosen to use Guile GI as
00:11:25.500 --> 00:11:30.499
the foundation for the GUI. Let me just load it up quick here.
00:11:30.600 --> 00:11:39.899
"load main-guile.scm". And this will launch the GUI. I also
00:11:39.900 --> 00:11:44.199
happen to have a REPL that runs in a separate thread and
00:11:44.200 --> 00:11:49.759
submits any form that you type to be evaluated inside of the
00:11:49.760 --> 00:11:57.079
running GUI environment. But you can just type stuff. So
00:11:57.080 --> 00:12:02.903
"hello world." And of course there is...
00:12:02.904 --> 00:12:08.059
as you can see, it's not quite rendering correctly.
00:12:08.060 --> 00:12:11.090
This "*Messages*" thing here,
00:12:11.091 --> 00:12:13.760
that should be over here, obviously. I haven't been able to
00:12:13.761 --> 00:12:17.820
figure out how to get those little details down. But yeah,
00:12:17.821 --> 00:12:23.215
you can do M-:, and you get your eval,
00:12:23.216 --> 00:12:26.637
and you can just evaluate, like (what's an emacs,)
00:12:26.638 --> 00:12:29.280
(or what's a Scheme-specific thing?)
00:12:29.281 --> 00:12:37.679
Like "(import (srfi 1))", and
00:12:37.680 --> 00:12:44.888
let's see, do "(iota 20)", for example.
00:12:44.889 --> 00:12:46.780
And so that is the procedure
00:12:46.781 --> 00:12:52.900
that iterates and produces some 20 elements of a
00:12:52.901 --> 00:12:58.419
list. Or you can do something like, let's see,
00:12:58.420 --> 00:13:08.114
string-append "hello" with space "world".
00:13:08.115 --> 00:13:10.259
And you get the result and so on. And,
00:13:10.260 --> 00:13:13.039
you know, scheme allows you to return multiple values. So
00:13:13.040 --> 00:13:14.998
what I have done here is just
00:13:14.999 --> 00:13:17.979
every value is captured in a list
00:13:17.980 --> 00:13:21.001
and it prints all of the return values in the list.
00:13:21.002 --> 00:13:23.462
So if a procedure returns no values,
00:13:23.463 --> 00:13:26.144
you get an empty list.
00:13:26.145 --> 00:13:29.405
And that's that. It's still quite buggy.
00:13:29.406 --> 00:13:31.519
So like, here's a bug
00:13:31.520 --> 00:13:37.319
that I can reproduce fairly consistently.
00:13:37.320 --> 00:13:41.407
I can, yeah, if you do...
00:13:41.408 --> 00:13:46.199
there seems to be a problem with a
00:13:46.200 --> 00:13:49.719
widget being freed too soon, so it will crash. I'm going to
00:13:49.720 --> 00:13:53.319
try and solve that, hopefully, before this presentation
00:13:53.320 --> 00:13:57.109
goes live. Let's see here.
00:13:57.110 --> 00:13:59.839
The Emacs Lisp parser is based on
00:13:59.840 --> 00:14:04.399
Guile Emacs Lisp. So the Guile Emacs Lisp interpreter that
00:14:04.400 --> 00:14:09.039
ships with Guile, that is what I am using. I've actually
00:14:09.040 --> 00:14:15.719
copied and pasted the source code from the Guile source base
00:14:15.720 --> 00:14:20.639
into my own project so that I can iterate on it more quickly.
00:14:20.640 --> 00:14:25.799
And I've already had to make some modifications to the
00:14:25.800 --> 00:14:29.899
Emacs Lisp interpreter in Guile. So here's the evaluator.
00:14:29.900 --> 00:14:33.079
I've actually already modified the parser and the lexer a
00:14:33.080 --> 00:14:37.858
little bit. And it's at least able to parse
00:14:37.859 --> 00:14:43.149
all of the "subr.el" program, the Emacs Lisp program.
00:14:43.150 --> 00:14:44.599
It can actually load that, but not
00:14:44.600 --> 00:14:47.570
evaluate it, or parse it, but not evaluate it...
00:14:47.571 --> 00:14:51.719
Read, not eval.
00:14:51.720 --> 00:14:53.959
By the time this goes live, I will have submitted a patch
00:14:53.960 --> 00:14:57.559
upstream. And that's another goal of this project,
00:14:57.560 --> 00:15:01.199
incidentally, is that anything that we can contribute to
00:15:01.200 --> 00:15:08.359
Guile and any built-in functions that we can implement
00:15:08.360 --> 00:15:10.999
I would like to, for this project, I would like to try and
00:15:11.000 --> 00:15:15.679
contribute upstream to Guile. The Emacs Lisp interpreter
00:15:15.680 --> 00:15:21.359
is not working well, unfortunately. So this copy, this is
00:15:21.360 --> 00:15:29.479
the copy of the code base (from this commit in particular)
00:15:29.480 --> 00:15:34.979
and well, I can't get it working. I can't actually get the
00:15:34.980 --> 00:15:37.759
non-copy, the actual built-in version of
00:15:37.760 --> 00:15:41.211
the Emacs Lisp interpreter to work properly quite yet.
00:15:41.212 --> 00:15:47.033
So let me quick go to, (what is this here?)
00:15:47.034 --> 00:15:51.879
Guile Elisp. So suppose you have this
00:15:51.880 --> 00:15:55.999
"eval-elisp" procedure here and it takes
00:15:56.000 --> 00:16:00.639
an Elisp environment and then it evaluates an expression in that
00:16:00.640 --> 00:16:03.599
environment. And evaluates to a value. So this
00:16:03.600 --> 00:16:05.084
is the standard way of doing it in Guile.
00:16:05.085 --> 00:16:06.039
If you can see here,
00:16:06.040 --> 00:16:09.946
you've got this expression, "compile" expression.
00:16:09.947 --> 00:16:16.859
This is like "eval". And so actually trying to load this.
00:16:16.860 --> 00:16:24.672
So let's do "load gypsum". (Let's see here. This is, no),
00:16:24.673 --> 00:16:35.759
I wanted to "import gypsum backend guile Elisp".
00:16:35.760 --> 00:16:39.039
And if I actually want to do this... So elisp eval, first of all,
00:16:39.040 --> 00:16:42.879
it says it failed because there's an unbound variable
00:16:42.880 --> 00:16:45.348
"elisp-eval". Don't know what it's talking about.
00:16:45.349 --> 00:16:48.229
There's no such variable in any of my programs.
00:16:48.230 --> 00:16:51.151
I have no idea what's going on here.
00:16:51.152 --> 00:16:59.279
You can try to run eval elisp on some simple form like
00:16:59.280 --> 00:17:04.759
(+ 1 2). And it gives you this exception. This works.
00:17:04.760 --> 00:17:09.579
This is the same issue that I have with all of the,
00:17:09.580 --> 00:17:13.200
every version of the Emacs Lisp Interpreter in Guile.
00:17:13.201 --> 00:17:18.751
I can get it to work with this big ",L" mode.
00:17:18.752 --> 00:17:21.593
So I can actually do (+ 1 2) here.
00:17:21.594 --> 00:17:26.816
I can do "princ" like here.
00:17:26.817 --> 00:17:30.119
That all works fine. It gives me, for some reason,
00:17:30.120 --> 00:17:34.940
a stack trace here.
00:17:34.941 --> 00:17:43.926
And yeah, so it's a bit, it's not well-documented.
00:17:43.927 --> 00:17:45.887
The code base is fairly old.
00:17:45.888 --> 00:17:50.399
As I said, it was developed around 2011,
00:17:50.400 --> 00:17:53.239
and it's fairly opaque, and I have not been able to figure out
00:17:53.240 --> 00:17:57.959
how to get Emacs Lisp in Guile working smoothly. So I have
00:17:57.960 --> 00:18:04.539
started writing my own Emacs Lisp interpreter. And, uh,
00:18:04.540 --> 00:18:13.399
"gypsum/elisp/eval-tests.scm".
00:18:13.400 --> 00:18:18.269
It's, uh, not entirely ready.
00:18:18.270 --> 00:18:21.695
I can show you some of the tests at least.
00:18:21.696 --> 00:18:25.036
Here is a simple Emacs Lisp program
00:18:25.037 --> 00:18:25.856
that you can evaluate.
00:18:25.857 --> 00:18:31.139
You got "progn", "setq" a to 3, "setq" b to 5,
00:18:31.140 --> 00:18:35.839
"setq" c to the sum of a and b, return c.
00:18:35.840 --> 00:18:39.059
And this at least works correctly.
00:18:39.060 --> 00:18:43.279
As you can see here, the result is eight. Um, but
00:18:43.280 --> 00:18:46.520
the "let*" semantics are not completed yet.
00:18:46.521 --> 00:18:51.103
Lots of work left to do there.
00:18:51.104 --> 00:18:54.464
So in the time I have left, I guess I can just,
00:18:54.465 --> 00:18:56.759
talk a little bit about what my plans
00:18:56.760 --> 00:18:59.387
are for the future.
00:18:59.388 --> 00:19:02.599
I would like to begin by evaluating or
00:19:02.600 --> 00:19:06.759
actually loading the "subr.el" into my Emacs Lisp
00:19:06.760 --> 00:19:09.639
interpreter. I actually have tests set up for that as well,
00:19:09.640 --> 00:19:15.909
so I can actually select any form I want from "subr.el".
00:19:15.910 --> 00:19:18.832
I can just run this through my interpreter
00:19:18.833 --> 00:19:21.593
and test to see if everything is working
00:19:21.594 --> 00:19:28.779
once I get that far.
00:19:28.780 --> 00:19:33.239
And yeah, let me just say that this is my formal appeal to the
00:19:33.240 --> 00:19:37.799
community for help on this project. Emacs Lisp has
00:19:37.800 --> 00:19:41.179
1,393 built-in functions.
00:19:41.180 --> 00:19:45.039
I could never implement that many functions on my own, so if
00:19:45.040 --> 00:19:47.599
this project is going to be useful to anybody in any
00:19:47.600 --> 00:19:51.114
reasonable amount of time, I'm going to need help.
00:19:51.115 --> 00:19:53.476
And I know that there are people out there
00:19:53.477 --> 00:19:56.398
who are very interested in a Guile-based Emacs,
00:19:56.399 --> 00:19:58.999
and so if you're watching this,
00:19:59.000 --> 00:20:00.521
please feel free to contact me
00:20:00.522 --> 00:20:05.699
on social media or over e-mail.
00:20:05.700 --> 00:20:09.647
My job, the way I see it, is if there's enough interest,
00:20:09.648 --> 00:20:12.064
and I do get a lot of people interested in
00:20:12.065 --> 00:20:13.199
starting to contribute,
00:20:13.200 --> 00:20:17.919
my job will be to document the building and testing process
00:20:17.920 --> 00:20:21.039
and make sure that it is as easy as possible to contribute
00:20:21.040 --> 00:20:24.079
code to this project. I want to document the system
00:20:24.080 --> 00:20:27.599
architecture. I'll write blog posts. I'll do videos on
00:20:27.600 --> 00:20:31.879
PeerTube explaining how everything works. And I will
00:20:31.880 --> 00:20:34.199
prioritize which built-in functions
00:20:34.200 --> 00:20:36.462
I think are probably going to be the most necessary,
00:20:36.463 --> 00:20:40.878
the most essential to get the interpreter running,
00:20:40.879 --> 00:20:42.559
and then find low-hanging fruit,
00:20:42.560 --> 00:20:46.519
functions that are easy for people to implement
00:20:46.520 --> 00:20:50.845
as a good introduction to getting them started
00:20:50.846 --> 00:20:53.947
on contributing to the project.
00:20:53.948 --> 00:20:56.679
And then, of course, I will take
00:20:56.680 --> 00:21:01.719
responsibility myself of making sure that we can
00:21:01.720 --> 00:21:03.774
get the Elisp interpreter to the point
00:21:03.775 --> 00:21:09.079
where it can run the Emacs regression tests.
00:21:09.080 --> 00:21:13.333
These are the test suites that are used
00:21:13.334 --> 00:21:20.359
to test Emacs Lisp itself in the GNU Emacs code base. And so
00:21:20.360 --> 00:21:24.559
ERT is itself written in Emacs Lisp. And so
00:21:24.560 --> 00:21:27.033
I think if we implement enough of the built-in functions
00:21:27.034 --> 00:21:29.933
to be able to run ERT,
00:21:29.934 --> 00:21:31.195
then we can actually start
00:21:31.196 --> 00:21:33.617
using the GNU Emacs regression tests
00:21:33.618 --> 00:21:39.248
to test our own interpreter, our own Emacs clone.
00:21:39.249 --> 00:21:41.199
And of course, I'll make sure that there's at least
00:21:41.200 --> 00:21:45.833
one usable GUI. I'm currently working on Guile GI
00:21:45.834 --> 00:21:51.396
and GTK. It would be great to have an...
00:21:51.397 --> 00:21:53.879
ANSI terminal based...
00:21:53.880 --> 00:21:58.219
something that works in your terminal emulator.
00:21:58.220 --> 00:22:00.283
And yeah, it would be great if someday soon,
00:22:00.284 --> 00:22:03.159
hopefully, we get enough done
00:22:03.160 --> 00:22:06.094
that you can actually contribute a patch to this project
00:22:06.095 --> 00:22:11.778
from within the Gypsum editor itself.
00:22:11.779 --> 00:22:13.380
I was going to do an overview,
00:22:13.381 --> 00:22:19.679
but that would be for more of an hour-long presentation.
00:22:19.680 --> 00:22:22.927
So I'm out of time. I guess the last thing
00:22:22.928 --> 00:22:25.449
I should quickly say is there's no
00:22:25.450 --> 00:22:27.159
meta object protocol in this
00:22:27.160 --> 00:22:29.001
project. I think that's a little bit too difficult
00:22:29.002 --> 00:22:30.962
to port to various scheme implementations.
00:22:30.963 --> 00:22:33.739
So I've created a substitute, which I'm
00:22:33.740 --> 00:22:36.959
calling "functional lenses", which is inspired by the
00:22:36.960 --> 00:22:42.059
Haskell project of the same name.
00:22:42.060 --> 00:22:47.511
Everything in this project is based on functional lenses.
00:22:47.512 --> 00:22:52.603
Yeah, also a lot a work went into the keymaps data structure.
00:22:52.604 --> 00:22:55.206
The point being that I think I have
00:22:55.207 --> 00:22:58.589
a pretty good foundation here upon which we can build,
00:22:58.590 --> 00:23:00.839
even though there isn't an actual, there isn't
00:23:00.840 --> 00:23:04.699
a lot done in the actual prototype itself, not yet anyway,
00:23:04.700 --> 00:23:08.419
but I made sure to get the fundamentals down
00:23:08.420 --> 00:23:11.080
from the beginning. And so I think we have something
00:23:11.081 --> 00:23:16.308
like a solid foundation on which to build.
00:23:16.309 --> 00:23:21.230
So, I'm going to conclude it there.
00:23:21.231 --> 00:23:24.599
And here's my contact details. Like I said,
00:23:24.600 --> 00:23:29.319
this is a project, I'm appealing to the community of all
00:23:29.320 --> 00:23:31.899
people who are interested in Guile and Emacs to help
00:23:31.900 --> 00:23:35.839
contribute to this project. I see myself as just getting the
00:23:35.840 --> 00:23:40.600
ball rolling. Again, taking-off from the work
00:23:40.601 --> 00:23:46.278
that Ken Raeburn left behind, with my own
00:23:46.279 --> 00:23:50.637
from-the-ground-up implementation. So yeah,
00:23:50.638 --> 00:23:53.858
contact me: e-mail, you can take a look at my blog
00:23:53.859 --> 00:23:57.419
where I talk about what I have done.
00:23:57.420 --> 00:24:00.759
My source code, the code for this project, is up on
00:24:00.760 --> 00:24:06.139
Codeberg... The presentation... this
00:24:06.140 --> 00:24:09.379
presentation, the home page for this presentation, you
00:24:09.380 --> 00:24:15.559
can find more details there. Oh, I'm on
00:24:15.560 --> 00:24:19.139
ActivityPub as well, so my handle is
00:24:19.140 --> 00:24:27.119
@ramin_hal9001@fe.disroot.org, and I'm on everyday.
00:24:27.120 --> 00:24:30.939
So yeah, please feel free to contact me if you're interested,
00:24:30.940 --> 00:24:35.640
and thank you for your attention.
