The most important keys on any keyboard for an Emacs user are the Operation Keys (I made up that term). Without them Emacs would be useless. For Techne (the new name for my Emacs keyboard project) I decided to use symbols instead of letters for them.
The operations cluster is on both the left and right side of the keyboard. Yes, that is a full twenty keys just to make life happier in Emacs! I love keyboards so dedicating twenty keys to a critical task is perfect for me. These sections live on a eight row by sixteen column layout so there is plenty of room. It’s bottom left corner is position (1,1) (Row, Column) increasing as you go up and to the right (ala Cartesian coordinates). In the table I wrote the key name and then the symbol. The picture only includes the symbol.
Legend: C# (column number)
Ultra is: C-m-S-H. Emacs can handle that including the Shift modifier along with it. In case you haven’t encountered it yet, here is how to get all of the Emacs modifiers on a modern USB keyboard.
My symbol choices started with Sun’s meta symbol. After playing around with that, reading Xah’s page on Unicode input symbols, searching for and comparing symbols with PopChar and playing around with a ton of combinations I ended up here. It is nice because it settles on the diamond theme.
Using Org mode for literate programming probably isn't as powerful as something like Knuth's CWEB but it does have the advantage of working with just about any language and of running the code directly from the (untangled) source file to insert results directly into the document.
Even if, like many people, you don't care for the literate programming paradigm, the idea of combining code and narrative is still very powerful. The approach used by (for example) John Kitchen to embed the code used for calculations and figure generation is a huge aid in reusing results, calculations, and figures and is a significant step towards reproducible research.
In any event, take a look at Babenhauserheide's example. It may give you some useful ideas and it certainly serves as another demonstration of the power of Org mode and Babel.
I read this Reddit thread about favorite themes, and got intrigued by the spacemacs theme1. I added that theme to my init file, and tried making it the default theme. I use use-package, and configured the theme as follows: (use-package spacemacs-theme :ensure t :config (load-theme 'spacemacs-light t) ) When re-evaluating my init file, the theme … Continue reading use-package’s :config vs. :init
I’ve been playing around with some different fonts to see how they look in Emacs. For a long time I’ve been using DejaVu Sans Mono, but I felt like a change. It’s easy to switch the font for the current frame, just use M-x set-frame-font and enter the name of an installed font, or put a line like this
(set-frame-font "DejaVu Sans Mono-14" nil t)
in your scratch buffer and put the cursor at the end of the line, and use C-x C-e to run eval-last-sexp which evaluates that bit of code. This will instantly change the appearance of the current frame.
Here are some of the fonts I’ve been trying out (I installed them using the Font Book on my Mac):
Back in June I wrote about A Complete Example of Reproducible Research with Org. One of the authors of that paper was Arnaud Legrand who has an excellent webinar on reproducible research. Sadly, the video of the talk is in Flash, which makes it unwatchable for many of us. Happily they also have an MPEG4 version but it took a long time to download. Nonetheless, it was worth the wait. It's a really great talk on why you should be doing reproducible research and a demonstration of some of the tools you can use to help you organize and produce it.
The first half of the talk considers the problems that ordinary research papers can have and how reproducible research can help solve them. Legrand also talks about some problems with implementing reproducible research. In the second half of the talk, Legrand demonstrates a few of the tools that a researcher can use to help with producing reproducible research.
One of these, reprozip, helps you capture the environment that you used to run your software. He also looks at Rstudio and Ipython and shows how they can help produce papers while embedding code and results directly into the final result. His favorite tool, though, is Emacs/Org Mode, which he says is more powerful and versatile. He describes how he and his students keep journals (in Org mode) that record everything they did and the results they got. These journals are invaluable when it comes time to write the paper. If you read Legrand's complete example paper, you saw an example of this is in action.
The talk is just over 2 hours 45 minutes so you're going to have to block out time (or several times) to watch. It's worth it though, so if you have any interest at all in the subject matter, I urge you to take the time. Don't worry too much about reading everything on his slides because they are also available.
Finally, I'm happy to report that this is the first in a series of Webinars on reproducible research. There a three more currently available and another is planned for some time this month. The others webinars discuss
Controlling your environment
Logging and backing up your work
If you follow the link to the other videos, you will find a list of topics they plan to cover in the future.
Some time ago there was an interesting thread on the help-gnu-emacs mailing list. Basically, the OP wanted an equivalent of save-some-buffers, only not for all files, but for the ones under version control. More generally, he wanted to be able to programmatically get the list of buffers which visit files under VC. Go to the discussion to read about a few things Emacs can do. One of the things I learned from it was a very general function locate-dominating-file.
I recently wrote down my thoughts about Emacs’ concurrency efforts. In a
way this post is the second part. While the first post went a long way to
explain why I do not like threads this post tries to explain why I see futures
as an easier, a faster way to provide better concurrency support for Emacs.
I believe that threads are just concurrency infrastructures—nothing that I’d
like to use directly. But it’s not as if Emacs Lisp didn’t have infrastructure
for concurrency already: We have asynchronous networking and asynchronous
What we don’t have is a good API around these, and, probably more important,
an ubiquitous model and interface for asynchronous operations.
What tools do we currently have to this end in Emacs Lisp? Only callbacks.
More generally, CPS. But we know from other languages (Node.js, looking at you)
that CPS leads to very messy code when used at scale, and we see it in Emacs
Lisp: Flycheck’s asynchronous code is very hard to follow, because the
inevitable excessive use of callbacks scatters it all over the place.
This CPS spaghetti makes asynchronous operations hard to use in Emacs Lisp,
and—probably even worse—even harder to apply in hindsight. Just going from
“call-process” to “start-process” requires a complete rewrite of the affected
code in CPS.
We know better these days: We know monads, and particularly we know that
assuming a proper “do” notation lifting code from non-monadic bindings to
monadic bindings is much closer to a purely syntactic transformation than
rewriting bindings to CPS. In particular we see that monadic code in a
do-notation retains a important properties of non-monadic code: It’s still
local within a single expression and it’s still readable from top to bottom,
i.e. in sequential form.
That’s not to say that Emacs needs monads—surely that’d be nice, but that’s not
my point. We know that the concept of monads works very well to model
computations, whether we call them monads or not. Scala’s monads have “for” and
“flatMap”, and are in a way “specialized” to the List monad. C# doesn’t even
have proper monads but its “async”/“await” is essentially a very specialized
monadic syntax just for “Future”—C# calls them “Task”—monads.
We could use the same in Emacs Lisp: A monadic syntax—specialized for Futures if
you want—to make asynchronous operations dead-simple to use, and easy to use in
existing code. Take the following as an example:
And what’s more, with futures we had a common model for asynchronous operations
that we could use everywhere.
As an example just think of “completion-at-point-functions” being allowed to
return futures: All of a sudden we had asynchronous completion in Emacs Lisp.
Wouldn’t even be hard to implement: Show synchronous completions immediately,
then await all asynchronous completions and re-render the completion buffer with
all completions. No need even to change the current interface: Futures would fit
in nicely without breaking compatibility as the calling code would just need to
check whether a function returned a future or not.
That’s the main point of futures.
For sure Future can be implemented on top of threading, but they are so much
more than just another API: They offer an ubiquitous interface for asynchronous
results that we could start using everywhere, right away.
And if we like to we can do threads and run futures on top of them. That’s just
another advantage of futures: They don’t care for the underlying execution
model; it could even be synchronous.
In a way futures are orthogonal to threads, but I believe that they are much
much more important than threads—which are just another infrastructure in
addition to async processes and networking that’s going to be under-used in the
absence of a nice and simple concurrency API.
Of course, I’m biased by my own experience—I compare the ease of concurrency in
Scala and Haskell with the hassle of even the simplest asynchronous operations
in Emacs Lisp—but I know that threads won’t be of any use in Flycheck, but the
futures would immediately make Flycheck’s code a lot simpler and allow us to
make some operations concurrency that weren’t worth the complexity of
concurrency with the current API (syntax checker predicates for instance).
I’m not saying that the efforts of the concurrency branch are wasted, or that we
shouldn’t merge it when we get the chance, but I’m not sharing the community’s
enthusiasm about it and I believe that many of those who praise it and long for
it haven’t yet considered the impact of threads on their code. I fear that
threads come to Emacs with much ado only to starve to a niche existence as
everyone realizes that they are terribly hard to use and come at great cost for
existing code, leaving the problem of the blocking Emacs as large as it is just
I see more hope to solve that problem with futures which are easy enough for
everyone to use concurrency. Concurrency for the masses, that’d be a thing in
Table of Contents Part 1 – Intro Part 2 – Create A Simple Function And A Test Of That Function Part 3 – Looping And Local Variables Part 4 – Interactive Functions I’ve just finished watching Daniel Gopar’s elisp video tutorial. So far there are 4 parts to the tutorial, and based on this thread … Continue reading Elisp Video Tutorial – Notes
Did you know that you can press C-M-l to invoke the command reposition-window? Here’s an excerpt from its docstring: Make the current definition and/or comment visible. Further invocations move it to the top of the window or toggle the visibility of comments that precede it.
A while ago I wrote mu4e-delay, a package (based heavily on gnus-delay), to add a customisable delay to outgoing mail so that a sent email could be “undone” before the delay period had passed. This was spectacularly useful for me, but now Benny Andresen has put together the superior mu4e-send-delay, which improves on my package in several ways.
The key features of mu4e-send-delay are (from the github page):
mu4e context support
Saves scheduled mails to mu4e-drafts-folder
Uses an emacs timer to check Drafts if a mail is scheduled to be sent now
Allows easy edit of the X-Delay header in mu4e-compose-mode
Displays scheduled time in mu4e-view
Doesn’t send if mail is currently being edited
Works with attachments
The last four points are all improvements over the original mu4e-delay, with the last two being the most important. I’d encourage any mu4e-delay users to switch over to mu4e-send-delay. I have, and I’ve not looked back!
I hack a fair bit of Ruby, usually in a pretty plain way to solve a text-based problem; I can write scripts to do what I need, because my problems aren’t too large, but what I write isn’t elegant. Just recently I started using Rubocop in Emacs, and wow, what a great tool! It’s making the code better and me a better coder.
Rubocop is written by Bozhidar Batsov, who also made rubocop-emacs to integrate it into Emacs. I’ve had that running for a while and found it useful for pointing out unused variables and things like that, but otherwise it didn’t seem to do a lot. That’s because I had it turned on but wasn’t actually using it.
Here’s a short Ruby script:
What it looks like in my Emacs with rubocop-mode on:
The lines in red are highlighted because there’s a problem: in this case, the variables aren’t reused so, as the script stands, they could be removed without affecting anything.
Now, if I run rubocop on this script at the command line, it tells me helpful things about making the script better. If I run M-x rubocop-check-current-file in Emacs it tells me the same helpful things. But if I run M-x rubocop-autocorrect-current-file it fixes the problems.
Here’s the output:
-*- mode: compilation; default-directory: "~/" -*-
Compilation started at Thu Oct 13 20:28:30
rubocop -a --format emacs /home/wtd/rubocop.rb
/home/wtd/rubocop.rb:3:6: C: [Corrected] Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.
/home/wtd/rubocop.rb:5:1: W: Useless assignment to variable - `x`.
/home/wtd/rubocop.rb:7:1: W: Useless assignment to variable - `y`.
/home/wtd/rubocop.rb:7:5: C: [Corrected] Use `%w` or `%W` for an array of words.
/home/wtd/rubocop.rb:9:1: C: [Corrected] Favor modifier `if` usage when having a single-line body. Another good alternative is the usage of control flow `&&`/`||`.
/home/wtd/rubocop.rb:11:1: C: [Corrected] Redundant `else`-clause.
Compilation exited abnormally with code 1 at Thu Oct 13 20:28:30
(I can hit Enter on any of those lines and jump to that line in the code.)
All of the corrections are corrected and the warnings are left alone. The code is changed to this:
Magic! It’s up to me to decide what to do with x and y, but all the style problems are fixed. That’s just a tiny example. Rubocop does a lot more, and I’ve been going through scripts changing CGI::parse to CGI.parse or foo["bar"] to foo[:bar] and all sorts of other small things that make them more readable and consistent.
The one thing I didn’t like about Rubocop was its preference for ‘single’ quotes over “double” quotes, so I put this in a new ~/.rubocop.yml file to tell it how I like things:
Currently there’s a lot of fuzz about concurrency in Emacs again. The topic
rekindled on emacs-devel and promptly made it to Reddit as well1. The
lack of proper concurrency is a long-standing issue in Emacs, vexing users and
developers alike. Users are frustrated to see Emacs freezing every now and
then, and developers are frustrated because so far they are unable to fix this
source of constant frustration without major pain.
The Concurrency Branch
There’s unanimous agreement that Emacs needs better support for concurrency, and
indeed over the last few years Tom Tromey (of ELPA fame) and others worked on
concurrency for Emacs Lisp—dubbed as “the concurrency branch” in the community.
The branch has come very far, to the point where there’s prospect of actually
merging it into master.
I find that very impressive, and don’t dare to imagine what huge amount of pain
the developers most have gone through. Emacs is riddled with a tremendous
amount of mutable global state—the mortal enemy of concurrency. It’s all over
the place, in the editor as well as in the language: The mere existence of
global dynamic variables makes proper parallelism impossible to implement, not
to mention all the implicit state in variables like match-data.
It’s no surprise then that the concurrency branch doesn’t even attempt to
implement true parallelism. Instead it provides a model of concurrency without
parallelism that’s very similar to that of other dynamic languages such as
Python or Ruby. As usual Emacs’ great documentation is a good
resource to understand how this model is implemented in Emacs Lisp.
Essentially the branch adds threads to Emacs Lisp. Like Python a global
interpreter lock ensures that only a single thread runs at any given time to
avoid any race conditions and inconsistencies in the interpreter state. Unlike
Python which sort of preempts threads by automatically releasing the interpreter
lock and switching threads after every 100 byte code instructions threads in
Emacs Lisp will be entirely cooperative. Emacs only releases the lock and
switches threads when blocking for IO or when thread-yield is explicitly
This simple form of concurrency is the result of a couple of year’s work: The
beginnings of the branch date back to 2012, maybe even earlier. It’s quite a
step forward for Emacs Lisp in terms of clarifying the semantics of the
language, but in the cold light of the day does it add much?
Heaven Or Hell?
The branch is generally met with uncritical enthusiasm. Talking to other Emacs
Lisp developers and users I have the impression that many people naively believe
that the concurrency branch is the immediate cure to all the blocking operations
that interrupt their Emacs workflow. I don’t think that’s the case, for so many
Even if the branch offered a good solution it’ll take years, many years, before
it hits downstream packages. There’s no story about backwards compatibility in
the branch: A package that uses threads won’t run on older Emacs versions no
matter what. This alone stops popular packages from using threads for a couple
of years; they need to wait until Emacs versions with concurrency are
sufficiently widely spread before they can drop compatibility with older
versions and start to use threads. And, well, that’s just the start: Embracing
threads for blocking operations involves a major refactoring.
Remember that threads will be cooperative. Shoving a blocking operation to
another thread won’t change anything: It’ll block Emacs just as it used to, just
on a different thread. To truly make it non-blocking it needs to be carefully
enriched with thread-yield at strategic spots and audited for potential race
conditions— the assumption of a single-thread environment that all Emacs Lisp
code implicitly carries with it suddenly doesn’t hold anymore.
Communicating between threads will be challenging, too: Emacs will offer mutexes
for locking and conditions for events between threads. Code that makes use of
threads needs to be rewritten around these primitives for communication.
That’s not a simple straight-forward change. It fundamentally changes the look
of code, and the mental model behind it, moving it from a local sequence of
instructions to a distributed scattered mess of small disconnected pieces. As a
result code is much harder to understand, much harder to debug, and much less
welcoming to new developers.
We already see that in Emacs, with asynchronous processes which use callbacks to
communicate state back to Emacs. Flycheck makes heavy use of asynchronous
processes for responsive syntax checking. Conceptually that’s quite simple and
straightforward, but the implementation of syntax checking is scattered over
many different callbacks. Thus what’s supposed to be a simple operation—and is
in languages with modern concurrency concepts—is the single hardest piece of
code in Flycheck.
The Past, The Present, The Future?
The concurrency branch is hailed as Emacs Lisp’s future, but to me it looks like
a terrible blast from the past. It’s the nineties-style Java-way of
concurrency: Threads, yield, mutexes, locks. And a long tearful story of races,
deadlocks, pain and suffering. It’s been a single big failure in every major
programming language, Java first and foremost, how come we believe that it would
be a success in Emacs?
I don’t doubt that some packages will profit from threads but in many cases
they’ll be too hard to use, and developers will just continue with synchronous
operations for the sake of simplicity. That’s simply what we’ve seen for years
in GUI applications that were limited to the thread model of concurrency. It’s
only in recent years with better concurrency models that GUI applications became
Threads are broken because they leak the details of execution into concurrency
code. What Emacs actually needs is a decent simple concurrency model that’s
independent of execution and abstracts the implementation of concurrency. An
ubiquitous model that’s applicable not only to concurrency execution but to all
sorts of concurrency like asynchronous processes or asynchronous IO. A model
that can not only move expensive computations into background but also simplify
asynchronous processes and networking without mucking about with callbacks.
We already know such a model: Futures. The concept is as old as threads but
became a huge success in many different programming language in recent years.
It’s futures that brought concurrent programming to the masses.
To have a future Emacs Lisp needs a Future.
I’m not linking to Reddit by principle but I’m told that the discussion is
not too bad surprisingly—quite unusual for Reddit. I didn’t read it
anyway—again, by principle. ↩
An Emacs’ configuration is an Emacs Lisp (Elisp) program. Whether you write it by hand or using the Easy Customization GUI it is still a program. Some of us write it once and never touch it for years. I’ve done that and it works well. Some of us make changes daily, even hourly. I’ve done that too and it works well. When non Emacsers hear stories about this never ending program they shudder in horror and I don’t blame them. Configuring a text editor for multiple years does sound horrible! What is really happening here though, are all Emacsers sadists?
No, not really. Instead they are creators, makers, writers, and weavers of that which can be easily represented as plain text. They are programmers, too. Of course, that is the easy one! Unfortunately, that is the one that instantly kills any conversation (in some contexts). What people miss out on though is that its not just programmers who use Emacs. So do composers. So do publishers. So do finite element analysts. So do pen testers. So do screenwriters. So do hardware designers. Every Emacs configuration is an opportunity to learn something about something totally new to you! What comes to mind here is where Emacs configurations might play a role in interviews.
One of the stories going around is that during job interviews you should be able to cite an open source project so your interviewers can review it. Great idea. Does it ever really happen? (I’m looking for your feedback here). My Emacs’ configuration is a labor of love. It contains perfection, neglect, and horror. It is all a trade-off. Every single line means something to me and I’d love to share with anyone interested why I did what I did there. It is fun to share because you always learn something new. Every single time you learn something new when you mutually share.
This is my story why Emacs’s is an infinite program that would reveal more during a job interview than any personality profiling test out there.
“The hardest bug I ever debugged in my life was a concurrency bug; the second hardest wasn’t even close (and thankfully, I didn’t try to solve it at the same time).” — John Wiegley, Emacs maintainer, on Emacs Lisp’s future, 09 October 2016
-1:-- Concurrency (Post William Denton)--L0--C0--October 12, 2016 01:03 AM
Four Saturdays ago, on September 17, Emacs 25 was finally released. Almost two
years before that, I wrote a post predicting a few Big things to expect from
Emacs 25. Throughout the months since then, I’ve also been reporting interesting
new features as they arrived on the dev builds. Today, we compile a list of all
of those news posts, and review which predictions I actually got right.
For the convenience of those looking for actually practical information, I feel
we should start with a list of the posts. I must strive to be clear that this
is not a comprehensive list of new features. Not by a mile! If you want
everything, you can have a look at the news file that ships with Emacs,
/etc/NEWS, or you can read Mickey Petersen’s commented version.
The list below merely sums up most (not even all) of the features that piqued
my interest over the last couple of years.
If you’re short on time, I personally recommend checking out char-folding
search (1), archive priorities (17), and the comment-line command (4), which are all
features you might not realize are there. The round-quotes in Help buffers (2) and
the improved query-replace history (3) are also among my favorites, but you don’t
need to do anything special to see them in action.
Now, for the indulgence of those looking for more than just practical
information. On the aforementioned post, I talked about 6 things I hoped to see
by the time Emacs 25 came out.
Moving the code base to git
This one even had a schedule date when I wrote
the post, so it obviously doesn’t count as a prediction. Still, I’m
extremely glad it happened as I would never have contributed myself if not
for this change.
Dynamic library loading
Now this is exciting. I originally wrote it was
“looking almost in shape for release”, but I have no idea what led me to
say that. This feature actually almost didn’t make it into release. It only
got merged to the emacs-25 branch more than one year later, after the
feature-freeze took place!
Nonetheless, it’s finally out and about, and I’m eager to see what comes
out of it. If you’re interested, it’s actually very easy to get started
(well… easy by C-coding standards). Aurélien Aptel has a super short
tutorial on how to write, compile, and use a dynamic module in Emacs.
Concurrency in Elisp
I’ll count this as a half point. We don’t have proper
concurrency in Elisp yet, and whether that’s something we want is still an
ongoing discussion. Still, most of the points in my rant have already been
addressed. The packages list does refresh asynchronously now (despite the
lack of concurrency), and several optimizations have been made which speed
up the actual rendering of the list.
A Better Package Menu
I shouldn’t have to say much here. The last 5 links on
list above are all improvements to the package menu. While there’s still
room for improvement, it’s quite ahead of where it was 2 years ago. Better
dependency management, asynchronous refreshing, and more filtering options
were all much needed improvements. Meanwhile, archive priorities are a nice
cherry to top of it all off.
A More Robust Customize Interface
Out of the two issues that led me to
write this point, one of them has been fixed (custom-theme-load-path is no
longer a defcustom). Still, I’m counting this as a miss. Over the last
couple of years I’ve seen other fundamental issues with the Customize
interface be reported, and there’s still quite a bit of work to be done here.
Well, OK. We still don’t have namespaces. Honestly, though, it
doesn’t bother me anymore. I’ve released two packages, Names and Nameless,
which are available on Elpa and help mitigate the the lack of namespaces. I
use Nameless for all my Elisp coding now and that’s the end of the story
Summarizing, even if we exclude the Git point (which wasn’t really a
prediction), it’s a 2½ out of 5 (or 3½ if we count namespaces). That’s a
pretty good outcome considering I had never even made a single contribution to
Emacs core when I wrote that post. I’d love to write another one of those, but
I’m not nearly as involved in the news as I was 2 years ago. Maybe in a couple
of months I’ll manage to catch up.
In Emacs today, there’s no way to find all the callers of a function
or macro. Most Emacsers just grab their favourite text search tool.
Sadly, dumb text search knows nothing of syntax.
We can do better. It just wouldn’t be Emacs without a little fanatical
tool building. Let’s make this happen.
Everyone know how to parse lisp, right? It’s just read.
It turns out that a homoiconic language is hard to parse when you want
to know where you found the code in the first place. In a language
with a separate AST, the AST type includes file positions. In
lisp, you just have… a list. No frills.
I briefly explored writing my own parser before coming to my
senses. Did you know the following is legal elisp?
Anyway, I totally ripped off was inspired by similar functionality
in el-search. read
moves point to the end of the expression read, and you can use
scan-sexps to find the beginning. Using this technique
recursively, you can find the position of every form in a file.
OK, we’ve parsed our code, preserving positions. Which forms actually
look like function calls?
This requires a little thought. Here are some tricky examples:
We can’t simply walk the list: (foo) may or may not be a function
call, depending on context. To model context, we build a ‘path’ that
describes the contextual position of the current form.
A path is just a list that shows the first element of all the
enclosing forms, plus our position within it. For example, given the
code (let (x) (bar) (setq x (foo))), we build a path ((setq . 2)
(let . 3)) when looking at the (foo).
This gives us enough context to recognise function calls in normal
code. “Aha!”, says the experienced lisper. “What about macros?”
Well, elisp-refs understands a few common macros. Most macros just
evaluate most of their arguments. This means we can just walk the
form and spot most function calls.
This isn’t perfect, but it works very well in practice. We also
provide an elisp-refs-symbol command that finds all references to a
symbol, regardless of its position in forms.
It turns out that Emacs has a ton of elisp. My current instance
has loaded three quarters of a million lines of code. Emacs actually
lazily loads files, so that’s only the functionality that I use!
So, uh, a little optimisation was needed. I wrote a benchmark script
and learnt how to make elisp fast.
Firstly, avoid doing work. elisp-refs needs to calculate form
positions, so users can jump to the file at the correct
location. However, if a form doesn’t contain any matches, we don’t
need to do this expensive calculation at all.
Secondly, find shortcuts. Emacs has a little-known variable
called read-with-symbol-positions. This variable reports all the
symbols read when parsing a form. If we’re looking for function calls
to some-func, and there’s no reference to the symbol some-func, we
can skip that form entirely.
Thirdly, use C functions. CS algorithms says that building a hash
map gives you fast lookup. In elisp-refs, we use assoc with small
alists, because C functions are fast and most lists weren’t big enough
to benefit from the O(1) lookup.
Fourthly, write impure functions. Elisp provides various ways to
preserve the state of the current buffer, particularly
save-excursion and with-current-buffer. This bookkeeping is
expensive, so elisp-refs just creates its own temporary buffers and
When all else fails, cheat. elisp-refs reports its progress, which
doesn’t make it faster, but it certainly feels like it.
We have something that works, and we can search in all the code in in
the current Emacs instance in less than 10 seconds. How do we display
Initially, I just displayed each form in the results buffer. It turns
out that the context is useful, so added the rest of the matching lines
too. To avoid confusion, I underlined the section of the code that
matched the search.
The second prototype also had some custom faces for styling. This was
an improvement, but it forces all Emacs theme authors to add support
for the faces defined in our package.
It still didn’t work as well as I’d hoped. When I get stuck with UI,
I ask ‘what would magit do?’. I decided that magit would take
advantage of existing Emacs faces.
The final version uses standard elisp highlighting, but highlights the
surrounding context as comments. This means it will match your
favourite colour scheme, and new users should find the UI familiar.
I added a few other flourishes too. You can see that results in the
second prototype were often very indented. The final version unindents
each result, to make the matches easier to read quickly.
Today I decided to write a little bit of documentation for my most basic version of .emacs or init.el that I use. It gets me up to 80% or so of full productivity for basic text editing on a new installation.
At Affectv we use a wide range of editors: Sublime, Atom, Emacs, Pycharm, IntelliJ... Actually only two people use the same editor! As such, from time to time I see things in other people's editors that I would like to have as well. So, yesterday I decided to improve on some configuration settings on Spacemacs.
Click for multiple-cursors
I saw this on Jordi's Sublime, and it is much more comfortable than using more-like-this or similar helper functions, even if I need to use the trackpad to do so. After all, a multi-cursor edit (proper edit, not as a substitute for a macro) is rare enough that I can tolerate leaving the home row. Easy enough to configure thanks to Magnar Sveen.
I have always loved how clean vim's folding works, and how Sublime has this nice folding. Then I found origami-mode and my emacs-life was complete. I tweaked a little the folding functions so that minimap was updated on fold (for some reason it is not, I guess minimap is tied to the "modified" hook or similar). I bound z and Z (and A-z which maps to æ in Colemak) to the basic fold operations.
For some reason just advising the functions with after didn't work, this is not great but does work. I left the Z bindings as they are, since I have not used them yet, and will probably delete them if I keep not using them.
Execution overlays in Ensime (Scala)
I saw this for Cider in the emacs church meeting from August, and heard @fommil (I think it was him) mention that it was coming to ensime. And indeed it was. And it's easy enough to use C-c C-v C-r (thing of it as extended command, eval, region to remember), given an open inferior Scala interpreter. Symbol prettify does not apply to overlays, so you need to customise the arrow used therein.
A Kanban board is a way to visualise your work and help you get more work done. You organise your work into tasks that need completeing and use the board to show the state of each card. Kanban encourages you to get work finished before starting new work.
The amazing Emacs Org-mode can be used to create a very fast and easy to use Kanban board that is with you where ever you are.
Update: Using Org-mode doesnt give me everything I want from a Kanban board, but it was an interesting exersice. For now, I am just sticking to my list view of a Kanban board.
Org-mode is built into Emacs / Spacemacs so there is no need to install any packages or layers for any of the following.
Designing a kanban board
The columns on your kanban board represent the state of work and represent your typical workflow. You can represent the states as the most generic todo, doing, done workflow, or anything more specific that adds value to how you manage work.
I have been using kanban for a while, so I am using a five stage workflow: planning, in progress, blocked, review, done
planning - work I’d like to do that needs organising so I can do it.
in progress - what I am currently working on. I try and keep this to a minimum so I get things done
blocked - things I’ve started working on but currently arent able to complete
review - work I have completed. Check if there are any follow on tasks or lessons learnt
done - things I have completed. Gives feeling of satisfaction
Create a new file by opening a new buffer M-x find-files and type in the new file name, ending in .org. Any files with a .org filename extension will automatically set the Emacs major mode to Org-mode.
I use a file called kanban.org for my kanban board.
SPC f f
Create a kanban board
Lets assume you created a file called kanban.org. Edit this file and create a table for the kanban board. You can start creating ths manually by typing | for the table layout or use M-x org-table-create and enter the number of columns and rows for the table. For example, to create for a table with 5 columns and 3 rows, you would speciify 5x3
Add the names of the kanban board in the first row of the table. If you did not use M-x org-table-create then add a header row with M-x org-table-insert-hline.
In my kanban board, this gives
Adding tasks to the kanban board
Each item on the board represents a task and we use the Org-mode interal link to jump from the board to the details of the task. To create a link of the same name as the task, simply type the name inside double square brakets [].
Moving the tasks across the board
Its easy enough to move the columns around with Alt - <arrow-keys> in org-mode, but there is not a single keybinding to move a cell.
To move the individual tasks between the columns use selective cut and paste:
Move the cursor to the cell you want to move and use C-c C-x C-w
Use TAB to move to the new cell
Paste/Yank the value into the new cell using C-c C-x C-y
However, simply moving the task does not update the Org-mode stage. As each task is a link, I can click on that link and I am taken to the task and can easily update the task stage to match the board.
It would be great if moving the tasks on the board updated the associated task stage and vice versa.
El Kanban - updating the board from task stage changes
I found the El Kanban package that will updated the kanban board based on the task org-mode stages. This uses the Org-mode table format directive that you run each time you want to update the board.
I installed this package and it did pull in my custom org-mode stages for the headers. Unfortunately it did not pull in the tasks to the board, so I will either need to fix the package or find another solution.
When I got started with Lua, everything about it seemed to be the
opposite of what I would like in a language, especially coming
from Racket, Clojure, OCaml, and Erlang. It's unabashedly
imperative, has nils everywhere, and lacks a macro system or any
kind of static analysis. But now after spending over a year with
it, I've developed a fondness for it, and the reasons are not what
I would have expected.
The most obvious strength of Lua is its relentless
simplicity. The small number of concepts you have to keep in your
head when writing Lua can really help you focus, and it picks just
the right concepts to build on. For
instance, the module system is largely just constructed out of
tables and closures. What more do you need? It brings to mind the
simplicity of Scheme and its "perfection is achieved when there is
nothing left to remove" philosophy, but I believe Scheme's
insistence on lists as the fundamental data type actually does a
great disservice—fitting sequential data into an associative
data type is much more natural than going the other way around.
But what you most often hear touted as Lua's appeal is actually
in its ease of embedding. Now obviously when people talk about
this they are usually referring to how seamless it is to add the
Lua runtime to a large C program and expose its functionality to
code that can be written by the end user. And this is huge;
empowering users to control your programs by doing their own
coding pays major dividends, and here again Lua's simplicity means
more users are likely to be able to take advantage of it. But even
though I don't write large C programs, I found that the ability to
embed Lua execution inside a Lua program is very
This advantage is not at all intuitive if you haven't seen it, but one
distinguishing factor of Lua is that it allows sandboxed execution
contexts to be constructed trivially:
In these three lines the code loaded from the user_code
string will run with no access to any functions outside
the api table you provide. (In practice you would also
include a whitelist of pure functions for tables, strings, math,
etc.) But that's all it takes to allow user code to run inside
your own limited sandbox.
Now Lua lacks any notion of first-class interfaces. The idea of
passing a table in which must conform to a certain specified shape
of fields and functions is fully ad-hoc and must be communicated
entirely through documentation. And unfortunately it's somewhat
unusual for Lua programmers to specify which functions in a module
are for public consumption vs which are internal implementation
details. But first-class sandboxes as extension points actually
address many of the same problems as interfaces! Instead of saying
"you must provide an implementation of this interface that has
these fields and these functions" you can say "Provide your own
code here; you will have access to call only this limited subset
of functions which we've designated as a public API. The
implementation details aren't even visible to you."
Now this can break down badly when the sandbox doesn't
expose enough functionality to get the job done. This is why it's
important not to tack on "scriptability" as a checkbox you fulfill
at the end, but to embrace
reprogrammability from the very start. If you use the same
methods to build the program in the first place as the end users
use to customize it, you force yourself to be honest and to give
the end users everything they need.
So from this perspective, we can agree that yes, Lua's imperative
nature and sloppy semantics (especially around nils) put it at a
disadvantage for large codebases vs languages that have the
advantage of immutability and/or intelligent type systems. But the
fact that it offers setfenv makes it uniquely suited
for constructing larger codebases out of small
codebases. This is the approach I take in my game
I have four separate execution contexts, none of which have much
more than 3,000 lines of code in them. Each small codebase is
perfectly manageable on its own, and the interfaces between them
are concise and clearly-defined despite Lua lacking first-class
features for defining interfaces as we normally think of them.
 I have found that this simplicity also
makes it a great choice for teaching
programming, especially to younger kids who haven't reached
the developmental stages where they can appreciate the more
approach espoused by Racket.
 I know this method has a bad reputation
be done well. There is a bit of awkwardness around ambiguity
between array-like tables and key/value tables, but it is not
nearly as awkward as using alists.
Recently, I've been looking at
didn't manage to fully figure out their CMake build system for
tutorials: although each tutorial has a CMakeLists.txt, it's only
possible to build them all at once.
So I decided to replace CMakeLists.txt with a good-old Makefile;
how hard can it be? Concerning includes, not at all hard: the missing
files are found with counsel-locate and added to the include path.
But I had some trouble matching a missing ld dependency to a library
file. Fixed it with a bunch of googling and guesswork; I still wonder
if there's a better way. But in the process, I've found this useful
readelf --syms libGL.so
which produces e.g.:
Symbol table '.dynsym' contains 2732 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 000000000004faf0 0 SECTION LOCAL DEFAULT 8
2: 00000000000e8f20 0 FUNC GLOBAL DEFAULT 11 glGetIntegerui64i_vNV
3: 00000000000e13e0 0 FUNC GLOBAL DEFAULT 11 glGetMultiTexEnvfvEXT
4: 00000000000d7440 0 FUNC GLOBAL DEFAULT 11 glProgramUniform2uiv
5: 00000000000cfdc0 0 FUNC GLOBAL DEFAULT 11 glMultiTexCoord3sv
This is a pretty good representation of a binary file: in this
example, instead of one megabyte of gibberish I see a bit more than
2732 lines describing the functions this file uses and provides.
Viewing the symbol list automatically
I liked the above representation so much that I want to see it by
default. In Emacs, it's pretty easy to do with auto-mode-alist:
The idea is very simple: elf-mode is a toggle function that replaces
the buffer contents with the shell command output. It carefully uses
read-only-mode and set-buffer-modified-p so that the file will not
be overwritten by accident with the symbol names.
Using autoload to avoid overhead
As you might imagine, looking at binaries isn't really a common
task. Is it worth to be dragging this code around from now on, loading
it on each start? The answer is yes, of course. Since the actual cost
is negligible until the feature is used.
If you look above, elf-mode has an ;;;###autoload cookie before
it. The cookie results in this line in my loaddefs.el:
My init.el always loads loaddefs.el, but never loads ora-elf.el
where the function is defined. That file is only loaded when the
function elf-mode is called for the first time. The above autoload
statement simply instructs Emacs to load a particular file when
elf-mode needs to be called.
When you use the package manager, the autoloads file is generated and
loaded for you automatically:
Here, the package manager will always load ace-link-autoloads.el,
which instructs Emacs to load ace-link.el when one of the
;;;###autoload functions is called and ace-link.el isn't yet
As an example of how useful delayed loading is: my 6000 line
config starts in 1.8 seconds.
About 40% of that time is spent on (package-initialize), which I
assume is the package manager loading all those *-autoloads.el files
that I have in my elpa/.
Let me know if there's interest to have elf-mode on MELPA. Also, if
anyone knows how to set mode automatically based on the first few
chars of the file (all binaries seem to start with ^?ELF), I'd like
to know that as well. Happy hacking!
The new racer-describe command actually renders the markdown in
rustdoc comments. Since we’re showing a separate buffer, we can render
the docs and throw away the markdown syntax. We can even convert
external hyperlinks to clickable links!
This is a really nice example of composing Emacs functionality. Since
we can easily highlight code snippets (it’s an editor!), we actually
apply syntax highlighting to inline code! Note how Vec and T are
highlighted as types in the above screenshot.
Whilst we don’t use *Help* buffers, we extend the same keymaps, so
all the relevant help shortcuts just work too.
We have hit a few teething issues in racer (namely
#597) but it’s
changed the way I explore Rust APIs. It’s particularly useful for
learning functionality via examples, without worrying about
I hope it will also encourage users to write great docstrings for
their own projects.