(Re)generate: (find-escripts-intro)
Source code: (find-efunction 'find-escripts-intro)
More intros: (find-eev-quick-intro)
(find-eev-intro)
This buffer is _temporary_ and _editable_.
It is meant as both a tutorial and a sandbox.
The quickest way to open or recreate this is with `M-6 M-j'.
This intro will be merged with
(find-here-links-intro)
at some point...
Eev's central idea is that you can keep "executable logs" of
what you do, in a format that is reasonably readable and that is
easy to "play back" later, step by step and in any order. We
call these executable logs "e-scripts".
We will start this intro by explaining how eev and e-scripts
appeared. Then we will see how to read and play back a sample
e-script, and understand its conventions; then we will see some
tools to help writing e-scripts in several usual formats:
1) a file with hyperlinks and eepitch blocks,
2) a file with e-script blocks and an index,
3) several files with e-script blocks and indexes,
4) source files with eepitch blocks in multi-line comments,
5) temporary buffers, like the ones generated by
`find-latex-links' and `find-lua-links'.
1. Prehistory
Eev appeared by accident. I started using Emacs in 1994 or 1995.
I knew a bit of Lisp from a course in the university, and after
just a few hours using Emacs I started putting sexps like this in
my notes,
(find-file "/usr/share/emacs/19.24/lisp/")
(find-file "/usr/share/emacs/19.24/lisp/files.el")
to go quickly to files or directories that I found interesting. A
few days after that I wrote a function - that I could invoke as
`M-x eev' - that saved the text of the region in the file
"~/ee.sh", and I had an alias `ee' in my shell that would
execute the contents of that file in verbose mode, i.e., showing
each line before executing it. "Eev" meant
"Emacs-execute-verbosely", but `M-x eev' only saved a block of
commands into "~/ee.sh"; to execute them I had to switch to a
terminal and type "ee". If the function `eev' was called with a
string argument instead of being called interactively it would
write that string to "~/ee.sh"; a sexp like
(eev "man tar")
was a very primitive hyperlink to the manpage for "tar". I
wrote extensions to these ideas gradually, and for YEARS I was
absolutely sure that Emacs was meant to be used exactly in that
way, and that EVERYBODY used elisp code as hyperlinks. At some
point in 1999 I sent a message to a mailing list about Emacs, and
I casually apologized for using my own functions - with weird
names - for elisp hyperlinks and for saving code to be sent to a
shell, and asked where in the elisp source files I could find the
standard function that did that.
RMS himself answered.
He said that no one else was using Emacs in that way; that that
was very interesting, and that someone should clean up and
document my code so that it could be included in Emacs.
Eev is not yet an official part of Emacs (long story!) and
eepitch practically replaced `M-x eev' as a way to execute shell
commands. For more on `M-x eev', see: (find-prepared-intro)
2. E-scripts
The best short definition for eev that I've found involves some
cheating, as it is a circular definition: "eev is a library that
adds support for e-scripts to Emacs" - and e-scripts are files
that contain chunks meant to be processed by eev's functions.
Almost any file can contain parts "meant for eev": for example,
a HOWTO or README file about some program will usually contain
some shell commands, and we can use `M-x eev' or eepitch to send
these commands to a shell; most of my own files contain lots of
elisp hyperlinks, and some of them even contain eepitch blocks
inside multi-line comments - for example, this Lua library:
http://anggtwu.net/LATEX/dednat6/eoo.lua.html#Vector
Some of my files are "pure e-scripts": they are mostly made of
"e-script blocks" like the ones described here:
(find-eev-quick-intro "8.4. Creating e-script blocks")
Here are two examples structured like this:
http://anggtwu.net/e/emacs.e.html
http://anggtwu.net/e/lua5.e.html
Each of these "e-script blocks" is an "executable log" of
something that I was trying to understand, or trying to do.
3. Sharing
One of my first public texts about eev was the "Eev Manifesto":
http://anggtwu.net/eev-manifesto.html
Here are its main parts.
Everybody is fluent in only a small fraction of all Unix
commands. If you could "listen" to how the Unix gurus
"speak" to their machines you would learn which "words" are
related to solving a particular task, and learn how they fit in
"sentences". By checking the "dictionary entries" for
them (i.e., manpages, info pages, READMEs, source code, etc)
you could learn the real meaning of them. But then you'd be
learning Unix by immersion, from real use, instead of having to
rely only on "textbooks", "dictionaries" and sometimes
"Rosetta stones", "graffitis on toilet walls" and "old
newspapers".
The fact is that you can make a record of how you "speak"
Unix, and more, you can become a lot more productive if you do
so. Many tasks consist on short fixed sequences of commands:
connecting to your ISP via modem, unpacking a source package
and recompiling it, printing a text file in two-column mode,
and so on. The trick is that with some functions defined in
eev.el you can write these sequences of commands in a plain
text file, then mark a block of this file with your
editor (which must be Emacs for this to work), then tell a
shell to execute only the commands in that block; in this way
you can easily execute only portions of what would otherwise
have to be a monolythic script; this is great for when you're
not sure if everything works, or if you just want to do some
steps. Also, it would be easy to change bits of the "script"
before execution, as you'll be doing things from inside an
editor.
(...)
I have placed essentially all my "scripts" written in this
way (I call them "e-scripts") in a public place. They contain
almost everything I know about Unix.
If you like this idea, please get in touch, send comments, ask
questions -- about e-scripts or questions whose answer could
become an e-script chunk -- or send me your e-scripts when you
have some, or even ask for help on setting up your own e-script
collection or e-script public site... anything! By asking good
questions you can help me make the documentation get better.
I really want to make this e-scripts idea spread. Learning Unix
-- or simply more Unix -- could be made easier for everybody...
please help! E-scripts are more fun to use, and easier to
write, than texts that tell everything in terms of "press
this, do that". A lot of effort and money are being invested
now on these kinds of text, and they're often very depressing.
Let's try to save the world from them, at least a bit, and
maybe this money will be directed to better things. And
teaching people Unix tricks will be both easier and more fun.
The Manifesto said that
1) *NIX can be compared to an oral language,
2) we can "write" the commands that we "speak",
3) we learn mostly by "listening", or "reading", others,
4) we have good reasons to write:
a) executable logs make us more productive,
b) our notes/logs can, and should, be shared.
What it *did not* say explicitly was:
5) that *not sharing* should be *immoral*,
6) one of my main objectives with eev was REVENGE.
I spent (what felt like) hundreds of hours in the university
trying to learn things with the *NIX users and gurus there - to
practically no avail. They answered very few of my questions,
they only very rarely showed me their code or notes, and I can
remember only a handful of cases in which we sat side-by-side on
a terminal.
These people - who shared very little - were the most respected
hackers of that place.
They had to be stripped of their status.
4. How to read an e-script
The indented block below between the two "snip, snip" lines -
we will call it "Example 1" - exemplifies most of the basic
techniques available for e-scripts. These techniques will be
reviewed in the subsections below.
--snip, snip--
# Index:
# «.lua5.1-debian» (to "lua5.1-debian")
# «.lua-tutorial» (to "lua-tutorial")
#####
#
# The main Debian packages for Lua 5.1
# 2018jun02
#
#####
# «lua5.1-debian» (to ".lua5.1-debian")
# (find-status "lua5.1")
# (find-vldifile "lua5.1.list")
# (find-udfile "lua5.1/")
# (find-status "lua5.1-doc")
# (find-vldifile "lua5.1-doc.list")
# (find-udfile "lua5.1-doc/")
# (find-udfile "lua5.1-doc/doc/")
# (find-udfile "lua5.1-doc/test/")
# http://www.lua.org/docs.html
# http://www.lua.org/manual/5.1/manual.html
# file:///usr/share/doc/lua5.1-doc/doc/manual.html
* (eepitch-shell)
* (eepitch-kill)
* (eepitch-shell)
sudo apt-get install lua5.1 lua5.1-doc
#####
#
# Downloading and opening an eev-based Lua tutorial
# 2018jun02
#
#####
# «lua-tutorial» (to ".lua-tutorial")
# http://anggtwu.net/e/lua-intro.e.html
# http://anggtwu.net/e/lua-intro.e
* (eepitch-shell)
* (eepitch-kill)
* (eepitch-shell)
cd /tmp/
rm -v lua-intro.e
wget http://anggtwu.net/e/lua-intro.e
# (find-fline "/tmp/lua-intro.e")
# (find-anchor "/tmp/lua-intro.e" "intro:types")
# (defun eejump-71 () (find-fline "/tmp/lua-intro.e"))
--snip, snip--
4.1. Anchors and `to'
The two lines below
# «.foo» (to "foo")
# «foo» (to ".foo")
"point to one another". This is explained here:
(find-eev-quick-intro "8. Anchors")
We used this in Example 1 to create an index. Compare with:
# Index:
# «.one» (to "one")
# «.two» (to "two")
###
## Stuff in block "one"
###
# «one» (to ".one")
(...)
###
## Stuff in block "two"
###
# «two» (to ".two")
4.2. Debian hyperlinks
The hyperlinks using `find-status', `find-vldifile', and
`find-udfile' are hyperlinks to information about a Debian
package. These hyperlinks
(find-status "bash")
(find-vldifile "bash.list")
(find-udfile "bash/")
are equivalent to:
(find-fline "/var/lib/dpkg/status" "\nPackage: bash\n")
(find-fline "/var/lib/dpkg/info/bash.list")
(find-fline "/usr/share/doc/bash/")
See:
(find-eev "eev-blinks.el" "find-Package")
(find-eev "eev-blinks.el" "find-Package" "find-status")
(find-eev-quick-intro "9.1. `code-c-d'")
(find-eev-quick-intro "9.1. `code-c-d'" "(code-c-d \"ud\"")
(find-eev "eev-code.el" "code-c-d-s")
(find-eev "eev-code.el" "code-c-d-s" "(code-c-d \"ud\"")
(find-eev "eev-code.el" "code-c-d-s" "(code-c-d \"vldi\"")
4.3. URL hyperlinks
The lines
# http://www.lua.org/docs.html
# http://www.lua.org/manual/5.1/manual.html
# file:///usr/share/doc/lua5.1-doc/doc/manual.html
are URL hyperlinks. Here's how to follow them:
(find-eev-quick-intro "3.1. Non-elisp hyperlinks")
Note that the "file:///" URL above points to a local copy of
the Lua manual at "http://www.lua.org/manual/5.1/manual.html" -
but the local copy will only exist if the Debian package
"lua5.1-doc" is installed.
4.4. Eepitch blocks
This
* (eepitch-shell)
* (eepitch-kill)
* (eepitch-shell)
sudo apt-get install lua5.1 lua5.1-doc
is an "eepitch block", as explained here:
(find-eev-quick-intro "6. Controlling shell-like programs")
(find-eev-quick-intro "6.1. The main key: <F8>")
Note that it will only work if you delete the whitespace before
the "*"s!
4.5. Htmlized e-scripts
The "Eev Manifesto" in section 3 above has this:
I have placed essentially all my "scripts" written in this
way (I call them "e-scripts") in a public place. They contain
almost everything I know about Unix.
The "public place" is here:
http://anggtwu.net/e/
The links
# http://anggtwu.net/e/lua-intro.e.html
# http://anggtwu.net/e/lua-intro.e
point to one of these e-scripts - one that I use to teach (or
introduce) Lua to people that already know other programming
languages. The
# http://anggtwu.net/e/lua-intro.e.html
point to an "htmlized version" of it, in which many of the
hyperlinks are converted to something that works in a browser.
The header of the .html explains briefly how the htmlized version
is produced.
4.6. The `rm' in the eepitch block
When we execute this eepitch block a first time,
* (eepitch-shell)
* (eepitch-kill)
* (eepitch-shell)
cd /tmp/
rm -v lua-intro.e
wget http://anggtwu.net/e/lua-intro.e
the "rm" gives an error:
rm: cannot remove 'lua-intro.e': No such file or directory
When we execute it a second, third, fourth time, the "rm"
deletes the file "/tmp/lua-intro.e" that the wget downloaded in
the previous run.
I usually write my eepitch blocks a few lines at a time, and I
test the new lines by running the whole block again from the
beginning. This means that for me most of the time a line like
rm -v lua-intro.e
does not give an error - and I got used to ignoring the error
when it's run for the first time.
Most e-scripts in
http://anggtwu.net/e/
follow these conventions:
1) they can be re-run,
2) they start with clean-up code,
3) I prefer to write the clean-up code to be short, even when
this means that I will have to ignore errors and warnings.
4.7. A convention about order
(Explain why I feel natural to put the eepitch block that
installs the lua5.1 packages at the end of the first e-script
block, after the hyperlinks to files from that package)
5. Tools for writing e-scripts
One of my favorite ways of describing eev is as a "tool to
create executable logs", but this only make sense if we clarify
some ideas and terms.
The e-script in Example 1 has two _e-script blocks_ plus an
_index_. The fist block has notes about installing the packages
for Lua5.1 in Debian and inspecting them, and the second block is
about downloading and using an eev-based Lua tutorial. Let's
think of each of these blocks as a _task_.
The task "install Lua5.1" is performed in one way if we're
doing it for the first time, and in a different way if we're
doing it for the n-th time with some memory of what we did in the
previous times and of what we found important and what not.
Performing a task like this consists of several steps, that can
be roughly divided into "visiting" and "commands". I borrowed
the term "visiting" from Emacs:
(find-enode "Visiting" "Visiting Files")
Look at the first block of Example 1 again. It has several elisp
hyperlinks to information about the packages "lua5.1" and
"lua5.1-doc". Following those hyperlinks let us "visit" the
descriptions of the two packages, their lists of files, and some
of their directories. Then the e-script block has three URL links
to the Lua documentation in general and to its reference manual,
and then an eepitch block that runs an "apt-get install".
We saw how to follow links and how to execute eepitch blocks, so
an e-script block is "executable". But in what sense it is a
"log"?
1. In the old days log books were always made of paper, and
there was nothing automatic in taking notes with them. We
would have to decide what to write and how to write it, and
we would have to alternate between the "task" and "taking
notes". After many years of practice _some_ people would
learn how to take notes without distracting themselves much
from the task at hand, and they would learn how to make
their notes at the same time concise and readable enough.
2. Nowadays, with computers, there are _some_ ways to write
logs automatically - for example, most shells record the
commands given to them - but the output is of low quality.
3. Eev takes an intermediate stance between "notes by hand"
and "automatic notes". It is possible to do
"task"+"notes" with just a few more keystrokes than for
doing just "task", but that requires learning some tricks,
and having some practice.
The next sections discuss those tricks.
5.1. Anchors-to pairs and e-script blocks
Anchor-to pairs can be generated easily using `M-A':
(find-eev-quick-intro "8.3. Creating index/section anchor pairs")
(find-eev-quick-intro "8.3. Creating index/section anchor pairs" "M-A")
Typing `M-A' on this line:
# <bletch>
yields this pair of anchor-to lines:
# «.bletch» (to "bletch")
# «bletch» (to ".bletch")
let's call the first one a "to-forward" and the second one a
"to-back". In my e-scripts files I follow the convention that
the to-forwards are all together at the beginning of the file,
forming an index of sections of the file, and each to-back is at
the beginning of a section. Most of the source files of eev
follow this convention; see, for example:
(find-eev "eev-blinks.el" ".eek")
(find-eev "eev-blinks.el" "eek")
Note that there, and in most source files of eev, above each
to-back line there a title in big letters in ASCII art in Lisp
comments.
After creating a to-forward-to-back pair with `M-A' we have to
move the to-forward line to the index by hand, using cut and
paste.
In the e-script files in
http://anggtwu.net/e/
I follow another convention - "e-script blocks". The title
above each to-backward line is written like this:
#####
#
# Long description for the section Bletch
# 2016feb29
#
#####
Note that you can generate a title in "#"s like that, followed
by a to-forward-to-back pair, by typing `M-B' on a line like:
bletch Long description for the section Bletch
See:
(find-eev-quick-intro "8.4. Creating e-script blocks")
(find-eev-quick-intro "8.4. Creating e-script blocks" "`M-B'")
The to-forward line still has to be moved to the index by cut and
paste by hand.
5.2. Debian hyperlinks
The key `M-D' converts a line with the name of a Debian package,
like this,
lua5.1-doc
to these three hyperlinks,
# (find-status "lua5.1-doc")
# (find-vldifile "lua5.1-doc.list")
# (find-udfile "lua5.1-doc/")
and moves the point to the next line. Try it! Put the point on
the "bash" line below and type `M-D M-D M-D':
bash
lua5.1
lua5.1-doc
5.3. URL hyperlinks
I usually "write" URLs in Emacs by copying them from a browser
to Emacs.
5.4. Eepitch blocks
We saw in
(find-eev-quick-intro "6.3. Creating eepitch blocks: `M-T'")
how to create eepitch blocks with `M-T'. Try that on the line
that says "lua51" below:
lua51
5.5. `rm/mkdir/cd' triples
Try typing `M-R' on the line with the "/tmp/foo/" below:
/tmp/foo/
5.6. Hyperlinks to files, directories, and info nodes
One practical way to create a `find-fline' hyperlink is with
`M-F' (`eewrap-find-fline'). Try it here:
/usr/share/doc/lua5.1-doc/test/
/usr/share/doc/lua5.1-doc/test/README
/usr/share/doc/lua5.1-doc/test/fibfor.lua
Note that the three lines above were copied from:
(find-vldifile "lua5.1-doc.list")
(find-vldifile "lua5.1-doc.list" "/usr/share/doc/lua5.1-doc/test")
Another way is by visiting a file and typing `M-h M-h'. See:
(find-eev-quick-intro "4.1. `find-here-links'")
This can also be used to generate links to info nodes.
(...)
6. Tutorials
All the tutorials in eev follow these four principles:
1. All the examples in them are very easy to run,
2. The links to documentation are easy to follow,
3. All the "sub-examples" are easy to run,
4. The links to related documentation - including links to
primary sources - are easy to follow.
I used to believe that all these four principles would be
immediately obvious to everyone who had played a bit with the
tutorials of eev, and I thought that people would realize that
these are very good principles, that they should follow too...
and so these people would start to apply these principles to
their own e-scripts, and they would adapt them to other
environments that are not Emacs-based, and these ideas would
spread (sort of) naturally. Well, I was totally wrong - and I
only discovered that in 2021, when I chatted with some relatively
advanced eev users to whom those ideas were not obvious at all.
So let me try to be explain these principles clearly - especially
the principles 3 and 4 - and show how they can be applied to
other contexts besides tutorials.
The idea of "making sub-examples very easy to run" is
especially easy to see in the elisp tutorials. In this
introduction
(find-elisp-intro "1. Introduction")
we have first this sexp,
(+ (* 2 3) (* 4 5))
and then these ones:
2
3
(* 2 3)
4
5
(* 4 5)
(+ (* 2 3) (* 4 5))
(list (* 2 3) (* 4 5))
In the first sexp people _could_ execute the subsexps (* 2 3)
and (* 4 5) by typing `M-E' in the right places... remember:
(find-eval-intro "2. The end of line and `M-e'")
(find-eval-intro "2. The end of line and `M-e'" "without moving")
...but it is much easier to see the sub-sexps, and to execute
them, when they are in different lines. This example also serves
to stress to beginners than number, like 4, are sexps too, and
they can be evaluated - the result of evaluating 4 is 4.
In a sequence of sub-sexps, like the one above, I usually try to
arrange the sexps in a didactic order: to understand the result
of (+ (* 2 3) (* 4 5)) we need to understand first the results
of (* 2 3) and (* 4 5). Also, the best way to understand the new
idea that appears in
(list (* 2 3) (* 4 5))
is to compare it with this other sexp, that appears just before
it and is conceptually simpler:
(+ (* 2 3) (* 4 5))
I try to apply this principle - "make sub-examples very easy to
run" - to tutorials for other languages, too. At this moment the
only tutorial for another language that I have that is in a
_reasonably_ organized form is this one,
http://anggtwu.net/e/lua-intro.e.html
(find-wgeta "http://anggtwu.net/e/lua-intro.e")
(find-wgeta "http://anggtwu.net/e/lua-intro.e" "intro:for")
but parts of it were written in 2004, when these principles were
not yet very clear to me. I am revising it, and I am also trying
to convince some students to work together with me on tutorials
for shell and Python, but they are not very enthusiastic (yet).
The "links to related documentation" can also be arranged in a
didactical order. For example, here,
(find-eev-quick-intro "6.4. Red stars")
(find-eev-quick-intro "6.4. Red stars" "bullet")
(find-eepitch-bullet-links)
the first link points to a section of a tutorial that most people
should have stumbled on; the second link points to technical a
point in it that most people ignore on a first reading, and the
third one points to something much more technical,
containing (executable!) source code.
(TO DO: mention test blocks)
7. Sequences of links
A good part of my executable notes consists of sequences of links
in which in practically all cases the new link "refines" the
previous one in some sense; the notion of "refining" explained
here is just one of these senses:
(find-refining-intro "1. Pos-spec-lists")
Let me compare two styles: 1. textual, 2. executable notes.
1. The section 2 of the tutorial `find-eev-quick-intro'
mentions that `M-e' accepts several different numerical
prefixes, but it only explains one case: `M-0 M-e'. One way
to discover what the other numerical prefixes do is to use
`M-h M-k', that is explained in the section 4.2 of
`find-eev-quick-intro', on `M-e', and then follow the link
in the temporary buffer that starts with `find-efunction'.
The key `M-e' is bound to `ee-eval-sexp-eol', and one of
lines in the docstring of `ee-eval-sexp-eol' says this:
3: same as 2, but also switch to the new window
If we follow the source code we see that `M-3 M-e' executes
`ee-eval-last-sexp-3', that calls a function called
`find-wset', that is defined in eev-multiwindow.el. Some
functions in eev-multiwindow.el call functions like
`split-window-horizontally', that are mentioned in section 6
of `(find-emacs-keys-intro)'.
The comments at the top of eev-multiwindow.el say that the
functions in that file are explained in a tutorial called
`find-multiwindow-intro'. It turns out that the first
argument of `find-wset' is a string that is interpreted as
series of commands in a mini-language in which each
character means a certain operation on windows.
Now let's see the second style: executable notes. I wrote the
block below by following the idea described here:
(find-here-links-intro "1. Alternating between \"task\" and \"notes\"")
Every time that I found something interesting I would save a link
to it in my notes, and these are my notes with only very minor
clean-ups.
2. (find-eev-quick-intro "2. Evaluating Lisp")
(find-eev-quick-intro "2. Evaluating Lisp" "M-0 M-e")
(find-eev-quick-intro "4.2. `find-ekey-links' and friends")
(eek "M-h M-k M-e")
(eek "M-h M-k M-e ;; ee-eval-sexp-eol")
(find-eek "M-h M-k M-e ;; ee-eval-sexp-eol")
(find-eek "M-h M-k M-e ;; ee-eval-sexp-eol" "(find-efunction ')")
(find-efunction 'ee-eval-sexp-eol)
(find-efunction 'ee-eval-sexp-eol "3:")
(eek "2*<up> M-3 M-e")
(find-efunction 'ee-eval-last-sexp)
(find-efunction 'ee-eval-last-sexp-3)
(find-efunction 'ee-eval-last-sexp-3 "find-wset")
(find-efunction 'find-wset)
(find-emacs-keys-intro "6. Windows")
(find-emacs-keys-intro "6. Windows" "L|R")
(find-eev-intro)
(find-eev-intro "M-5 M-0 M-j")
(find-eev-intro "(find-multiwindow-intro)")
(find-multiwindow-intro)
(find-wset "13o_2o2o23oo33ooo" '(find-ebuffer "B"))
(find-wset "13o_2o2o23oo33ooo+" '(find-ebuffer "B"))
(find-2a nil '(find-efunction 'ee-eval-sexp-eol))
(find-2b nil '(find-efunction 'ee-eval-sexp-eol))
The notes in the style 1 are a translation to English to the
notes in the style 2. I wrote the notes in style 2 first.
Some people _PANIC_ when they see notes written in the second
style, and most of us are conditioned to believe that a) we have
to try to write notes that are readable by everyone - even though
that is impossible if we take the "everyone" literally, b)
notes in the second style can't be shared in public. However:
a) It is good karma to make our notes publically available even
if very few people will be able to read them,
b) we are our main readers - and we need to try to make our
notes easily to read by ourselves,
c) _executability_ helps in _readability_,
d) people are experimenting with ways of writing executable
notes, and even the most popular styles of doing that -
Jupyter Notebooks, I guess? - are not yet really hugely
popular.
One of my intents with eev is to encourage people to experiment
with ways of writing executable notes. This involves learning the
functions and techniques that already exist, and inventing new
ones - and, hopefully, sharing them.
8. IRC
(TO DO: explain this:)
(find-efunction 'ee-0x0-upload-region)
(find-efunction 'ee-0x0-upload-region "aliased to `u0'")
9. Git
Example:
(progn
;; Links to the git repository:
;; https://github.com/edrx/emacs-lua
;; https://github.com/edrx/emacs-lua/blob/main/tests.e
;; https://raw.githubusercontent.com/edrx/emacs-lua/main/tests.e
(setq ee-emluagit-base
"https://raw.githubusercontent.com/edrx/emacs-lua/main/")
(defun find-emluagitfile (fname &rest rest)
(apply 'find-wget (format "%s%s" ee-emluagit-base fname) rest))
(defun find-emluagit (fname &rest rest)
(apply 'find-wgeta (format "%s%s" ee-emluagit-base fname) rest))
;; Tests:
;; (find-emluagit "tests.e")
;; (find-emluagit "tests.e" "find-angg-and-find-es")
;; (find-emluagit "tests.e" "find-angg-and-find-es" "Tests:")
;; (find-emluagitfile "tests.e" "Warning:")
;; Links to a local copy of the git repository:
;; (find-git-links "https://github.com/edrx/emacs-lua" "emlua")
;; (setq ee-git-dir "~/usrc/")
;;
;; (find-code-c-d "emlua" "~/usrc/emacs-lua/" :anchor)
(code-c-d "emlua" "~/usrc/emacs-lua/" :anchor)
;;
;; Tests:
;; (find-emlua "")
;; (find-emlua "tests.e")
;; (find-emlua "tests.e" "find-angg-and-find-es")
;; (find-emlua "tests.e" "find-angg-and-find-es" "Tests:")
;; (find-emluafile "tests.e" "Warning:")
;; Compare:
;; (find-emluagit "tests.e" "find-angg-and-find-es")
;; (find-emlua "tests.e" "find-angg-and-find-es")
)