Grant Rettke: Techne (Emacs Friendly Keyboard): Operations Keys

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)

Row Four Five Six Seven Eight
Two Hyper ⬖ Super ⬙ Meta ⬗ Control ⬘ Space ⭕
One Alt ⎇ GUI ⃟ Ultra ◆ Shift ⇧ Enter ⎆


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.

-1:-- Techne (Emacs Friendly Keyboard): Operations Keys (Post Grant)--L0--C0--October 27, 2016 02:03 AM

Irreal: A Literate Programming Example with Org Mode

Arne Babenhauserheide has posted a nice example of literate programming with Org mode. It's a bare-bones example but shows what you can do including stitching code blocks together.

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.

-1:-- A Literate Programming Example with Org Mode (Post jcs)--L0--C0--October 26, 2016 06:02 PM

Yaniv Gilad: use-package’s :config vs. :init

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
-1:-- use-package’s :config vs. :init (Post Yaniv)--L0--C0--October 25, 2016 02:36 PM

Pragmatic Emacs: Fun with fonts

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):

(set-frame-font "DejaVu Sans Mono-14" nil t)
(set-frame-font "Fantasque Sans Mono-16" nil t)
(set-frame-font "Source Code Pro-14" nil t)
(set-frame-font "Monaco-14" nil t)
(set-frame-font "Cousine-14" nil t)

I’ve decided to go with Google’s Cousine font at the moment, so I add the following to my emacs config file to make the choice permanent:

