Hi! My name is Eduardo Ochs, I'm the author of
an Emacs package called eev, and a few weeks
ago I gave a very bad presentation at
the EmacsConf 2023 about an application of eev.
The title of my presentation was: REPLs
in strange places: Lua, LaTeX, Lpeg, LPegRex,
and TikZ, and the idea is that the
presentation should have a way to let
people try what I was showing, because
the central idea of eev is that
everything should be easy to try...
well, let me explain that in a better way.
Let me start with a
question: why should people learn eev?
Most people say that it looks like a
kind of Org mode, but uglier and less
powerful, and let's look at these ideas here.
Scripts made with
Org mode and code blocks look
very professional - they can be
exported to HTML and PDF easily, you can
show to other people what you're doing,
you can make blog posts... all the
fortification happens in the right
way, you have colors and so on...
and scripts made with eev - and eepitch,
which is one of the best starting points
for eev, they look very barebones...
they have some ideas that are
the opposite of "this must look
professional", and they have some strange
influences in their aesthetics... for
example, they are influenced by ideas by
the ideas of Peter Brook -
about rough theater, about using
the least scenery possible, and so on...
whatever. So people have very good
reasons for spending 10 years trying to
learn Org and they have very good
reasons for spending just just a few
minutes trying to learn eev but the
tutorials of eev are full of "try it"s,
and one of the filters of eev is that
some people who try the "try it"s like eev,
but some people refuse to try the "try it"s -
they just want to see explanations
and a professional description of what
this can do for them, how this can
solve their problems, how would this can
earn them money and so on... and they
don't find that, they refuse to try
the "try it"s, and they hate eev.
Anyway, what I want to show in this short
video is the "try it"s for my presentation
on REPLs in strange places. These "try it"s
only became ready several weeks after the
presentation and now I'm going to show
rather quickly how to run them.
This is the list of intros of eev...
let me switch to a smaller font here...
the one that we are going to see
is here, in the section of advanced
features that require extra setup and
the name of this intro is find-show2-intro.
Let me go straight to that intro...
it's here... here we have an
introduction that explains
very roughly what these things are...
the main idea is that at some point the
the main attraction of this thing will
be a tutorial on how to use Lpeg, that is
a tool for generating parsers...
but this tutorial does not exist yet...
anyway, the focus here is on how
to try this
thing. You need to start here...
this is not a very basic "try it", it
has some prerequisites... it expects
that people will understand most of
these expressions here... and one of
the most basic things is that when you
type f8 on a line that starts with
two red stars the f8 treats that line
as a comment and shows the content of
that line in the echo area.
When yoy type f8 on a line that has only one
red star the rest of the line is treated as
Lisp... so these lines here,
that take a few seconds to run...
they will assure that we have access to
melpa and that the package system is
installed...
oops, oh no, I need to fix something here...
whatever - I'll do that later...
and then these other two sexps here
will guarantee that
we have pdf-tools installed, and this
last one here, that is a comment... if we
execute it with M-e... then it
will show the description of the
package pdf-tools, in my case it
will show that is installed... and so on.
Then, to try the the demo people have to
install some system-wide dependencies...
I mean, this first block was for an
Emacs-wide dependency, that is pdf-tools...
In my case I need to run this
block here, because I'm running Debian...
so I need to run this... in this
case if I send these lines to a shell
with f8s it's going to show that
all these packages are already
installed... and then I have to give
more f8s here, just to define links to
some manuals... for example, now this
link here... if I execute it with M-e it
will open the manual of lpeg... a local
copy of the manual of lpeg.
Then we have to run this part here
that installs some things in
/tmp, and this first block here clears
the directory in which I'm going to put
most of the things, and it clones my
programs - the ones that I showed in my
presentation in a very incomplete form...
then this other block here
clones other two repositories of
something very specific about Lua - some
extensions of Lpeg... and they compile one
of these extensions, that needs to be
compiled with gcc...
and then we have to run this
other block here, that defines links to
some manuals... for example...
oops, well, whatever... and then I have
to run this block here because the
communication with some of the external
programs that will be run from Emacs will
be done using environment variables...
then this block here is
just a technical comment...
then here we have the first
non-trial test.
These three lines here will
create
a target buffer running Lua here...
and then it will check with if my
pretty-printer works...
it does, it's able to print
associative tables in this format...
and then I'm going to do some other things
here... I'm going to inspect the path and
then load an extension of my pretty-printer
and ask it to tell me the contents of the
table of methods of my pretty-printer...
so, for example, it prints the method
getsortedkvs as this, and this thing
is something that I can run in Emacs...
and it shows the source code
here in the window at the right. let me
close this and go back...
This is a test that we need
to run just to check if lpegrex is
working... it's not very important, lpegrex
is only going to be used in a
very few tests, and just to compare
lpegrex with my hacker-friendly version
of its main functions...
so here is a test... it adds some
paths to the to the LUA_PATH...
and then we just need to check that
these things here run without errors...
but the output is boring, as I've said.
This is another test, that just
checks if lpegrex can be loaded in
another way... it's also boring it only
shows that some the functions are defined...
and this is the non-trivial part,
that shows the things that I've explained in
my presentation... the first thing is that
most of my tools use one of the
windows to display a PDF,
but the PDF must be regenerated
by Lua and we need to tell Lua where to
put that PDF and this is done by setting
some environment variables, and the
function that does that is called
show2-use, that tells Show2
which directory to use, and it works in a
very non-trivial way... but usually we run
show2-use before a block like this one...
and remember that some parts of
blocks like these are things
that are not important... for example, if I
run this then it shows in the window at
the right the current... sorry, this
example. If I run just this it shows
in the window at the right a target
buffer that may not be important, then in
the second line here it kills the
current target buffer and then in this
other line here it recreates the target
buffer so that I got a new target buffer
running Lua.
This line here, whose
logic is very non-trivial... it also uses
the window at the right, but it uses the
window at right to explain what it is
doing. So if I run this it shows in the
window at the right how its argument
is going to be interpreted, how it's
going to be processed to set some
environment variables, and explains lots
of things including how it's going to
define these functions here, that set up
a 3-window setting like this.
But let me go back to this
part of the demo here... if I run
all these lines with f8, each one of the
lines will show a buffer like this,
with the information about what show2-use
does with each of these
arguments... so I can just type several
f8s here and compare how things change.
So this is just a way
to let people understand how this
function works... and it uses a nice trick
that I only invented a few weeks ago,
that is using the window at the right for
explaining the logic...
and now here is a basic
example of using show2-use...
and using Show2...
and this line
here, with the show... it takes a few
seconds to run... it creates a
PDF, and this line here creates the
3-window setting with the script
being edited here - the "e", the target
buffer here - the "t", and the viewing
buffer here - the "v"... so this works,
but it's very basic... there are some
explanations here...
this is an example that is
slightly less
trival... we can first execute it like
this... note that
here we have these two lines, that look
redundant... in the first we define the
global variable "body" in a certain way,
and in the second we we redefine "body" in
another way...
let me run this again... :show00 and :show0
are just debugging functions
that show what is going to be saved
in the .tex file... and this last line here,
we just ":show" without any "0"s,
saves the .tex file and
produces the PDF... and it takes a few
seconds to run we need to wait
until it finishes, and we need to to
check if its output says either success
or error... and if we got a success then we
can run this, the "(etv)"...
and note that this option
here has told show to include some
things here that would scale the output...
it includes this \scalebox{4} here...
and then this part of the
tutorial explains that we can run
these lines here in any order, and we can...
remember that in the first time
this first line was ignored because the
second one redefined "body"...
but now we can run this first
line here and now this value is going to
override the other one...
then we skip this "HELLO" without
the backslash here... we run these lines
again... and now the show is going to say
that we didn't get a success, we get
an error... so now the "(etv)" would not
work, it's going to show something spurious...
and we can show the log of the
compilation... we're going to see what went
wrong...
and we can also run this to to examine
what was saved in the .tex file.
So this was just a basic demo to
explain how Show2 works, and how "(etv)"
works, and how we can use these several
variants of :show to inspect what is
being saved and compiled...
and now we have a few
less trival tests, in the
sense that these tests are going to
show something in the PDF that is not so
trivial... here we get one test that is in
a test block in this file...
the file is called ParseTree2.lua,
and this line here goes to
this test block... and if we run this
block here, in the test block...
it uses a parser that is defined in
this file, it parses this string
here, it displays this, the abstract
syntax tree generated by parsing this
string... and then we have some
other lines here that process the tree
in several ways...
that I do not want to explain... but the
important is that at this point here at
this line I take this object here,
produced by underbracifying o9, and I
run the show method on it. It takes a
few seconds, it says success, so now this
is going to work...
and it displays this parse tree here.
So this was one of the non-trivial
tests... here is another one...
that... the output looks trivial, but
the logic is not...
the test is this one, it produces
this .tex here, that loads
several .tex files and the
style file... they are all included
this directory here...
here you can see that is,
/tmp/show2-elpeg1/LATEX/,
so it's a temporary thing... but it has
lots of Luas files and some .tex files.
and this thing here is processed by
by the one of the things that I use to
to generate diagrams in LaTeX, it's a
package called Dednat6...
and if I run this it generates a PDF and
the PDF is this.. so this thing is a
variant of verbatim mode...
and this is something that will be very
interesting at some point, but at this
point is not really interesting...
this is my hacker-friendly
version of lpegrex, and here
are some examples of how it works...
I tested either all or most of its
test blocks and they are working... for
example, this one is a test block that
defines a grammar that starts very
basic... and then it's changed a bit at a
time... and then we change the grammar and
we ask this function here to use the
current grammar to parse this thing
here considering that this symbol
here is the top level symbol of the
grammar. So... it shows how we can parse
arithmetical expressions with the right
precedence, and... that's it.
At some point this thing is going to become
a tutorial of lpeg but at at this moment
it is not. Anyway...
So, here we have lots of Lua files,
and most of these Lua files have...
let me see... let me see if I have
something interesting here...
Most of these Lua files
have test blocks that that you can run
in your installation, in which
everything is in the /tmp/ directory...
for example this one... no, let me try the
last test block in this file...
it does some weird things here, but
then it has a :show()... the :show()
saves a .tex file and compiles it into a PDF,
and then this thing here shows the result,
that is something three-dimensional here,
and some other things here.
So, yeah, that's it! I hope that
everything is... will be easy to
run... I have only tested this thing on
Debian and I have one friend that is
testing that on Mac OS and another
friend who's testing that on Arch Linux...
and if you can test that on
your system then please get in touch!
Please tell me if things are working,
please help me to debug these things...
and yeah! That's it. That's it for the
moment. Thanks! Bye! =)