summaryrefslogtreecommitdiffstats
path: root/2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--...
diff options
context:
space:
mode:
authorSacha Chua <sacha@sachachua.com>2024-12-24 10:31:26 -0500
committerSacha Chua <sacha@sachachua.com>2024-12-24 10:31:26 -0500
commit436f702956aad327f9039ae842d7c524ec4cbf72 (patch)
tree0784155569dfc98374ff863490ee0ce490250920 /2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt
parent82f130314ca10bd1e8fad7eb628b8c4e7aceb510 (diff)
downloademacsconf-wiki-436f702956aad327f9039ae842d7c524ec4cbf72.tar.xz
emacsconf-wiki-436f702956aad327f9039ae842d7c524ec4cbf72.zip
add YouTube URLs, Q&A video URLsHEADmaster
Diffstat (limited to '2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt')
-rw-r--r--2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt474
1 files changed, 237 insertions, 237 deletions
diff --git a/2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt b/2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt
index 0142a879..7c2708d9 100644
--- a/2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt
+++ b/2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt
@@ -1,725 +1,725 @@
WEBVTT
-00:00.069 --> 00:01.850
-Troy Hinckley's project that I'm talking about. I was going
+00:00:00.000 --> 00:00:02.999
+...Troy Hinckley's project that I'm talking about. I was going
-00:02.350 --> 00:22.139
+00:00:03.000 --> 00:00:08.799
to mention this in my presentation, but it's possible,
-00:02.350 --> 00:22.139
+00:00:08.800 --> 00:00:16.359
theoretically, that Troy Hinckley, his project could be
-00:02.350 --> 00:22.139
+00:00:16.360 --> 00:00:18.559
used as a scheme of limitation that actually runs my own
-00:02.350 --> 00:22.139
+00:00:18.560 --> 00:00:23.759
version of Emacs. And although, you know, This is
-00:25.478 --> 00:29.380
+00:00:23.760 --> 00:00:30.719
completely theoretical, and I don't know how difficult
-00:25.478 --> 00:29.380
+00:00:30.720 --> 00:00:34.079
that would be. But if Troy Hinckley implemented enough of
-00:30.781 --> 00:47.029
+00:00:34.080 --> 00:00:39.879
the R7-RS standard in Rust, it would theoretically be
-00:30.781 --> 00:47.029
+00:00:39.880 --> 00:00:46.719
possible to run the Gypsum editor in Troy Hinckley's own
-00:30.781 --> 00:47.029
+00:00:46.720 --> 00:00:50.239
editor. I thought that was kind of interesting, and I
-00:48.270 --> 00:53.833
+00:00:50.240 --> 00:00:59.119
thought it was worth mentioning, at least in the questions
-00:48.270 --> 00:53.833
+00:00:59.120 --> 00:01:12.159
and answers.
-01:12.179 --> 01:14.080
+00:01:12.160 --> 00:01:16.199
I also mentioned this in the presentation. I wanted to see
-01:14.940 --> 01:22.364
+00:01:16.200 --> 00:01:20.119
Robin Templeton's project presentation, but
-01:14.940 --> 01:22.364
+00:01:20.120 --> 00:01:22.399
unfortunately it's going to be at like four in the morning
-01:14.940 --> 01:22.364
+00:01:22.400 --> 00:01:26.239
for me. So I'm going to try and watch that tomorrow, but
-01:22.984 --> 01:31.428
+00:01:26.240 --> 00:01:29.559
that's also going to be a very interesting project to keep an
-01:22.984 --> 01:31.428
+00:01:29.560 --> 00:01:34.039
eye on if you're interested in Scheme. That's the project
-01:33.149 --> 01:38.051
+00:01:34.040 --> 00:01:37.519
where you've got the Guylain interpreter running inside of
-01:33.149 --> 01:38.051
+00:01:37.520 --> 00:02:04.679
the Emacs process. It's dynamically linked as a library.
-02:04.699 --> 02:06.748
+00:02:04.680 --> 00:02:08.759
I'm ready for questions from anybody. You can ask or you can
-02:07.431 --> 02:09.079
+00:02:08.760 --> 00:02:32.079
type. It's up to you.
-02:32.319 --> 02:34.521
+00:02:32.080 --> 00:02:37.319
Okay, let me check the etherpad.
-02:37.304 --> 02:38.245
+00:02:37.320 --> 00:02:41.159
Let's see here.
-02:41.208 --> 02:42.830
+00:02:41.160 --> 00:02:42.719
I'm not sure if I'm doing that right.
-02:46.373 --> 02:47.554
+00:02:42.720 --> 00:02:54.199
Let me check one more time. Oh, there it goes.
-02:54.221 --> 02:55.702
+00:02:54.200 --> 00:03:00.079
Let's see, so this is...
-03:00.151 --> 03:02.072
+00:03:00.080 --> 00:03:02.239
I didn't know about that first bit of history. Oh, I've heard
-03:02.332 --> 00:03:09.369
+00:03:02.240 --> 00:03:06.119
RMS say that Scheme Guile is just a nicer Lisp, but I didn't
-03:02.332 --> 03:09.776
+00:03:06.120 --> 00:03:09.079
know there were concrete talks attempts to use Guile for
-03:02.332 --> 03:09.776
+00:03:09.080 --> 00:03:14.319
Emacs that early. Let's see, that was from janneke.
NOTE Q: I'm curious to know how the hell guile-emacs deals with all of the dynamically scoped modules out there. Is there any effort to automatically modularize and namespace stuff?
-00:03:09.370 --> 00:03:19.241
+00:03:14.320 --> 00:03:17.439
I'm curious to know how the hell Guile Emacs deals with all the
-03:14.318 --> 03:19.241
+00:03:17.440 --> 00:03:21.359
dynamically scoped modules out there. Is there any effort
-03:20.181 --> 03:24.943
+00:03:21.360 --> 00:03:29.759
to automatically modularize and name? Let's see.
-03:30.523 --> 03:35.806
+00:03:29.760 --> 00:03:40.919
That might be a better question for Robin Templeton. In my
-03:36.727 --> 03:46.573
+00:03:40.920 --> 00:03:44.639
own project,
-03:36.727 --> 03:46.573
+00:03:44.640 --> 00:03:49.399
there's no module system for Emacs Lisp. There is a module
-03:46.693 --> 03:48.234
+00:03:49.400 --> 00:03:55.559
system for Scheme. And the Emacs Lisp interpreter runs in
-03:49.695 --> 03:55.158
+00:03:55.560 --> 00:04:01.599
its own environment. the require system or whatever module
-03:57.068 --> 04:11.736
+00:04:01.600 --> 00:04:06.359
system that Emacs has, once it's implemented, all of that
-03:57.068 --> 04:11.736
+00:04:06.360 --> 00:04:09.759
would just happen inside of the Emacs Lisp environment,
-03:57.068 --> 04:11.736
+00:04:09.760 --> 00:04:12.399
which is inside of the Scheme environment. And
-04:12.437 --> 04:15.898
+00:04:12.400 --> 00:04:21.479
environments are objects in Scheme.
-04:21.522 --> 04:24.103
+00:04:21.480 --> 00:04:26.399
I think a more difficult question is how to handle
-04:26.420 --> 04:31.942
+00:04:26.400 --> 00:04:33.279
threading, and Scheme has very good threading built in, in
-04:26.420 --> 04:31.942
+00:04:33.280 --> 00:04:34.839
Serphe-18[??].
-04:34.283 --> 04:48.028
+00:04:34.840 --> 00:04:43.399
But I don't think it will be easy to write Emacs Lisp form
-04:34.283 --> 04:48.028
+00:04:43.400 --> 00:04:48.479
bindings to the Scheme multi-threading implementation.
-04:48.548 --> 04:50.749
+00:04:48.480 --> 00:04:52.279
Emacs Lisp was just not cut out for that kind of thing. So I
-04:51.710 --> 04:59.894
+00:04:52.280 --> 00:04:56.559
think each Emacs Lisp, you could, I suppose, have multiple
-04:51.710 --> 04:59.894
+00:04:56.560 --> 00:05:00.039
threads each running their own Emacs Lisp environment.
-05:01.375 --> 05:02.956
+00:05:00.040 --> 00:05:04.999
Scheme would make that very simple to do.
-05:06.018 --> 05:16.744
+00:05:05.000 --> 00:05:08.759
And then there'd just be a question of how you would get those
-05:06.018 --> 05:16.744
+00:05:08.760 --> 00:05:11.679
different interpreters to communicate with each other,
-05:06.018 --> 05:16.744
+00:05:11.680 --> 00:05:16.279
perhaps using the same protocol that's used by the Emacs
-05:06.018 --> 05:16.744
+00:05:16.280 --> 00:05:23.639
server. But I haven't thought that far ahead yet.
NOTE Q: Would it be possible to support a GUI toolkit other than GTK?
-05:23.646 --> 05:28.709
+00:05:23.640 --> 00:05:26.839
Would it be possible to support a GUI toolkit other than the
-05:23.646 --> 05:28.709
+00:05:26.840 --> 00:05:31.319
GTK? Like, how is it still supports Lucid? Yes, this is
-05:31.291 --> 05:33.232
+00:05:31.320 --> 00:05:36.999
absolutely a goal of the project. I'm trying to keep the back
-05:33.873 --> 05:38.416
+00:05:37.000 --> 00:05:41.599
end separate as possible. The scheme has what you call
-05:39.817 --> 05:42.478
+00:05:41.600 --> 00:05:45.239
parameters. And these are like global variables that are
-05:43.199 --> 05:46.221
+00:05:45.240 --> 00:05:50.519
still somewhat thread safe. And every call to the GUI goes
-05:47.484 --> 05:51.225
+00:05:50.520 --> 00:05:58.199
through a parameter. So the Emacs, the interpreter and the
-05:52.125 --> 05:59.367
+00:05:58.200 --> 00:06:01.679
editor logic is all in one module. And then that module calls
-05:59.987 --> 06:04.309
+00:06:01.680 --> 00:06:06.319
out into a separate GUI module. And then you can implement
-06:04.989 --> 06:07.690
+00:06:06.320 --> 00:06:11.599
different GUI modules. So you could have one for GTK3, one
-06:08.430 --> 06:13.171
+00:06:11.600 --> 00:06:16.879
for GTK4, if you want to write the extern C bindings around Qt
-06:13.843 --> 06:20.725
+00:06:16.880 --> 00:06:21.199
or full tick, that would certainly be possible as well. It
-06:21.185 --> 06:32.168
+00:06:21.200 --> 00:06:25.919
would be nice maybe to have an SDL implementation based
-06:21.185 --> 06:32.168
+00:06:25.920 --> 00:06:30.999
maybe on Chikiti or some kind of immediate mode GUI,
-06:21.185 --> 06:32.168
+00:06:31.000 --> 00:06:37.399
something like that. But definitely GTK3 through Guile GI
-06:33.808 --> 06:38.750
+00:06:37.400 --> 00:06:41.319
is the reference implementation. Things start there. But
-06:41.298 --> 06:43.959
+00:06:41.320 --> 00:06:43.999
I'm very interested in supporting other GUIs, yes. Let's
-06:45.199 --> 00:06:45.256
+00:06:44.000 --> 00:06:46.039
see.
NOTE Q: Do you plan to provide improvements to Elisp as a language, or is the focus on a compatibility layer to facilitate doing all new extensions, etc. in Scheme?
-00:06:45.257 --> 00:06:45.879
+00:06:46.040 --> 00:06:50.759
Question, do you plan to provide improvements to ELisp
-06:47.540 --> 06:56.342
+00:06:50.760 --> 00:06:54.519
as a language or focus on a compatibility layer to
-06:47.540 --> 06:56.342
+00:06:54.520 --> 00:06:57.999
facilitate all new extensions in Scheme? Yeah, the second
-06:57.142 --> 06:57.962
+00:06:58.000 --> 00:07:04.719
one. I want to move off to Scheme. I would like for this
-07:03.384 --> 07:05.264
+00:07:04.720 --> 00:07:08.999
project to try and keep up to date with each new release of
-07:05.666 --> 07:10.789
+00:07:09.000 --> 00:07:13.799
Emacs and Emacs Lisp. That's a difficult moving target to
-07:11.850 --> 07:14.552
+00:07:13.800 --> 00:07:18.639
follow, I realize. But to the greatest extent possible, any
-07:15.152 --> 07:23.397
+00:07:18.640 --> 00:07:25.239
new features to Emacs Lisp will be pulled in from GNU Emacs.
-07:25.419 --> 07:29.041
+00:07:25.240 --> 00:07:28.599
If we happen to be able to implement something cool in
-07:25.419 --> 07:29.041
+00:07:28.600 --> 00:07:31.639
Scheme, and be able to port it over to Emacs Lisp, then sure,
-07:29.437 --> 07:36.543
+00:07:31.640 --> 00:07:35.799
it'd be nice to be able to upload or to submit that upstream to
-07:29.437 --> 07:36.543
+00:07:35.800 --> 00:07:43.079
the GNU Emacs. But I think I would prefer to have new features
-07:38.584 --> 07:43.708
+00:07:43.080 --> 00:07:47.799
written in Scheme. I would like this gypsum to be more of a
-07:43.989 --> 07:52.075
+00:07:47.800 --> 00:07:51.479
Scheme app platform that just happens to be able to also run
-07:43.989 --> 07:52.075
+00:07:51.480 --> 00:07:56.199
Emacs Lisp. That's how I see it. Of course, this will be a
-07:54.577 --> 07:56.699
+00:07:56.200 --> 00:08:00.799
community project. I'm open to debate about that if anybody
-07:58.809 --> 08:02.012
+00:08:00.800 --> 00:08:02.079
wants to convince me otherwise.
-08:08.439 --> 08:11.683
+00:08:02.080 --> 00:08:11.759
Why is being able to interpret all of that EL a useful goal?
-08:12.464 --> 08:14.626
+00:08:11.760 --> 00:08:15.519
Sure, there is a lot of code written in Elisp. Can we
-08:15.206 --> 08:17.749
+00:08:15.520 --> 00:08:18.959
consider... Oh, it's still being written. Please go ahead
-08:18.390 --> 08:19.491
+00:08:18.960 --> 00:08:19.439
and finish writing.
NOTE Q: Can we consider a translator like utility to convert elisp to scheme, once guile-emacs becomes a reality?
-08:29.673 --> 08:35.576
+00:08:19.440 --> 00:08:32.519
Can we consider a translator like utility to convert eLisp
-08:29.673 --> 08:35.576
+00:08:32.520 --> 00:08:37.519
to Scheme once Guile-Emacs has become a reality?
-08:36.716 --> 08:37.076
+00:08:37.520 --> 00:08:42.119
Certainly. For the time being, I just wanted to get the
-08:38.717 --> 08:42.639
+00:08:42.120 --> 00:08:47.559
interpreter running. So the actual, the Guile-Emacs Lisp,
-08:44.520 --> 08:58.666
+00:08:47.560 --> 00:08:51.919
the one that was written in 2011 that I didn't write, that
-08:44.520 --> 08:58.666
+00:08:51.920 --> 00:08:57.599
actually does compile to, I think it's the tree
-08:44.520 --> 08:58.666
+00:08:57.600 --> 00:08:59.239
intermediate representation It's one of the intermediate
-08:59.076 --> 09:03.697
+00:08:59.240 --> 00:09:03.759
languages that Guile uses to compile Guile scheme itself.
-09:04.817 --> 09:09.299
+00:09:03.760 --> 00:09:09.079
So the Emacs lisp that was written before actually does
-09:04.817 --> 09:09.299
+00:09:09.080 --> 00:09:13.119
that. It actually compiles and makes use of the entire Guile
-09:09.339 --> 09:20.761
+00:09:13.120 --> 00:09:17.479
compiler tool chain and actually produces like JIT
-09:09.339 --> 09:20.761
+00:09:17.480 --> 00:09:21.719
compilable binaries, which is really cool. Like I said,
-09:23.342 --> 09:25.943
+00:09:21.720 --> 00:09:27.519
that's the one that I had trouble getting to work properly.
-09:29.209 --> 09:30.890
+00:09:27.520 --> 00:09:34.399
Maybe we can follow that architecture. I'm not sure how to do
-09:33.052 --> 09:45.102
+00:09:34.400 --> 00:09:37.919
that, but I would like to be able to do some kind of
-09:33.052 --> 09:45.102
+00:09:37.920 --> 00:09:41.999
translating, keeping in mind that we want to have this be
-09:33.052 --> 09:45.102
+00:09:42.000 --> 00:09:48.919
portable, do various schemes. And so Guile makes this very
-09:45.988 --> 09:50.289
+00:09:48.920 --> 00:09:52.719
easy, but other schemes don't. Gambit might do this pretty
-09:51.549 --> 09:53.530
+00:09:52.720 --> 00:09:57.919
well as well. It compiles to C and then compiles C down to a
-09:53.950 --> 10:01.471
+00:09:57.920 --> 00:10:06.159
dynamically linkable library. So yeah, I think probably
-10:03.372 --> 10:09.373
+00:10:06.160 --> 00:10:09.559
the most portable, I'm just thinking out loud right now,
-10:10.652 --> 10:21.715
+00:10:09.560 --> 00:10:13.239
most portable implementation will just be able to
-10:10.652 --> 10:21.715
+00:10:13.240 --> 00:10:17.119
translate Emacs Lisp directly to Scheme, which is not what
-10:10.652 --> 10:21.715
+00:10:17.120 --> 00:10:22.439
the old Guile Emacs Lisp implementation does. That goes to
-10:21.755 --> 10:26.777
+00:10:22.440 --> 00:10:26.439
TreeIL, so it's very, very Guile-specific, can't be
-10:21.755 --> 10:26.777
+00:10:26.440 --> 00:10:30.799
ported. But yeah, if we could somehow get Emacs Lisp
-10:28.359 --> 10:42.045
+00:10:30.800 --> 00:10:36.999
translated to Scheme and then compiled, say, in Shea Scheme
-10:28.359 --> 10:42.045
+00:10:37.000 --> 00:10:40.879
or Gambit or MIT Scheme or one of those other compilers, that
-10:28.359 --> 10:42.045
+00:10:40.880 --> 00:10:44.919
would be very cool. And I would absolutely love to do that.
-10:44.906 --> 10:49.948
+00:10:44.920 --> 00:10:49.279
And I would very quickly accept any code into the code base
-10:44.906 --> 10:49.948
+00:10:49.280 --> 00:10:50.599
that would do that.
NOTE Q: Why is being able to interpret all of \`init.el\` an useful goal?
-10:54.390 --> 10:56.291
+00:10:50.600 --> 00:10:59.119
Oh, and to answer the question about init.el,
-10:59.207 --> 11:17.215
+00:10:59.120 --> 00:11:02.839
It's just because people spend a lot of time on their configs
-10:59.207 --> 11:17.215
+00:11:02.840 --> 00:11:06.959
and it would be nice if, you know, you're starting to use this
-10:59.207 --> 11:17.215
+00:11:06.960 --> 00:11:14.079
new editor and want it to be similar to Emacs users, just the
-10:59.207 --> 11:17.215
+00:11:14.080 --> 00:11:16.519
Emacs community in general and people who are familiar with
-10:59.207 --> 11:17.215
+00:11:16.520 --> 00:11:20.879
using Emacs. It would be more useful to everybody in the
-11:17.715 --> 11:25.379
+00:11:20.880 --> 00:11:25.119
Emacs community if this were more compatible with GNU
-11:17.715 --> 11:25.379
+00:11:25.120 --> 00:11:35.999
Emacs. And so that's why that's, I think that's an important
-11:25.679 --> 11:27.960
+00:11:36.000 --> 00:11:38.559
goal.
-11:34.465 --> 11:35.467
+00:11:38.560 --> 00:12:01.839
Question is not yet. Great. Oh, here comes another
-11:38.471 --> 11:39.613
+00:12:01.840 --> 00:12:02.279
question.
NOTE Q: What is the plan to handle elisp packages that depend on 3rd party/external libraries? (libgit/magit or rg/ripgrep)?
-12:08.539 --> 12:17.742
+00:12:02.280 --> 00:12:11.879
Okay, what is the plan to handle elisp packages that depend
-12:08.539 --> 12:17.742
+00:12:11.880 --> 00:12:16.119
on third-party or external libraries like git or magit
-12:08.539 --> 12:17.742
+00:12:16.120 --> 00:12:22.719
or ripgrep? So that's going to be tricky. It depends on how
-12:21.523 --> 12:26.224
+00:12:22.720 --> 00:12:27.079
these external packages are linked into emacs. If it's
-12:26.844 --> 12:33.646
+00:12:27.080 --> 00:12:32.879
going to be a dynamic library like Robin Templeton's
-12:26.844 --> 12:33.646
+00:12:32.880 --> 00:12:38.039
project which you load the libgit library into the Emacs
-12:35.289 --> 12:41.931
+00:12:38.040 --> 00:12:43.159
process, that is going to be extremely difficult. So if you
-12:44.032 --> 12:52.975
+00:12:43.160 --> 00:12:49.359
have an external library like, I don't know, libgit or
-12:44.032 --> 12:52.975
+00:12:49.360 --> 00:12:59.279
what's the GUI thing? Cabal. No, not Cabal. Cairo, libcairo
-12:57.736 --> 13:01.398
+00:12:59.280 --> 00:13:01.439
to do SVG graphics and so on.
-13:04.483 --> 13:17.480
+00:13:01.440 --> 00:13:09.719
You can do that very easily with Guile, but then on top of
-13:04.483 --> 13:17.480
+00:13:09.720 --> 00:13:14.719
that, implementing Emacs list bindings to it, I mean,
-13:04.483 --> 13:17.480
+00:13:14.720 --> 00:13:17.199
you've got two layers there, and that makes things pretty
-13:04.483 --> 13:17.480
+00:13:17.200 --> 00:13:23.119
difficult. So it's possible. And to some degree, maybe
-13:21.935 --> 13:30.842
+00:13:23.120 --> 00:13:27.799
necessary for example, Cairo, if we want to do SVG graphics
-13:21.935 --> 13:30.842
+00:13:27.800 --> 00:13:30.599
the way that Emacs Lisp does, we're going to have to have
-13:21.935 --> 13:30.842
+00:13:30.600 --> 00:13:33.959
that. So that would be necessary. We would have to have those
-13:32.643 --> 13:33.944
+00:13:33.960 --> 00:13:39.199
two layers. Yes, let's do that. But if it's like for Magit,
-13:38.047 --> 13:50.596
+00:13:39.200 --> 00:13:45.479
you can just call out to your git process, and then you're
-13:38.047 --> 13:50.596
+00:13:45.480 --> 00:13:50.719
just using the regular process APIs that Emacs Lisp has. And
-13:51.451 --> 13:58.475
+00:13:50.720 --> 00:13:57.119
that can be, already we, like Guile has some very good
-13:51.451 --> 13:58.475
+00:13:57.120 --> 00:14:08.079
implementations for process management. And so it would
-13:59.055 --> 14:05.438
+00:14:08.080 --> 00:14:12.439
just be a matter of wrapping up those in the Emacs lisp form
-13:59.055 --> 14:05.438
+00:14:12.440 --> 00:14:24.919
bindings. So yeah, dynamic libraries, I wanna try to avoid.
-14:12.222 --> 14:20.366
+00:14:24.920 --> 00:14:32.799
And I would prefer to do things more through, you know,
-14:12.222 --> 14:20.366
+00:14:32.800 --> 00:14:40.399
launching a child process in the Emacs process. and then
-14:20.956 --> 14:24.798
+00:14:40.400 --> 00:14:47.239
communicating over the standard in, standard out
-14:20.956 --> 14:24.798
+00:14:47.240 --> 00:14:47.959
channels.
-14:29.460 --> 14:40.386
+00:14:47.960 --> 00:14:52.799
That's the easier way to do things, I think, because then you
-14:29.460 --> 14:40.386
+00:14:52.800 --> 00:14:58.519
can just use the process library that Emacs already has, and
-14:29.460 --> 14:40.386
+00:14:58.520 --> 00:15:03.239
you can just reuse all of that code.
-14:43.969 --> 14:49.912
+00:15:03.240 --> 00:15:09.079
I'm not sure how ripgrep works, unfortunately, but I
-14:43.969 --> 14:49.912
+00:15:09.080 --> 00:15:15.279
believe that's also a process, a child process. So, we can
-14:50.412 --> 14:53.774
+00:15:15.280 --> 00:15:23.479
just reuse all of the Emacs Lisp code that does that already.
-14:54.014 --> 15:05.979
+00:15:23.480 --> 00:15:30.399
We just need to make sure that the process management
-14:54.014 --> 15:05.979
+00:15:30.400 --> 00:15:35.119
implementation and scheme is properly bound to Emacs Lisp,
-14:54.014 --> 15:05.979
+00:15:35.120 --> 00:15:43.359
and it works the same as GNU Emacs does. Once that's all set,
-15:06.360 --> 15:13.383
+00:15:43.360 --> 00:15:48.399
then these porcelains, like around git, should fall into
-15:06.360 --> 15:13.383
+00:15:48.400 --> 00:15:55.279
place. without too much difficulty, hopefully.
NOTE Q: Not really a question, but how about Schemacs as a name?
-15:21.112 --> 15:22.593
+00:15:55.280 --> 00:15:59.199
How about Schemax as a name? I like the name. I like that name.
-15:28.937 --> 15:32.920
+00:15:59.200 --> 00:16:03.119
I haven't really looked into like, is that already used or is
-15:28.937 --> 15:32.920
+00:16:03.120 --> 00:16:09.759
that going to be confusing? But certainly something we can
-15:33.380 --> 15:35.021
+00:16:09.760 --> 00:16:10.959
discuss.
-15:38.243 --> 15:39.264
+00:16:10.960 --> 00:16:13.039
Another thing I should mention,
-15:42.157 --> 15:48.278
+00:16:13.040 --> 00:16:18.759
I should probably set up a server or something like Discord
-15:42.157 --> 15:48.278
+00:16:18.760 --> 00:16:25.359
or something like that. Discourse, not Discord.
-15:51.619 --> 15:56.220
+00:16:25.360 --> 00:16:31.599
Discourse, the open source one, where we could actually
-15:51.619 --> 15:56.220
+00:16:31.600 --> 00:16:49.239
chat about this stuff. For the time being, ActivityPub,
-15:56.540 --> 16:05.562
+00:16:49.240 --> 00:16:52.399
mostly Mastodon, is how I communicate with people in real
-15:56.540 --> 16:05.562
+00:16:52.400 --> 00:16:57.279
time, that or email. So if you want to get a hold of me, check
-16:09.809 --> 16:15.571
+00:16:57.280 --> 00:17:02.439
the notes for this presentation and just send me an email.
-16:16.752 --> 16:18.012
+00:17:02.440 --> 00:17:09.039
Any question at all is fine. If you want to contribute code,
-16:19.633 --> 16:25.495
+00:17:09.040 --> 00:17:12.799
if you want to just learn how to contribute code, send me any
-16:19.633 --> 16:25.495
+00:17:12.800 --> 00:17:22.199
questions. It's fine. I'm happy to answer them. And we can
-16:30.256 --> 16:31.757
+00:17:22.200 --> 00:17:25.879
talk about the name as well.
NOTE Q: Why is it not feasible for the Emacs layer that interprets Emacs Lisp (the core in C) ot have a Scheme interpreter, instead of using Guile?
-16:45.931 --> 16:54.215
+00:17:25.880 --> 00:17:30.239
Okay, why is it not feasible for the Emacs layer that
-16:45.931 --> 16:54.215
+00:17:30.240 --> 00:17:34.319
interprets Emacs Lisp, the core in C, have a Scheme
-16:45.931 --> 16:54.215
+00:17:34.320 --> 00:17:39.799
interpreter instead of using Guile? Let's see, I have to,
-16:55.496 --> 16:57.257
+00:17:39.800 --> 00:17:48.799
okay. Emacs layer interprets Emacs Lisp, the core in C, have
-16:57.737 --> 17:05.942
+00:17:48.800 --> 00:17:54.079
a Scheme interpreter instead of using Guile. Okay, so that,
-17:07.362 --> 17:13.906
+00:17:54.080 --> 00:17:59.959
the question xlarsx is asking, xlars, x, So Lars is asking,
-17:14.744 --> 17:28.093
+00:17:59.960 --> 00:18:02.319
is it not feasible for there to be an
-17:14.744 --> 17:28.093
+00:18:02.320 --> 00:18:06.839
Emacs layer that interprets Emacs Lisp have a scheme
-17:14.744 --> 17:28.093
+00:18:06.840 --> 00:18:33.079
interpreter? This is Robin Templeton's project. And
-17:30.815 --> 17:32.156
+00:18:33.080 --> 00:18:39.839
they're presenting later today. So check the roster and be
-17:32.697 --> 17:41.303
+00:18:39.840 --> 00:18:45.199
sure to see that presentation because that's exactly what
-17:32.697 --> 17:41.303
+00:18:45.200 --> 00:18:52.119
Robin Templeton is doing. That's not what I'm doing though.
-17:44.419 --> 17:46.459
+00:18:52.120 --> 00:18:57.239
I'm trying to create something in Scheme. But yes, there is
-17:48.280 --> 17:54.921
+00:18:57.240 --> 00:19:02.959
an attempt to get an Scheme interpreter to run inside of
-17:48.280 --> 17:54.921
+00:19:02.960 --> 00:19:07.159
Emacs itself. And it has its own method of binding to Emacs
-17:55.181 --> 18:05.323
+00:19:07.160 --> 00:19:11.199
Lisp functions and translating data like Lisp structures
-17:55.181 --> 18:05.323
+00:19:11.200 --> 00:19:14.439
between Guile Scheme and Emacs Lisp. Robin will explain all
-18:05.943 --> 18:08.284
+00:19:14.440 --> 00:19:15.799
of that in their presentation.
-18:28.519 --> 18:33.020
+00:19:15.800 --> 00:19:18.919
OK, I think I've got through all the questions on Etherpad.
-18:33.620 --> 18:35.500
+00:19:18.920 --> 00:19:23.879
But I'm going to hang out here for a bit longer. And yeah, feel
-18:37.621 --> 18:46.182
+00:19:23.880 --> 00:19:28.239
free to do a video chat with me or send me more questions on
-18:37.621 --> 18:46.182
+00:19:28.240 --> 00:19:33.839
Etherpad or here in the big blue button. And so I'm just going
-18:47.002 --> 18:48.082
+00:19:33.840 --> 00:21:49.119
to hang out. And thanks for asking all your questions. And
-18:51.663 --> 18:56.024
+00:21:49.120 --> 00:21:50.839
yeah, I look forward to working with all of you if you're
-18:51.663 --> 18:56.024
+00:21:50.840 --> 00:21:51.799
interested. take it easy. Thanks so much for the talk and
-18:59.935 --> 19:08.180
+00:21:51.800 --> 00:21:53.199
looking forward to seeing some of your progress as this
-18:59.935 --> 19:08.180
+00:21:53.200 --> 00:21:54.359
moves forward, exciting space. We'll go ahead and leave the
-19:09.261 --> 19:14.925
+00:21:54.360 --> 00:21:54.879
room open for you and thanks for offering to hang out and chat
-19:09.261 --> 19:14.925
+00:21:54.880 --> 00:21:55.639
with other people that come by. Feel free to throw something
-19:15.025 --> 19:18.287
+00:21:55.640 --> 00:21:56.719
in the chat if you want to remind people you're still here.
-19:19.557 --> 19:25.143
+00:21:56.720 --> 00:21:57.919
Meanwhile, on the stream, we have moved along to our next
-19:19.557 --> 19:25.143
+00:21:57.920 --> 00:21:59.599
talk on Rust, and that is just getting started. But again,
-19:25.283 --> 19:30.549
+00:21:59.600 --> 00:22:00.479
we're continuing to record this, and I'll just keep an eye on
-19:25.283 --> 19:30.549
+00:22:00.480 --> 00:22:01.239
it to stop the recording. Thank you. Thank you. It was
-19:33.352 --> 19:33.853
+00:22:01.240 --> 00:22:01.559
awesome.
-21:47.935 --> 21:50.558
+00:22:01.560 --> 00:22:03.959
So it seems like it's slowed down here for the Q&A. I don't see
-21:50.638 --> 21:53.741
+00:22:03.960 --> 00:22:05.439
anybody else on BBB, so I'm going to go ahead and stop the
-21:50.638 --> 21:53.741
+00:22:05.440 --> 00:22:08.479
recording. We can start it back up. I would say, yes, there's
-21:55.282 --> 21:58.906
+00:22:08.480 --> 00:22:09.519
a lot of things you can do with this. You can handle
-21:58.926 --> 22:00.627
+00:22:09.520 --> 00:22:11.239
processing. Yeah, I'm going to try and join over the chat for
-22:02.029 --> 22:07.614
+00:22:11.240 --> 00:22:14.679
the next talk. I'm not sure if I can do both big blue buttons at
-22:08.635 --> 22:11.538
+00:22:14.680 --> 00:22:15.759
the same time. You should be able to just watch your mute
-22:13.206 --> 22:19.998
+00:22:15.760 --> 00:22:19.159
settings and mute tab settings and whatever all you have to
-22:13.206 --> 22:19.998
+00:22:19.160 --> 00:23:37.800
avoid bleed through. Okay.