(setq default-frame-alist '((font . "Cousine-14")))
-1:-- Fun with fonts (Post Ben Maughan)--L0--C0--October 24, 2016 09:07 PM

Irreal: Reproducible Research Webinar

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
  • Numerical reproducibility
  • 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.

-1:-- Reproducible Research Webinar (Post jcs)--L0--C0--October 24, 2016 04:37 PM

sachachua: 2016-10-24 Emacs News

Links from, /r/orgmode, /r/spacemacs, Hacker News,, Youtube, the changes to the Emacs NEWS file, and emacs-devel.

Past Emacs News round-ups

The post 2016-10-24 Emacs News appeared first on sacha chua :: living an awesome life.

-1:-- 2016-10-24 Emacs News (Post Sacha Chua)--L0--C0--October 24, 2016 05:32 AM

Marcin Borkowski: locate-dominating-file

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.
-1:-- locate-dominating-file (Post)--L0--C0--October 22, 2016 06:22 AM

Sebastian Wiesner: A Future For Concurrency In Emacs Lisp

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 processes.

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:

(let* ((command (list "foo" ...))
      (return-code (apply #'call-process (car command)
                          nil nil nil (cdr command))))
 (when (= return-code 0)
   (with-current-buffer "*result*"
     (insert "some stuff"))))

And its asynchronous form:

(let* ((command (list "foo" ...))
      (process (apply #""start-process "foo" nil command)))
   (lambda (process state)
     (when (and (memq (process-status process) '(signal exit))
                (eq (process-exit-status process) 0))
       (with-current-buffer "*result*"
         (insert "some stuff"))))))

Wouldn’t it be so much better if we could just do this instead:

 (let-async* ((command (list "foo" ...))
              (result (apply #'start-process-future nil nil command)))
   (when (and (memq (process-result-status process) '(signal exit))
              (= (process-result-exit-status result) 0))
     (with-current-buffer "*result*"
       (insert "some stuff")))))

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 now.

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 Emacs Lisp!

-1:-- A Future For Concurrency In Emacs Lisp (Post)--L0--C0--October 20, 2016 10:00 PM

Yaniv Gilad: Elisp Video Tutorial – Notes

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
-1:-- Elisp Video Tutorial – Notes (Post Yaniv)--L0--C0--October 19, 2016 02:12 AM

Marcin Borkowski: reposition-window

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.
-1:-- reposition-window (Post)--L0--C0--October 17, 2016 08:09 PM

sachachua: 2016-10-17 Emacs News

Links from, /r/orgmode, /r/spacemacs, Hacker News,, Youtube, the changes to the Emacs NEWS file, and emacs-devel.

Past Emacs News round-ups

The post 2016-10-17 Emacs News appeared first on sacha chua :: living an awesome life.

-1:-- 2016-10-17 Emacs News (Post Sacha Chua)--L0--C0--October 17, 2016 05:10 AM

Pragmatic Emacs: mu4e-delay is dead, long live mu4e-send-delay

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!

-1:-- mu4e-delay is dead, long live mu4e-send-delay (Post Ben Maughan)--L0--C0--October 16, 2016 11:05 PM

William Denton: Rubocop

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:

#!/usr/bin/env ruby

puts 'This is an example.'

x = 5

y = ["foo", "bar", "baz"]

if 2 > 1
  puts "Yes, 2 > 1"

What it looks like in my Emacs with rubocop-mode on:

Before. Before.

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
During. During.

(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:

#!/usr/bin/env ruby

puts "This is an example."

x = 5

y = %w(foo bar baz)

puts "Yes, 2 > 1" if 2 > 1
After. After.

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:

  EnforcedStyle: double_quotes

Bozhidar Batsov: thank you.

-1:-- Rubocop (Post William Denton)--L0--C0--October 14, 2016 01:09 AM

Sebastian Wiesner: A Blast From The Past: The Tale Of Concurrency In Emacs

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 called.

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 different reasons.

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 highly concurrent.

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.

  1. 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.

-1:-- A Blast From The Past: The Tale Of Concurrency In Emacs (Post)--L0--C0--October 13, 2016 10:00 PM

Grant Rettke: Emacs: The Infinite Program or The Ultimate Interview

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.

-1:-- Emacs: The Infinite Program or The Ultimate Interview (Post Grant)--L0--C0--October 13, 2016 01:25 AM

William Denton: Concurrency

“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

Endless Parentheses: Emacs 25 is out! What are the new features and what were my predictions

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.

News posts

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.

  1. Easily search for non-ASCII characters (char-folding search)
  2. Round quotes in Help buffers
  3. Query-replace history is enhanced
  4. The comment-line command
  5. The seq.el library
  6. The let-alist library
  7. The map.el library
  8. Have prettify-symbols-mode reveal the symbol at point
  9. More flow control macros
  10. EWW improvements
  11. Easily install multifile package from a directory
  12. Better Rectangles
  13. Better dependency management
  14. User-selected packages
  15. Asynchronous Package Menu
  16. Filtering by status and archive
  17. Archive priorities and downgrading packages

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.

Reviewing predictions

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 for me.

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.

Comment on this.

-1:-- Emacs 25 is out! What are the new features and what were my predictions (Post)--L0--C0--October 11, 2016 12:00 AM

Timo Geusch: How to build GNU Emacs 25.1 on (X)Ubuntu 16.04

Explain how to build GNU Emacs 25.1 on Ubuntu Linux

The post How to build GNU Emacs 25.1 on (X)Ubuntu 16.04 appeared first on The Lone C++ Coder's Blog.

-1:-- How to build GNU Emacs 25.1 on (X)Ubuntu 16.04 (Post Timo Geusch)--L0--C0--October 08, 2016 08:55 PM

Wilfred Hughes: Searching A Million Lines Of Lisp

Time for another Emacs adventure!

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?

;; Variables can start with numbers:
(let ((0x0 1))
  ;; And a backquote does not have to immediately precede the
  ;; expression it's quoting:
  ;; foo
  (+ ,0x0))


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:

;; Not references to `foo' as a function.
(defun some-func (foo))
(lambda (foo))
(let (foo))
(let ((foo)))

;; Calls to `foo'.
(lambda (x) (foo))
(let (x) (foo))
(let ((x (foo))) (foo))
(funcall 'foo)
;; Not necessarily a call, but definitely a reference to 
;; the function `foo'.
(a-func #'foo)

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 dirties them.

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 results?

first prototype, showing the matching forms in isolation

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.

second prototype, adding context and custom faces

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.

final UI, using normal syntax highlighting

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.


elisp-refs is available on GitHub, available on MELPA, and it’s ready for your use! Go forth, and search your elisp!

-1:-- Searching A Million Lines Of Lisp (Post Wilfred Hughes ( 30, 2016 12:00 AM

Flickr tag 'emacs': emacs-org-babel-plantuml

ohyecloudy posted a photo:


-1:-- emacs-org-babel-plantuml (Post ohyecloudy ( 28, 2016 06:36 AM

Got Emacs?: Windows Binaries are out too

Looks like the binaries for Windows 32 and 64 bit can be found in the pretest folder, done by Philip Lord.  If you have any worries about downloading from sourceforge that is.
-1:-- Windows Binaries are out too (Post sivaram ( 18, 2016 12:28 PM

Got Emacs?: Emacs 25.1 released

Finally, Emacs 25.1 is released.  The windows binaries would take some time to turn up. Hopefully the new TLS features would help in setting up mail connectivity easier to deal with.
-1:-- Emacs 25.1 released (Post sivaram ( 18, 2016 02:32 AM

Mathias Dahl: barebones.el - the most basic .emacs file I use

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.

It can be found here: (download the barebones.el file)

Perhaps someone else will find it useful, as it is or as a simple start for their own Emacs customizations.


-1:-- barebones.el - the most basic .emacs file I use (Post Mathias Dahl ( 12, 2016 09:35 PM

Rubén Berenguel: More emacs configuration tweaks (multiple-cursor on click, minimap, code folding, ensime eval overlays)

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.

(global-unset-key (kbd "M-<down-mouse-1>"))
(global-set-key (kbd "M-<mouse-1>") 'mc/add-cursor-on-click)


Also from Sublime, I had this on my old emacs setup. As simple as adding minimap to the list of additional packages and configuring its property group. See animation below.

dotspacemacs-additional-packages '(helm-dash key-chord pig-mode mmm-mode minimap origami ansible)


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.

(eval-after-load 'origami
(defun rb-show-only (buffer point)
(interactive (list (current-buffer) (point)))
(progn (origami-show-only-node buffer point)

(defun rb-toggle-rec (buffer point)
(interactive (list (current-buffer) (point)))
(progn (origami-recursively-toggle-node buffer point)

(define-key evil-normal-state-map "æ" 'rb-show-only)
(define-key evil-normal-state-map "Z" 'origami-toggle-node)
(define-key evil-visual-state-map "Z" 'origami-toggle-node)
(define-key evil-insert-state-map "C-Z" 'origami-toggle-node)
(define-key evil-normal-state-map "z" 'rb-toggle-rec)
(define-key evil-visual-state-map "z" 'rb-toggle-rec)
(define-key evil-insert-state-map "C-z" 'rb-toggle-rec)

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.

-1:-- More emacs configuration tweaks (multiple-cursor on click, minimap, code folding, ensime eval overlays) (Post Rubén Berenguel ( 11, 2016 03:34 PM

John Stevenson: Kanban in Emacs Org-Mode to Get More Work Done

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

Creating Org-mode stages

Its easy to create your own Org-mode stages, to represent the state of work in your Kanban board. Please see my earlier article on Configuring Emacs Org-Mode to Managing Your Tasks

Create an Org-mode file

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 for my kanban board.

Spacemacs Emacs
SPC f f C-x C-f
M-x spacemacs/helm-find-files M-x find-files

Create a kanban board

Lets assume you created a file called 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

Emacs Org-mode table as Kanban board

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 [[]].

Emacs Org-mode table as Kanban board - task entry

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.

Any suggestions are more than welcome.


Thank you.

-1:-- Kanban in Emacs Org-Mode to Get More Work Done (Post)--L0--C0--September 09, 2016 12:38 PM

Raimon Grau: slime inspect + eval

When inspecting some value in slime-inspector, you may want to evaluate forms on that value.

That's what 'e' `slime-inspector-eval' is for.  What the docs do not put very clear is that '*' is the variable bound to the value.

-1:-- slime inspect + eval (Post Raimon Grau ( 30, 2016 01:13 PM

Phil Hagelberg: in which a surprising affinity is pondered

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[1]. 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[2].

There are two advanced features which can be confusing: metatables and coroutines. But when used judiciously, these can allow you to overcome the limitations of normal tables and functions in ways that feel seamless, like the way uses coroutines to hide the fact that many of its functions use asynchronous I/O and avoids structuring everything around callback soup.

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 valuable.

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:

local chunk = assert(loadstring(user_code))
setfenv(chunk, {api = require("my.api")})
return chunk()

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 internal 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.

9 and 9 coffee

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 Bussard, where 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.

[1] 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 abstract, mathematical approach espoused by Racket.

[2] I know this method has a bad reputation because JavaScript and PHP do it very badly, but Lua shows it can 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.

-1:-- in which a surprising affinity is pondered (Post Phil Hagelberg)--L0--C0--August 29, 2016 07:56 PM

(or emacs: elf-mode - view the symbol list in a binary

Recently, I've been looking at libigl. I 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 command:

readelf --syms

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:

(add-to-list 'auto-mode-alist '("\\.\\(?:a\\|so\\)\\'" . elf-mode))

The above code instructs Emacs to call elf-mode function whenever the file name ends in *.a or *.so.

And here's the body of elf-mode:

(defvar-local elf-mode nil)

(defun elf-mode ()
  (let ((inhibit-read-only t))
    (if elf-mode
          (delete-region (point-min) (point-max))
          (insert-file-contents (buffer-file-name))
          (setq elf-mode nil))
      (setq elf-mode t)
      (delete-region (point-min) (point-max))
      (insert (shell-command-to-string
               (format "readelf --syms %s" (buffer-file-name)))))
    (set-buffer-modified-p nil)
    (read-only-mode 1)))

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:

(autoload 'elf-mode "modes/ora-elf" "" t nil)

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:

$ tree elpa/ace-link-20160811.112/

├── ace-link-autoloads.el
├── ace-link.el
├── ace-link.elc
└── ace-link-pkg.el

0 directories, 4 files

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 loaded.

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!

-1:-- elf-mode - view the symbol list in a binary (Post)--L0--C0--August 27, 2016 10:00 PM

Wilfred Hughes: Rustdoc Meets The Self-Documenting Editor

Emacs Lisp has a delightful help system. You can view the docstring for any function under the cursor, making it easy to learn functionality.

Rust goes a step further. All the standard library documentation is written with the source code. This means we can find docs programmatically!

When I learnt that racer recently added support for rustdoc, I couldn’t resist adding support to racer.el.

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 #594 and #597) but it’s changed the way I explore Rust APIs. It’s particularly useful for learning functionality via examples, without worrying about implementation:

I hope it will also encourage users to write great docstrings for their own projects.

Love it? Hate it? Let me know what you think in the /r/rust discussion.

(It’s hot off the press, so there will be bugs. If you find one, please file it on GitHub.)

-1:-- Rustdoc Meets The Self-Documenting Editor (Post Wilfred Hughes ( 27, 2016 12:00 AM

Chen Bin (redguardtoo): Emacs as C++ IDE, easy way

I design a quick and newbie friendly solution.

It works at Linux/OSX/Cygwin (should work at Windows, but I don't develop at Windows).

Setup is minimum. You only need install GNU Global and two Emacs plugins:

Here is the step to step guide.

1 Step 1, create sample projects for experiment

Say I have two projects ~/proj1 and ~/proj2. Both projects will use third party library C++ header files from read-only directory /usr/include.

A new directory ~/obj to store the index files of third party libraries.

mkdir -p ~/{proj1,proj2,obj}

The content of ~/proj2/lib.cpp,

void proj2_hello(int a2, char* b2) {

The content of ~/proj1/main.cpp,

void proj1_hello(int a1, char* b1) {

int main(int argc, char *argv[]) {
    return 0;

2 Step 2, scan C++ code and setup Emacs

Run below command in shell to scan code,

cd /usr/include && MAKEOBJDIRPREFIX=~/obj gtags -O && cd ~/proj1 && gtags && cd ~/proj2 && gtags

After setting up the corresponding Emacs plugins (minimum setup copied from their website is enough), insert below code into ~/.emacs,

;; Please note `file-truename' must be used!
(setenv "GTAGSLIBPATH" (concat "/usr/include"
                               (file-truename "~/proj2")
                               (file-truename "~/proj1")))
(setenv "MAKEOBJDIRPREFIX" (file-truename "~/obj/"))
(setq company-backends '((company-dabbrev-code company-gtags)))

3 Usage

Use the Emacs plugins as usual.

But you need install latest company built on 25th August because I fixed a company issue yesterday.



4 Technical Details (Optional)

Check GNU Global manual to understand environment variables GTAGSLIBPATH and MAKEOBJDIRPREFIX.

-1:-- Emacs as C++ IDE, easy way (Post Chen Bin)--L0--C0--August 25, 2016 02:20 PM