Irreal: Taking Notes in LaTeX

This is astounding. Gilles Castel uses LaTeX to take notes in his Math classes. These aren’t simple notes with a smattering of elementary math symbols; they’re notes for classes like Complex Variables and other advanced topics. Take a look at his post for some examples.

I say it’s astounding because I wouldn’t have believed you could type the LaTeX fast enough to keep up with the instructor. Castel’s goal is to be able to type the LaTeX as fast as the instructor could write the mathematics on the board. To make this possible, Castel uses UltiSnips snippets and Vim. He’s got a number of custom snippets—some quite complicated—that intelligently expand to LaTeX and enable him to enter the mathematics at speed.

Naturally, I started wondering how his procedures would port to Emacs and AUCTeX. I’ve never used UltiSnips but it seems similar to yasnippet except for supporting regular expressions in the keys. On the other hand, AUCTeX provides a lot of functionality that Castel implements with snippets. The post contains several animated GIFs that show how his system works in practice. Watch them and be amazed. If you’re an UltiSnips user, Castel’s snippets are available here for you to try.

Regardless of which editor and snippet package you use, I’d guess that it’s going to take some concentrated practice to get fast enough to actually use in class.

-1:-- Taking Notes in LaTeX (Post jcs)--L0--C0--March 24, 2019 03:54 PM

Irreal: Deleting Blank Lines

The Learn Emacs Twitter feed has a handy tip for dealing with blank lines:

It turns out that the delete-blank-lines command is a little more nuanced than that. The actual rules for invoking it (according to the documentation) are:

  1. If the point is on a blank line surrounded by others, delete all the surrounding blank lines, leaving just one.
  2. If the point is on an isolated blank line, delete that line.
  3. If the point is on a nonblank line, delete any blank lines that immediately follow.

This isn’t a command that I’d use everyday but it seems perfect for cleaning up a text file with lots of blank lines. Often times, I see imported data like this so it’s worth remembering the command.

-1:-- Deleting Blank Lines (Post jcs)--L0--C0--March 23, 2019 03:53 PM

Grant Rettke: VIM Changes Acronym to “VIM Imitates eMacs”

VI is the second editor that I learned. The six commands that I use in it will always be dear to me. Twenty-five years have passed, I still use the same six commands. The landscape has changed a lot though: VIM has taken VI into the stratosphere. My buddy showed me how he uses VIM. … Continue reading "VIM Changes Acronym to “VIM Imitates eMacs”"
-1:-- VIM Changes Acronym to “VIM Imitates eMacs” (Post grant)--L0--C0--March 21, 2019 12:26 PM

Grant Rettke: Customizing SyntaxHighlighter Evolved For Undefined Languages

SyntaxHighlighter Evolved supports a lot of languages. It would be impossible to support all of them. Fortunately many languages are similar enough to ones already supported by it. For example Common Lisp (not supported) is similar enough to Clojure (supported). Therefore you can alias Common Lisp to use Clojure’s formatter. Log into WordPress, Deactive the … Continue reading "Customizing SyntaxHighlighter Evolved For Undefined Languages"
-1:-- Customizing SyntaxHighlighter Evolved For Undefined Languages (Post grant)--L0--C0--March 20, 2019 02:58 AM

Marcin Borkowski: Free Emacs key bindings

As we all know, most Emacs users customize Emacs in various ways. Usually, at some point in time, the built-in customization options cease to suffice. Then you proceed to writing your own functions and commands. Then, you want to bind them to some keys. The purpose of this post is to list some default Emacs bindings which may be useless for some people, and so could be reused as command-invoking or even prefix keys.
-1:-- Free Emacs key bindings (Post)--L0--C0--March 18, 2019 08:42 PM

sachachua: 2019-03-18 Emacs news

Links from reddit.com/r/emacs, /r/orgmode, /r/spacemacs, /r/planetemacs, Hacker News, planet.emacslife.com, YouTube, the changes to the Emacs NEWS file, and emacs-devel.

-1:-- 2019-03-18 Emacs news (Post Sacha Chua)--L0--C0--March 18, 2019 04:40 AM

Manuel Uberti: Switching buffers (Take 2)

Last month I wrote about the neat nswbuff, but there is another way to implement buffer switching without introducing a new package.

Since I already use counsel-projectile, why not leverage it to my needs?

(defun mu-switch-to-project-buffer-if-in-project (arg)
    "Custom switch to buffer.
With universal argument ARG or when not in project, rely on
`ivy-switch-buffer'.
Otherwise, use `counsel-projectile-switch-to-buffer'."
    (interactive "P")
    (if (or arg
            (not (projectile-project-p)))
        (ivy-switch-buffer)
      (counsel-projectile-switch-to-buffer)))

(bind-key* "C-x b" #'mu-switch-to-project-buffer-if-in-project)

Pretty self-explanatory. By default, when not in a project counsel-projectile-switch-to-buffer asks you for the project to switch to.

However, if I am not in a project chances are I want to switch to a buffer that doesn’t belong to a project, especially since I usually enter a project before switching to one of its buffers.

nswbuff has previews and back-and-forth navigation, so it still offers a nicer solution to buffer switching. This is Emacs, of course, so you know the deal: endless possibilities.

-1:-- Switching buffers (Take 2) (Post)--L0--C0--March 16, 2019 12:00 AM

sachachua: 2019-03-11 Emacs news

Links from reddit.com/r/emacs, /r/orgmode, /r/spacemacs, /r/planetemacs, Hacker News, planet.emacslife.com, YouTube, the changes to the Emacs NEWS file, and emacs-devel.

-1:-- 2019-03-11 Emacs news (Post Sacha Chua)--L0--C0--March 12, 2019 04:48 AM

Modern Emacs: Notating Programs - Introduction

Notate is xxx.
-1:-- Notating Programs - Introduction (Post)--L0--C0--March 11, 2019 12:00 AM

Chris Wellons: An Async / Await Library for Emacs Lisp

As part of building my Python proficiency, I’ve learned how to use asyncio. This new language feature first appeared in Python 3.5 (PEP 492, September 2015). JavaScript grew a nearly identical feature in ES2017 (June 2017). An async function can pause to await on an asynchronously computed result, much like a generator pausing when it yields a value.

In fact, both Python and JavaScript async functions are essentially just fancy generator functions with some specialized syntax and semantics. That is, they’re stackless coroutines. Both languages already had generators, so their generator-like async functions are a natural extension that — unlike stackful coroutines — do not require significant, new runtime plumbing.

Emacs officially got generators in 25.1 (September 2016), though, unlike Python and JavaScript, it didn’t require any additional support from the compiler or runtime. It’s implemented entirely using Lisp macros. In other words, it’s just another library, not a core language feature. In theory, the generator library could be easily backported to the first Emacs release to properly support lexical closures, Emacs 24.1 (June 2012).

For the same reason, stackless async/await coroutines can also be implemented as a library. So that’s what I did, letting Emacs’ generator library do most of the heavy lifting. The package is called aio:

It’s modeled more closely on JavaScript’s async functions than Python’s asyncio, with the core representation being promises rather than a coroutine objects. I just have an easier time reasoning about promises than coroutines.

I’m definitely not the first person to realize this was possible, and was beaten to the punch by two years. Wanting to avoid fragmentation, I set aside all formality in my first iteration on the idea, not even bothering with namespacing my identifiers. It was to be only an educational exercise. However, I got quite attached to my little toy. Once I got my head wrapped around the problem, everything just sort of clicked into place so nicely.

In this article I will show step-by-step one way to build async/await on top of generators, laying out one concept at a time and then building upon each. But first, some examples to illustrate the desired final result.

aio example

Ignoring all its problems for a moment, suppose you want to use url-retrieve to fetch some content from a URL and return it. To keep this simple, I’m going to omit error handling. Also assume that lexical-binding is t for all examples. Besides, lexical scope required by the generator library, and therefore also required by aio.

The most naive approach is to fetch the content synchronously:

(defun fetch-fortune-1 (url)
  (let ((buffer (url-retrieve-synchronously url)))
    (with-current-buffer buffer
      (prog1 (buffer-string)
        (kill-buffer)))))

The result is returned directly, and errors are communicated by an error signal (e.g. Emacs’ version of exceptions). This is convenient, but the function will block the main thread, locking up Emacs until the result has arrived. This is obviously very undesirable, so, in practice, everyone nearly always uses the asynchronous version:

(defun fetch-fortune-2 (url callback)
  (url-retrieve url (lambda (_status)
                      (funcall callback (buffer-string)))))

The main thread no longer blocks, but it’s a whole lot less convenient. The result isn’t returned to the caller, and instead the caller supplies a callback function. The result, whether success or failure, will be delivered via callback, so the caller must split itself into two pieces: the part before the callback and the callback itself. Errors cannot be delivered using a error signal because of the inverted flow control.

The situation gets worse if, say, you need to fetch results from two different URLs. You either fetch results one at a time (inefficient), or you manage two different callbacks that could be invoked in any order, and therefore have to coordinate.

Wouldn’t it be nice for the function to work like the first example, but be asynchronous like the second example? Enter async/await:

(aio-defun fetch-fortune-3 (url)
  (let ((buffer (aio-await (aio-url-retrieve url))))
    (with-current-buffer buffer
      (prog1 (buffer-string)
        (kill-buffer)))))

A function defined with aio-defun is just like defun except that it can use aio-await to pause and wait on any other function defined with aio-defun — or, more specifically, any function that returns a promise. Borrowing Python parlance: Returning a promise makes a function awaitable. If there’s an error, it’s delivered as a error signal from aio-url-retrieve, just like the first example. When called, this function returns immediately with a promise object that represents a future result. The caller might look like this:

(defcustom fortune-url ...)

(aio-defun display-fortune ()
  (interactive)
  (message "%s" (aio-await (fetch-fortune-3 fortune-url))))

How wonderfully clean that looks! And, yes, it even works with interactive like that. I can M-x display-fortune and a fortune is printed in the minibuffer as soon as the result arrives from the server. In the meantime Emacs doesn’t block and I can continue my work.

You can’t do anything you couldn’t already do before. It’s just a nicer way to organize the same callbacks: implicit rather than explicit.

Promises, simplified

The core object at play is the promise. Promises are already a rather simple concept, but aio promises have been distilled to their essence, as they’re only needed for this singular purpose. More on this later.

As I said, a promise represents a future result. In practical terms, a promise is just an object to which one can subscribe with a callback. When the result is ready, the callbacks are invoked. Another way to put it is that promises reify the concept of callbacks. A callback is no longer just the idea of extra argument on a function. It’s a first-class thing that itself can be passed around as a value.

Promises have two slots: the final promise result and a list of subscribers. A nil result means the result hasn’t been computed yet. It’s so simple I’m not even bothering with cl-struct.

(defun aio-promise ()
  "Create a new promise object."
  (record 'aio-promise nil ()))

(defsubst aio-promise-p (object)
  (and (eq 'aio-promise (type-of object))
       (= 3 (length object))))

(defsubst aio-result (promise)
  (aref promise 1))

To subscribe to a promise, use aio-listen:

(defun aio-listen (promise callback)
  (let ((result (aio-result promise)))
    (if result
        (run-at-time 0 nil callback result)
      (push callback (aref promise 2)))))

If the result isn’t ready yet, add the callback to the list of subscribers. If the result is ready call the callback in the next event loop turn using run-at-time. This is important because it keeps all the asynchronous components isolated from one another. They won’t see each others’ frames on the call stack, nor frames from aio. This is so important that the Promises/A+ specification is explicit about it.

The other half of the equation is resolving a promise, which is done with aio-resolve. Unlike other promises, aio promises don’t care whether the promise is being fulfilled (success) or rejected (error). Instead a promise is resolved using a value function — or, usually, a value closure. Subscribers receive this value function and extract the value by invoking it with no arguments.

Why? This lets the promise’s resolver decide the semantics of the result. Instead of returning a value, this function can instead signal an error, propagating an error signal that terminated an async function. Because of this, the promise doesn’t need to know how it’s being resolved.

When a promise is resolved, subscribers are each scheduled in their own event loop turns in the same order that they subscribed. If a promise has already been resolved, nothing happens. (Thought: Perhaps this should be an error in order to catch API misuse?)

(defun aio-resolve (promise value-function)
  (unless (aio-result promise)
    (let ((callbacks (nreverse (aref promise 2))))
      (setf (aref promise 1) value-function
            (aref promise 2) ())
      (dolist (callback callbacks)
        (run-at-time 0 nil callback value-function)))))

If you’re not an async function, you might subscribe to a promise like so:

(aio-listen promise (lambda (v)
                      (message "%s" (funcall v))))

The simplest example of a non-async function that creates and delivers on a promise is a “sleep” function:

(defun aio-sleep (seconds &optional result)
  (let ((promise (aio-promise))
        (value-function (lambda () result)))
    (prog1 promise
      (run-at-time seconds nil
                   #'aio-resolve promise value-function))))

Similarly, here’s a “timeout” promise that delivers a special timeout error signal at a given time in the future.

(defun aio-timeout (seconds)
  (let ((promise (aio-promise))
        (value-function (lambda () (signal 'aio-timeout nil))))
    (prog1 promise
      (run-at-time seconds nil
                   #'aio-resolve promise value-function))))

That’s all there is to promises.

Evaluate in the context of a promise

Before we get into pausing functions, lets deal with the slightly simpler matter of delivering their return values using a promise. What we need is a way to evaluate a “body” and capture its result in a promise. If the body exits due to a signal, we want to capture that as well.

Here’s a macro that does just this:

(defmacro aio-with-promise (promise &rest body)
  `(aio-resolve ,promise
                (condition-case error
                    (let ((result (progn ,@body)))
                      (lambda () result))
                  (error (lambda ()
                           (signal (car error) ; rethrow
                                   (cdr error)))))))

The body result is captured in a closure and delivered to the promise. If there’s an error signal, it’s “rethrown” into subscribers by the promise’s value function.

This is where Emacs Lisp has a serious weak spot. There’s not really a concept of rethrowing a signal. Unlike a language with explicit exception objects that can capture a snapshot of the backtrace, the original backtrace is completely lost where the signal is caught. There’s no way to “reattach” it to the signal when it’s rethrown. This is unfortunate because it would greatly help debugging if you got to see the full backtrace on the other side of the promise.

Async functions

So we have promises and we want to pause a function on a promise. Generators have iter-yield for pausing an iterator’s execution. To tackle this problem:

  1. Yield the promise to pause the iterator.
  2. Subscribe a callback on the promise that continues the generator (iter-next) with the promise’s result as the yield result.

All the hard work is done in either side of the yield, so aio-await is just a simple wrapper around iter-yield:

(defmacro aio-await (expr)
  `(funcall (iter-yield ,expr)))

Remember, that funcall is here to extract the promise value from the value function. If it signals an error, this propagates directly into the iterator just as if it had been a direct call — minus an accurate backtrace.

So aio-lambda / aio-defun needs to wrap the body in a generator (iter-lamba), invoke it to produce a generator, then drive the generator using callbacks. Here’s a simplified, unhygienic definition of aio-lambda:

(defmacro aio-lambda (arglist &rest body)
  `(lambda (&rest args)
     (let ((promise (aio-promise))
           (iter (apply (iter-lambda ,arglist
                          (aio-with-promise promise
                            ,@body))
                        args)))
       (prog1 promise
         (aio--step iter promise nil)))))

The body is evaluated inside aio-with-promise with the result delivered to the promise returned directly by the async function.

Before returning, the iterator is handed to aio--step, which drives the iterator forward until it delivers its first promise. When the iterator yields a promise, aio--step attaches a callback back to itself on the promise as described above. Immediately driving the iterator up to the first yielded promise “primes” it, which is important for getting the ball rolling on any asynchronous operations.

If the iterator ever yields something other than a promise, it’s delivered right back into the iterator.

(defun aio--step (iter promise yield-result)
  (condition-case _
      (cl-loop for result = (iter-next iter yield-result)
               then (iter-next iter (lambda () result))
               until (aio-promise-p result)
               finally (aio-listen result
                                   (lambda (value)
                                     (aio--step iter promise value))))
    (iter-end-of-sequence)))

When the iterator is done, nothing more needs to happen since the iterator resolves its own return value promise.

The definition of aio-defun just uses aio-lambda with defalias. There’s nothing to it.

That’s everything you need! Everything else in the package is merely useful, awaitable functions like aio-sleep and aio-timeout.

Composing promises

Unfortunately url-retrieve doesn’t support timeouts. We can work around this by composing two promises: a url-retrieve promise and aio-timeout promise. First define a promise-returning function, aio-select that takes a list of promises and returns (as another promise) the first promise to resolve:

(defun aio-select (promises)
  (let ((result (aio-promise)))
    (prog1 result
      (dolist (promise promises)
        (aio-listen promise (lambda (_)
                              (aio-resolve
                               result
                               (lambda () promise))))))))

We give aio-select both our url-retrieve and timeout promises, and it tells us which resolved first:

(aio-defun fetch-fortune-4 (url timeout)
  (let* ((promises (list (aio-url-retrieve url)
                         (aio-timeout timeout)))
         (fastest (aio-await (aio-select promises)))
         (buffer (aio-await fastest)))
    (with-current-buffer buffer
      (prog1 (buffer-string)
        (kill-buffer)))))

Cool! Note: This will not actually cancel the URL request, just move the async function forward earlier and prevent it from getting the result.

Threads

Despite aio being entirely about managing concurrent, asynchronous operations, it has nothing at all to do with threads — as in Emacs 26’s support for kernel threads. All async functions and promise callbacks are expected to run only on the main thread. That’s not to say an async function can’t await on a result from another thread. It just must be done very carefully.

Processes

The package also includes two functions for realizing promises on processes, whether they be subprocesses or network sockets.

  • aio-process-filter
  • aio-process-sentinel

For example, this function loops over each chunk of output (typically 4kB) from the process, as delivered to a filter function:

(aio-defun process-chunks (process)
  (cl-loop for chunk = (aio-await (aio-process-filter process))
           while chunk
           do (... process chunk ...)))

Exercise for the reader: Write an awaitable function that returns a line at at time rather than a chunk at a time. You can build it on top of aio-process-filter.

I considered wrapping functions like start-process so that their aio versions would return a promise representing some kind of result from the process. However there are so many different ways to create and configure processes that I would have ended up duplicating all the process functions. Focusing on the filter and sentinel, and letting the caller create and configure the process is much cleaner.

Unfortunately Emacs has no asynchronous API for writing output to a process. Both process-send-string and process-send-region will block if the pipe or socket is full. There is no callback, so you cannot await on writing output. Maybe there’s a way to do it with a dedicated thread?

Another issue is that the process-send-* functions are preemptible, made necessary because they block. The aio-process-* functions leave a gap (i.e. between filter awaits) where no filter or sentinel function is attached. It’s a consequence of promises being single-fire. The gap is harmless so long as the async function doesn’t await something else or get preempted. This needs some more thought.

Update: These process functions no longer exist and have been replaced by a small framework for building chains of promises. See aio-make-callback.

Testing aio

The test suite for aio is a bit unusual. Emacs’ built-in test suite, ERT, doesn’t support asynchronous tests. Furthermore, tests are generally run in batch mode, where Emacs invokes a single function and then exits rather than pump an event loop. Batch mode can only handle asynchronous process I/O, not the async functions of aio. So it’s not possible to run the tests in batch mode.

Instead I hacked together a really crude callback-based test suite. It runs in non-batch mode and writes the test results into a buffer (run with make check). Not ideal, but it works.

One of the tests is a sleep sort (with reasonable tolerances). It’s a pretty neat demonstration of what you can do with aio:

(aio-defun sleep-sort (values)
  (let ((promises (mapcar (lambda (v) (aio-sleep v v)) values)))
    (cl-loop while promises
             for next = (aio-await (aio-select promises))
             do (setf promises (delq next promises))
             collect (aio-await next))))

To see it in action (M-x sleep-sort-demo):

(aio-defun sleep-sort-demo ()
  (interactive)
  (let ((values '(0.1 0.4 1.1 0.2 0.8 0.6)))
    (message "%S" (aio-await (sleep-sort values)))))

Async/await is pretty awesome

I’m quite happy with how this all came together. Once I had the concepts straight — particularly resolving to value functions — everything made sense and all the parts fit together well, and mostly by accident. That feels good.

-1:-- An Async / Await Library for Emacs Lisp (Post)--L0--C0--March 10, 2019 08:57 PM

Raimon Grau: emms ftw

I never got into the Emacs MultiMedia System, but just read that it has support for streaming radios so I gave it a try. And you know what?  It's awesome.  I'm adding all the radios I have in my radios repo.

But you already knew that.

Only a few concepts/commands:
- m-x emms-streams RET
- m-x emms RET
- c-+ + + +
- m-x emms-add-dired RET

Enough to get by and start using it.
-1:-- emms ftw (Post Raimon Grau (noreply@blogger.com))--L0--C0--March 06, 2019 03:31 AM

Marcin Borkowski: org-todo-yesterday

I often run my org-agenda in the morning only to see a task I completed yesterday marked as TODO (but forgotten to be marked as DONE). Often I don’t care about the exact date I completed the task, but sometimes I do, and then org-todo-yesterday comes into play.
-1:-- org-todo-yesterday (Post)--L0--C0--March 03, 2019 10:43 AM

Rubén Berenguel: 2019-7 Readings of the week

NOTE: The themes are varied, and some links below are affiliate links. Formal methods, Scala, productivity. Expect a similar wide range in the future as well. You can check all my weekly readings by checking the tag here . You can also get these as a weekly newsletter by subscribing here.


Solving Knights and Knaves with Alloy

Once you start your journey down the formal methods rabbit hole (which I started with TLA+) you can never stop. This is a very good introduction to Alloy, a modelling language which seems well suited for data structure descriptions (not procedural/step-time models)

Seeking the Productive Life: Some Details of My Personal Infrastructure

As much as I don't like Stephen Wolfram, his obsessive take on being productive echoes mine. And that worries me.

Encryption Key Hierarchies in Alloy

Next after the intro above, this is a short post about how you would set up a reasonable hierarchy of keys in an organisation. Something like "Infrastructure team owns infrastructure keys, developers own GitHub" but with more layers. Then you can automatically check somebody has access to stuff, etc. Neat.

Is your Scala object always a singleton?

The guys at SoftwareMill (excellent technical blog and people) stumbled upon this. The kind of bug that could defeat you, but they succeeded, and documented it for the rest of us.

Proving Games are Winnable with Alloy

And the final instalment in this week's formal method extravaganza, how to prove a randomised game (say, Zelda) can be winnable using Alloy.

Don't Let the Internet Dupe you, Event Sourcing is Hard

Yep, can totally agree, I've hit some of the roadblocks and fun moments the author shares. As usual, some HackerNews comments can be enlightening.

On Being A Senior Engineer

There are many definitions of what being senior is, but you can't go wrong trying to follow these suggestions

Hold the front pages: meet the endpaper enthusiasts

I'm pretty sure you didn't know there are collectors of endpaper.

Beating hash tables with trees? The ART-ful radix trie

A synopsis of a data structure paper, about ART radix tries. They are kind-of-like tries, but try to use less memory.

Scala pattern matching: apply the unapply

In case you didn't know how pattern matching works (hint: unapply), this post will tell you.

buffer-expose emacs package

A package released late last week, it helps you navigate your open buffers in a visual way. Pretty neat, and even with my usual 20+ buffers seems to work seamlessly.

Newsletter?

These weekly posts are also available as a newsletter. These days (since RSS went into limbo) most of my regular information comes from several newsletters I’m subscribed to, instead of me going directly to a blog. If this is also your case, subscribe by clicking here.
-1:-- 2019-7 Readings of the week (Post Rubén Berenguel (noreply@blogger.com))--L0--C0--February 26, 2019 09:59 PM

emacsninja: Smooth Video Game Emulation in Emacs

I have a lengthy TODO.org of things I might eventually implement for Emacs, most of which are not exactly useful, are challenging to do or fulfill both conditions. A NES emulator fits all of these criteria neatly. I’ve kept hearing that they can run on poor hardware and learned that the graphics fit into a tiled model (meaning I wouldn’t have to draw each pixel separately, only each tile), so given good enough rendering speed it shouldn’t be an impossible task. Then the unexpected happened, someone else beat me to the punch with nes.el. It’s an impressive feat, but with one wrinkle, its overall speed is unacceptable: Mario runs with a slowdown of over 100x, rendering it essentially unplayable. For this reason I adjusted my goals a bit: Emulate a simpler game platform smoothly in Emacs at full speed.

Enter the CHIP-8. It’s not a console in that sense, but a video game VM designed in the 70ies with the following properties:

  • CPU: 8-Bit, 16 general-purpose registers, 36 instructions, each two bytes large
  • RAM: 4KB
  • Stack: 16 return addresses
  • Resolution: 64 x 32 black/white pixels
  • Rendering: Sprites are drawn in XOR mode
  • Sound: Monotone buzzer
  • Input: Hexadecimal keypad

It’s perfect. Sound is the only real issue here as the native sound support in Emacs is blocking, but this can be worked around with sufficient effort. Once it’s implemented there’s a selection of almost a hundred games to play, with a few dozen more if you implement the Super CHIP-8 extensions. I’d not have to implement Space Invaders, Pacman or Breakout with gamegrid.el. What could possibly be hard about this? As it turns out, enough to keep me entertained for a few weeks. Here’s the repo.

General strategy

First of all, I’ve located a reasonably complete looking ROM pack. It’s not included with the code as I’m not 100% sure on the legal status, some claim the games are old enough to be public domain, but since there are plenty of new ones, I decided to go for the safe route. Sorry about that.

Cowgod’s Chip-8 Technical Reference is the main document I relied upon. It’s clearly written and covers nearly everything I’d want to know about the architecture, with a few exceptions I’d have to find out on my own. Another helpful one is Mastering CHIP-8 to fill in some of the gaps.

To boot up a CHIP-8 game on real hardware you’d use a machine where the interpreter is loaded between the memory offsets #x000 and #x200, load the game starting at offset #x200, then start the interpreter. It would start with the program counter set to #x200, execute the instruction there, continue with the next instruction the program counter points to, etc. To make things more complicated there’s two timers in the system running at 60Hz, these decrement a special register if non-zero which is used to measure delays accurately and play a buzzing sound. However, there is no specification on how fast the CPU runs or how display updates are to be synchronized, so I had to come up with a strategy to accomodate for potentially varying clock speeds.

The standard solution to this is a game loop where you aim at each cycle to take a fixed time, for example by executing a loop iteration, then sleeping for enough time to arrive at the desired cycle duration. This kind of thing doesn’t work too well in Emacs, if you use sit-for you get user-interruptible sleep, if you use sleep-for you get uninterruptable sleep and don’t allow user input to be registered. The solution here is to invert the control flow by using a timer running at the frame rate, then being careful to not do too much work in the timer function. This way Emacs can handle user input while rendering as quickly as possible. The timer function would execute as many CPU cycles as needed, decrement the timer registers if necessary and finally, repaint the display.

Each component of the system is represented by a variable holding an appropriate data structure, most of which are vectors. RAM is a vector of bytes, the stack is a vector of addresses, the screen is a vector of bits, etc. I opted for using vectors over structs for simplicity’s sake. The registers are a special case because if they’re represented by a vector, I’d need to index into it using parts of the opcode. Therefore it would make sense to have constants representing each register, with their values being equal to the value used in the opcode. Initially I’ve defined the constants using copy-paste but later switched to a chip8-enum macro which defines them for me.

The built-in sprites for the hex digits were shamelessly stolen from Cowgod’s Chip-8 technical reference. They are copied on initialization to the memory region reserved for the interpreter, this allows the LD F, Vx instruction to just return the respective address. When implementing extended built-in sprites for the Super CHIP-8 instructions there was no convenient resource to steal them from again, instead I created upscaled versions of them with a terrible Ruby one-liner.

Basic Emulation

For debugging reasons I didn’t implement the game loop at first, instead I went for a loop where I keep executing CPU instructions indefinitely, manually abort with C-g, then display the display state with a debug function that renders it as text. This allowed me to fully concentrate on getting basic emulation right before fighting with efficiency concerns and rendering speed.

For each CPU cycle the CPU looks up the current value of the program counter, looks up the two-byte instruction in the RAM at that offset, then executes it, changing the program counter and possibly more in the process. One unspecified thing here is what one does if the program counter points to an invalid address and what actual ROMs do in practice when they’re done. Experimentation showed that instead of specifying an invalid address they fall into an infinite loop that always jumps to the same address.

Due to the design choice of constantly two-byte sized instructions, the type and operands of each instruction is encoded inline and needs to be extracted by using basic bit fiddling. Emacs Lisp offers logand and ash for this, corresponding to &, << and >> in C. First the bits to be extracted are masked by using logand with an argument where all bits to be kept are set to ones, then the result is shifted all the way to the right with ash using a negative argument. Take for example the JP nnn instruction which is encoded as #x1nnn, for this you’d extract the type by masking the opcode with #xF000, then shift it with ash by -12. Likewise, the argument can be extracted by masking it with #x0FFF, with no shift needed as the bits are already at the right side.

A common set of patterns comes up when dissecting the opcodes, therefore the chip8-exec function saves all interesting parts of the opcode in local variables using the abbreviations as seen in Cowgod’s Chip-8 technical reference, then a big cond is used to tell which type of opcode it is and each branch modifies the state of the virtual machine as needed.

Nearly all instructions end up incrementing the program counter by one instruction. I’ve borrowed a trick from other emulators here, before executing chip8-exec the program counter is unconditionally incremented by the opcode size. In case an instruction needs to do something different like changing it to an jump location, it can still override its value manually.

To test my current progress I picked the simplest (read: smallest) ROM doing something interesting: Maze by David Winter. My debug function printed the screen by writing spaces or hashes to a buffer, separated by a newline for each screen line. After I got this one working, I repeated the process with several other ROMs that weren’t requiring any user input and displayed a (mostly) static screen. The most useful from the collection was “BC Test” by BestCoder as it covered nearly all opcodes and tested them in a systematic fashion. Here’s a list of other ROMs I found useful for testing other features, in case you, the reader, shall embark on a similar adventure:

  • Jumping X and O: Tests delay timer, collision detection, out of bounds drawing
  • CHIP-8 Logo: Tests CALL nnn / RET
  • Sierpinski triangle: Slow, tests emulation speed
  • Zero: Animation, tests rendering speed (look for the flicker)
  • Minimal Game: Tests SKP Vx
  • Keypad Test: Tests LD Vx, K, uncovered a bug in the main loop
  • Tetris: Tests SKP Vx, SKNP Vx, playability
  • SC Test: Tests nearly all opcodes and a few Super CHIP-8 ones
  • Font Test: Tests drawing of small and big built-in sprites
  • Robot: Tests drawing of extended sprites
  • Scroll Test: Tests scrolling to the left and right
  • Car Race Demo: Tests scrolling down
  • Car: Tests emulation speed in extended mode
  • Emutest: Tests half-pixel scroll, extended sprites in low-res

Debugging and Analysis

Surprisingly enough, errors and mistakes keep happening. Stepping through execution of each command with edebug gets tiring after a while, even when using breakpoints to skip to the interesting parts. I therefore implemented something I’ve seen in Circe, my preferred IRC client, a logging function which only logs if logging is enabled and writes the logging output to a dedicated buffer. For now it just logs the current value of the program counter and the decoded instruction about to be executed. I’ve added the same kind of logging to a different CHIP-8 emulator, chick-8 by Evan Hanson from the CHICKEN Scheme community. Comparing both of their logs allowed me to quickly spot where they start to diverge, giving me a hint what instruction is faulty.

Looking through the ROM as it is executed isn’t terribly enlightening, it feels like watching through a peephole, not giving you the full picture of what’s about to happen. I started writing a simple disassembler which decodes every two bytes and writes their offset and meaning to a buffer, but stopped working on it after realizing that I have a much more powerful tool at hand to do disassembly and analysis properly: radare2. As it didn’t recognize the format correctly, I only used its most basic featureset for analysis, the hex editor. By displaying the bytes at a width of two per row and searching for hex byte sequences with regex support I was able to find ROMs using specific opcodes easily.

Later after I’ve finished most of the emulator, I started developing a CHIP-8 disassembly and analysis plugin using its Python scripting support. I ran into a few inconsistencies with the documentation, but eventually figured everything out and got pretty disassembly with arrows visualizing the control flow for jumps and calls.

/img/chip8-r2-graph-thumb.png

Later I discovered that radare2 actually does have CHIP-8 support in core, you need to enable it explicitly by adding -a chip8 to the command line arguments as it cannot be auto-detected that a file is a CHIP-8 ROM. The disassembly support is decent, but the analysis part had a few omissions and mistakes leading to less nice graphs. By using my Python version as basis I’ve managed improving the C version of the analysis plugin to the same level and even surpassed it as the C API allows adding extra meta-data to individual instructions, such as inline commentary. There is a pending PR for this functionality now, I expect it to be merged soon.

Testing

For maximum speed I set up firestarter to recompile the file on each save, added the directory of the project to load-path, then always launched a new Emacs instance from where I loaded up the package and emulated a ROM file. This is ideal if there isn’t much to test, but it’s hard to detect regressions this way. At some point I decided to give the great buttercup library another try and wrote a set of tests exercising every supported instruction with all edge cases I could think of. For each executed test the VM is initialized, some opcodes are loaded up and chip8-cycle is called as often as needed, while testing the state of the registers and other affected parts of the machinery. It was quite a bit of grunt work due to the repetitive nature of the code, but gave me greater confidence in just messing around with the code as retesting everything took less than a second.

Make no mistake here though, excessively testing the complicated parts of a package (I don’t believe it’s worth it testing the simple parts) is in no way a replacement for normal usage of it which can uncover completely different bugs. This is more of a safety net, to make sure code changes don’t break the most basic features.

Rendering

Retrospectively, this was quite the ride. Normally you’d pick a suitable game or multimedia library and be done, but this is Emacs, no such luxuries here. Where we go we don’t need libraries.

My favorite way of drawing graphics in Emacs is by creating SVG on the fly using the esxml library. This turned out to be prohibitively expensive, not only did it fail meeting the performance goals, it also generated an excessive amount of garbage as trees were recursively walked and thrown away over and over again. A variation of this is having a template string resembling the target SVG, then replacing parts of it and generating an image from them. I attempted doing this, but quickly gave up as it was too bothersome coming up with suitable identifiers and replacing all of them correctly.

I still didn’t want to just drop the SVG idea. Considering this was basically tiled graphics (with each tile being an oversized pixel), I considered creating two SVG images for white and black tiles respectively, then inserting them as if they were characters on each line. The downside of this approach was Emacs’ handling of line height, I couldn’t figure out how to completely suppress it to not have any kind of gaps in the rendering. gamegrid.el somehow solves it, but has rather convoluted code.

At this point I was ready to go back to plain text. I remembered that faces are a thing and used them to paint the background of the text black and white. No more annoying gaps. With this I could finally work and started figuring out how to improve the rendering. While the simple solution of always erasing the buffer contents and reinserting them again did work, there were plenty of optimization possibilities. The most obvious one was using dirty frame tracking to tell if the screen even needed to be redrawn. In other words, the code could set a chip8-fb-dirty-p flag and if the main loop discovered it’s set, it would do a redraw and unset it. Next up was only redrawing the changed parts. For this I’d keep a copy of the current and previous state of the screen around, compare them, repaint the changed bits and transfer the current to the previous state. To change the pixels in the buffer I’d erase them, then insert the correct ones.

The final optimization occurred me much later when implementing the Super CHIP-8 instructions. It was no longer possible to play games smoothly at quadrupled resolution, so I profiled and discovered that erasing text was the bottleneck. I considered the situation hopeless, fiddled around with XBM graphics backed by a bit-vector and had not much luck with getting them to work nearly as well at low resolution. It only occurred me by then that I didn’t try to just change the text properties of existing text instead of replacing text. That fixed all remaining performance issues. Another thing I realized is that anything higher-resolution than this will require extra trickery, maybe even involving C modules.

Garbage Collection Woes

Your code may be fast, your rendering impeccable, but what if every now and then your bouncing letters animation stutters? Congratulations, you’ve run into garbage collection ruining your day. In a language like C it’s much more obvious if you’re about to allocate memory from the heap, in a dynamic language it’s much harder to pin down what’s safe and what’s not. Patterns such as creating new objects on the fly are strictly forbidden, so I tried fairly hard to avoid them, but didn’t completely succeed. After staring hard at the code for a while I found that my code transferring the current to the old screen state was using copy-tree which kept allocating vectors all the time. To avoid this I wrote a memcpy-style function that copied values from one array to another one.

Another sneaky example was the initialization of the emulator state which assigned zero-filled vectors to the variables. I noticed this one only due to the test runner printing running times of tests. Most took a fraction of a millisecond, but every six or so the test took over 10 milliseconds for no obvious reason. This turned out to be garbage collection again. I rediscovered the fillarray function which behaves much like memset in C, used it in initialization (with the vectors assigned at declaration time instead) and the pauses were gone. No guarantees that this was the last of it, but I haven’t been able to observe other pauses.

Sound

If your Emacs has been compiled with sound support there will be a play-sound function. Unfortunately it has a big flaw, as long as the sound is playing Emacs will block, so using it is a non-starter. I’ve initially tried using the visual bell (which inverts parts of the screen) as a replacement, then discovered that it does the equivalent of sit-for and calling it repeatedly in a row will in the worst case of no pending user input wait as long as the intervals combined. There was therefore no easy built-in solution to this. To allow users to plug in their own solution I defined two customizable functions defaulting to displaying and clearing a message: chip8-beep-start-function and chip8-beep-stop-function.

The idea here is that given a suitable, asynchronous function you could kick off a beep, then later stop it. Spawning processes is the one thing you can easily do asynchronously, so if you had a way to control a subprocess to start and stop playing a sound file, that would be a good enough solution. I then remembered that mplayer has a slave mode and that mpv improved it in a multitude of ways, so I looked into the easiest way of remote controlling it. It turns out that mpv did away with slave mode in favor of controlling it via FIFO or a socket. To my surprise I actually made it work via FIFO, the full proof of concept can be found in the README.

User input

The CHIP-8 supports two ways of checking user input: Checking whether a key is (not) pressed (non-blocking) and waiting for any key to be pressed (blocking). Doing this in a game library wouldn’t be worth writing about, but this is Emacs after all, there is only a distinction between key up and down for mouse events. After pondering about this issue for a while I decided to fake it by keeping track of when keys have been last pressed in a generic key handler function, then comparing that timestamp against the current time: If it’s below a reasonable timeout, the key is considered pressed, otherwise it isn’t.

Solving the other problem required far more effort. The emulator was at this point sort of a state machine as I’ve tracked whether it was running with a boolean variable to implement a pause command. I’ve reworked the variable and all code using it to be mindful of the current state: Playing, paused or waiting for user input. This way the command merely changed the current state to waiting for input, set a global variable to the register to be filled with the pressed key and set the stage for the generic key handler function to continue execution. If that function detected the waiting state and a valid key has been pressed, it would record it in the respective register and put the emulator into playing state again.

Actually testing this with a keypad demo ROM unveiled a minor bug in the interaction between the main loop and the redrawing logic. Remember that a number of CPU cycles were executed, then a redraw was triggered if needed? Well, imagine that in the middle of the CPU cycles to be executed the state were changed to waiting and the redraw never happened! This would produce an inconsistent screen state, so I changed it to do a repaint immediately. Furthermore, if the state changed to waiting, the loop would still execute more cycles than needed (despite it being a blocking wait), therefore I had to add an extra check in the main loop’s constant amount of cycling whether the state changed and if yes, skeep the loop iteration alltogether.

Super CHIP-8

At this point I was pretty much done with implementing the full CHIP-8 feature set and started playing games like Tetris, Brix and Alien.

/img/chip8-tetris-thumb.png /img/chip8-brix-thumb.png /img/chip8-alien-thumb.png

Yet I wasn’t satisfied for some strange reason. I probably longed for more distraction and set out to implement the remaining Super CHIP-8 instructions. Unlike the main instruction set these weren’t nearly as well documented. My main resource was a schip.txt file which briefly describes the extra instructions. The most problematic extension is the extended mode which doubles the screen dimensions, requiring a clever way to draw a bigger or smaller screen whenever toggled. There are two ways of implementing such a thing: Drawing to one of two separate screen objects and painting the correct one or alternatively, always drawing to a big screen and rendering in a downscaled mode if needed. For simplicity’s sake I went with the first option.

The extra scroll extensions allow game programmers to efficiently change the viewport (though for some reason they forgot about an instruction scrolling up). My challenge here was to change the screen’s contents in-place, for this to be done correctly extra care was necessary to not accidentally overwrite contents you needed to move elsewhere. The trick here is to iterate in reverse order over the screen lines if necessary.

A few more instructions and optimizations later and I was ready to play the probably silliest arcade game ever conceived, Joust. The sprites in the picture below are supposed to be knights on flying ostrichs trying to push each other down with their lances, but they look more like flying rabbits to me.

/img/chip8-joust-thumb.png

Other Musings

Writing an emulator gives you great insight in how a machine actually works. Details like memory mapping you glossed over feels far more intuitive once you have to implement it yourself. One of the downsides is that I didn’t play games for my own enjoyment, but to further improve the emulator and understand the machine.

A few games and demo ROMs revealed bugs in the emulator, such as how to deal with drawing sprites that go outside the boundaries. Cowgod’s Chip-8 Technical Reference tells you to do wrap-around, but Blitz by David Winter seems to think otherwise, when rendered with wrap-around the player sprite collides immediately into a pixel on the edge and the “GAME OVER” screen is displayed. I decided in this case to forego that recommendation and clip the rendering to the screen edges.

It’s not always easy to make such decisions. Some quirks seem fairly reasonable, such as preferrably setting the VF flag to indicate an overflow/underflow condition for arithmetic, although it’s not always specified. Some quirks seem fairly obscure, such as the interpretation of Super CHIP-8 extensions in low-resolution mode: A demo insists that instead of drawing a high-resolution 16 x 16 sprite it should be drawn as 8 x 16 instead. As this doesn’t appear to affect any game and requires significant support code I decided against implementing it. In one case I was conflicted enough between the different interpretation of bit shifting operators that I introduced a customizable to toggle between both, with the incorrect, but popular behavior being the default.

-1:-- Smooth Video Game Emulation in Emacs (Post Vasilij Schneidermann)--L0--C0--February 21, 2019 08:01 PM

Da Zhang: Set_FF_default_browser

How to set Firefox as the default browser under Windows 10 when it does not show up in the default program list under “Default apps”

 

1 Summary: after re-install Firefox (version 65.01 64-bit), I cannot set it as the default browser of Windows 10. It turned out that the registry entry of Firefox was messed up.

1.1 symptoms

  • under Windows 10, Firefox did not appear in the program list under “Default apps”Set_FF_default_browser
  • after the fix, Firefox reappeared in the program list

1.2 the two major Firefox registry entries are: FirefoxHTML, FirefoxURL

1.3 detailed settings

  • FirefoxHTML
    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML]
    @="Firefox Document"
    "FriendlyTypeName"="Firefox Document"
    "EditFlags"=dword:00000002
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML\DefaultIcon]
    @="C:\\Program Files\\Mozilla Firefox\\firefox.exe,1"
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML\shell]
    @="open"
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML\shell\open]
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML\shell\open\command]
    @="\"C:\\Program Files\\Mozilla Firefox\\firefox.exe\" -osint -url \"%1\""
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML\shell\open\ddeexec]
    @=""
    
    
  • FirefoxURL
    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL]
    @="Firefox URL"
    "FriendlyTypeName"="Firefox URL"
    "URL Protocol"=""
    "EditFlags"=dword:00000002
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL\DefaultIcon]
    @="C:\\Program Files\\Mozilla Firefox\\firefox.exe,1"
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL\shell]
    @="open"
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL\shell\open]
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL\shell\open\command]
    @="\"C:\\Program Files\\Mozilla Firefox\\firefox.exe\" -osint -url \"%1\""
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL\shell\open\ddeexec]
    @=""
    

1.4 how I figured out this is the issue

  • I compared the settings of Chrome, which also has ChromeHTML and ChromeURL
  • I also found the FirefoxHTML and FirefoxURL entries, but the original settings were strange (the “kernel32::GetLongPathNameW” lines below):
    • FirefoxHTML
      Windows Registry Editor Version 5.00
      
      [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML]
      @="Firefox HTML Document"
      "FriendlyTypeName"="Firefox HTML Document"
      "EditFlags"=dword:00000002
      
      [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML\Application]
      
      [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML\DefaultIcon]
      @="C:\\Program Files\\Mozilla Firefox\\firefox.exe,0"
      
      [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML\shell]
      @="open"
      
      [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML\shell\open]
      
      [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML\shell\open\command]
      @="\"kernel32::GetLongPathNameW(w R8, w .R7, i 1024)i .R6\" -osint -url \"%1\""
      
      [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML\shell\open\ddeexec]
      @=""
      
    • FirefoxURL
      Windows Registry Editor Version 5.00
      
      [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL]
      @="Firefox URL"
      "FriendlyTypeName"="Firefox URL"
      "URL Protocol"=""
      "EditFlags"=dword:00000002
      
      [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL\DefaultIcon]
      @="kernel32::GetLongPathNameW(w R8, w .R7, i 1024)i .R6,1"
      
      [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL\shell]
      @="open"
      
      [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL\shell\open]
      
      [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL\shell\open\command]
      @="\"kernel32::GetLongPathNameW(w R8, w .R7, i 1024)i .R6\" -osint -url \"%1\""
      
      [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL\shell\open\ddeexec]
      @=""
      
  • I also found in the registry another pair of FirefoxHTML-XXXXX and FirefoxURL-XXXXX (with XXXXX being a random alphanumeric string). So I thought, maybe the messy FirefoxHTML and FirefoxURL were from the old installation, and the -XXXXX version were the correct version.
    • I then just backed up the messy registry entries, removed them, and renamed the -XXXXX version into FirefoxHTML and FirefoxURL
    • PROJ-DONE then problem solved
-1:-- Set_FF_default_browser (Post zhangda)--L0--C0--February 18, 2019 05:23 PM

emacsair: Introducing Transient Commands

I am excited to announce the initial release of Transient, which is a replacement for Magit-Popup.
-1:-- Introducing Transient Commands (Post)--L0--C0--February 14, 2019 09:40 PM

Manuel Uberti: Jump around

Last time I shared my preferred choice for buffer switching, so let’s keep jumping around. The House of Pain reference is a bit tacky, I know, but 90s nostalgia is still flying pretty high from what I’ve heard.

Quickly moving in a buffer is something every Emacs knight do multiple times a day. I distinguish in-buffer jumps in two categories:

  • jumps that encompass all the buffer content
  • jumps limited to what is currently visible

The first movements are covered by Oleh Krehel’s Swiper, but I am more interested in the second kind of jumps this time. There are plenty of solutions both bundled in Emacs (e.g., pop/mark commands) and in the wild. My favourite is avy, again from Oleh Krehel.

(use-package avy-jump                   ; Jump to characters in buffers
  :ensure avy
  :bind (("C-j" . avy-goto-char-in-line)
         ("M-j" . avy-goto-char)))

As it always happens with Oleh’s packages, avy is well-documented, easy to extend, and full of useful commands. I only added bindings for the ones I use the most, and I really use these two all the time.

avy-goto-char allows me to move anywhere following the character I am after. It’s quicker than typing the whole candidate in Swiper, and obviously better than manually moving point1 with C-p/C-n or, worse, the arrow keys.

avy-goto-char-in-line behaves in much the same way, but it is limited to the current line. If you remember iy-go-to-char mentioned years ago on Emacs Rocks, this is Oleh’s own variant.

Both commands push point to the mark-ring, so the default Emacs key binding C-u C-SPC takes you back to your original position.

However, there is an even quicker alternative when I want to jump between occurrences of the symbol where point currently is, which turns out to be pretty handy when coding.

(use-package symbol-overlay             ; Highlight symbols
  :ensure t
  :bind (:map symbol-overlay-mode-map
              ("M-h" . symbol-overlay-put)
              ("M-n" . symbol-overlay-jump-next)
              ("M-p" . symbol-overlay-jump-prev))
  :hook ((conf-mode . symbol-overlay-mode)
         (html-mode . symbol-overlay-mode)
         (prog-mode . symbol-overlay-mode)
         (yaml-mode . symbol-overlay-mode)))

symbol-overlay not only highlights all the occurrences of the current symbol, but it lets you move quickly among them with symbol-overlay-jump-prev and symbol-overlay-jump-next without asking for a character to look for.

Moreover, symbol-overlay works on all the buffer content, so in this particular case is quicker than Swiper too.


  1. Cursor in the selected window. (See: 1.1 Point

-1:-- Jump around (Post)--L0--C0--February 14, 2019 12:00 AM
https://github.com/chrisbarrett/kubernetes-el
-1:--  (Post Steven Ness (noreply@blogger.com))--L0--C0--February 03, 2019 06:22 AM
dunnet i had no idea!
-1:--  (Post Steven Ness (noreply@blogger.com))--L0--C0--January 28, 2019 12:52 AM

Raimon Grau: Formatting JSON

Here's something you probably had to do at some point. You have some big json blob and you want to format it nicely.

I had done this in vim and honestly, it comes very very easy.  In vim, if you have a buffer (/tmp/foo.json) you want to reformat, and you have jq, the nicest way I've found is something like:

:r !jq %

This is really hard to beat, and I'm not sure you can be much faster in any other thing.

But I live inside emacs, and I when I have this need, until now, I was selecting the region, then `M-| jq .`  The problem is I always forget about m-|, and it's really annoying to type it anyway.

So I was about to create my elisp function that would reformat my json region, and before coding it, I timidly tried M-x json-form..  and yes, of course, json-reformat-region is already there (you can download it from melpa).  Job done.

Btw, if you use evil, you can also use ':r !jq /tmp/foo.json'.  For some reason, % doesn't work as a substitute for the current buffer-file-name, but at that point, I don't care much. :)
-1:-- Formatting JSON (Post Raimon Grau (noreply@blogger.com))--L0--C0--January 23, 2019 11:37 AM

Rubén Berenguel: 2019-1 Readings of the week

If you know me, you'll know I have.a very extensive reading list. I keep it in Pocket, and is part of my to do stored in Things3. It used to be very large (hovering around 230 items since August) but during Christmas it got out of control, reaching almost 300 items. That was too much, and I set myself a goal for 2019 to keep it trimmed and sweet. And indeed, since the beginning of the year I have read or canceled 171 articles (122 in the past week, 106 of which were read). That's a decently sized book!

To help me in this goal, I'll (hopefully) be writing a weekly post about what interesting stuff I have read the past week. Beware, this week may be a bit larger than usual, since I wanted to bring the numbers down as fast as possible.

NOTE: The themes are varied. Software/data engineering, drawing, writing. Expect a similar wide range in the future as well.


The Nature of Infinity, and Beyond – Cantor’s Paradise

A short tour through the life of Georg Cantor and his quest for proving the continuum hypothesis. In the end, he was vindicated.

Statistical rule of three

What is a decent estimate of something that hasn't happened yet? Find the answer here.

Apache Arrow: use of jemalloc

A short technical post detailing why Arrow moved to jemalloc for memory allocation.

Subpixel Text Encoding

This is... unexpected. A font that is 1 pixel wide.

Solving murder with Prolog

I have always been a fan of Prolog, and this is a fun and understandable example if you have never used it.

What Parkour Classes Teach Older People About Falling

Interesting. I'm still young, but I'll keep this in mind for the future.

Implementing VisiCalc

The detailed story about how VisiCalc (the first spreadsheet) was written.

The military secret to falling asleep in two minutes

I was actually doing something similar since I was like 12. It might be a stretch to say 2 minutes, but works.

Index 1,600,000,000 Keys with Automata and Rust

Super interesting (and long) post about how FSA and FST are used for fast search in Rust (I'm a bit into Rust lately). Also, BurntSushi's (Andrew Gallant, the author) cat is called Cauchy, something I appreciate as my cat is named Fatou.

How to Draw from Imagination: Beyond References

An excellent piece on gesture drawing and improving your technique.

Anatomy of a Scala quirk

All languages have their WAT, it's harder to find them in Scala though.

Chaotic attractor reconstruction

An easy example in Python of Takens' embedding theorem

Hello, declarative world

An exploration between imperative and functional, and how declarative fits the landscape

Python with Context Managers

Although I have written tons of Python, I never took the time to either write or understand how context managers work. This one was good.

Raymond Chandler's Ten Commandments For the Detective Novel

You never know when you may write a detective novel. Ruben and the case of the dead executor

Seven steps to 100x faster

An optimisation tour of a piece of code written in Go, from data structures to allocation pressure.

Writing a Faster Jsonnet Compiler

A semi-technical post by Databricks about Jsonnet and why they wrote their own compiler. Serves as an introduction to Jsonnet ("compilable JSON") as well.

Bonus

Monoid font and Poet emacs themeToday I switched from solarized dark and Fira Code Pro to the above. It looks interesting


Newsletter?

I’m considering converting this into a weekly newsletter in addition to a blog post. These days (since RSS went into limbo) most of my regular information comes from several newsletters I’m subscribed to, instead of me going directly to a blog. If this is also your case, subscribe by clicking here and if enough people join I’ll send these every Sunday night or so.
-1:-- 2019-1 Readings of the week (Post Rubén Berenguel (noreply@blogger.com))--L0--C0--January 20, 2019 06:16 PM

Emacs Redux: Emacs Prelude Gets a User Manual

This is going to be a really short post.

For ages I’ve planned to create a user manual for Emacs Prelude, but I never got to doing so. Writing a good manual is a huge amount of work and I was wary (and lazy) to commit to doing it. Today I realized that probably having some manual (even if it’s not good) beats having no manual, so I quickly sliced and diced the old huge README of the project, and compiled it together into this proto-manual.

I’ll try to find some time to improve it, but I can make no promises. You can certainly help me out by working on the manual yourselves, though. Prelude is pretty simple, so I assume that everyone, who has spent a bit of time using it, is more than qualified to work on improving its documentation. By the way, the manual features a dedicated section for working on the manual! Coincidence? I don’t think so.

Keep hacking!

-1:-- Emacs Prelude Gets a User Manual (Post Bozhidar Batsov)--L0--C0--January 16, 2019 06:06 PM

Emacs Redux: The Emacs Year in Review

This post is a brief summary of the past year for Emacs from my perspective.

Emacs 26.1

Probably the biggest news of the year was the release of Emacs 26.1. The highlights of the release were:

  • Limited form of concurrency with Lisp threads
  • Support for optional display of line numbers in the buffer
  • Emacs now uses double buffering to reduce flicker on the X Window System
  • Flymake has been completely redesigned
  • TRAMP has a new connection method for Google Drive
  • New single-line horizontal scrolling mode
  • A systemd user unit file is provided
  • Support for 24-bit colors on capable text terminals

Frankly, for me that release was a bit underwhelming as I won’t see much improvement in my day-to-day use of Emacs. I’m on macOS, I don’t use Flymake, I don’t use TRAMP, I don’t like seeing line numbers and I don’t use Emacs in terminal mode. What a bummer, right?

I’m excited that we finally got some limited form of concurrency, though. Probably this is going to become important in a few years, as Emacs packages start adopting it. There are also plenty of other small and very useful improvements in this release. Mickey (from “Mastering Emacs”) goes over the release notes here in greater detail. Maybe I’ll do something similar in the future if I ever find the time for it.

My Emacs Packages

It was a super busy year at work for me, but still I got to release new versions of most of my Emacs Packages. I’m really proud of releasing several big CIDER updates, and of Projectile making it to version 1.0 (and recently 2.0)! By the way - this was the first of my bigger projects that made it to 1.0!

Things were quieter on the Prelude front, but I think it’s pretty good, useful and stable in its current form. With everyone these days trying to pile every possible feature and package in an Emacs distribution, one has to appreciate the tenets of Prelude’s philosophy:

  • simple
  • easy to understand and extend
  • a foundation for you to build upon, as opposed to some end-user product

Probably I should expand on this down the road as well…

Overall, I’ve gotten to a point where I don’t have time to properly maintain all of my projects and it seems that I’ll have to focus on fewer of them in the future and solicit help from other people for the packages I can’t find enough time for.

Emacs Redux

I didn’t write much here last year, but at least I managed to overhaul the blog’s visuals and simplify its setup. Moving from Octopress to Jekyll really simplified things and I hope this will result in more articles down the road.

I’ve also started a new personal blog - Meta Redux. You’re more than welcome to check it out!

Emacs Packages

I don’t recall many new Emacs packages that made the news in 2018. I think I was most excited about ELSA - a brand new Emacs Lisp Static Analyzer. I’ve also noticed that many people were excited about LSP in Emacs and the older lsp-mode got some competition in the face of eglot. As all of the programming I do these days is in Emacs Lisp or Clojure, I don’t really need LSP (generally LSP makes little sense for REPL-driven programming), but it’s great that things are making headway there.

Many of the great Emacs packages became even greater this year - e.g. Magit, company-mode, avy, ivy, etc.

I didn’t pick up many new (for me) packages this year. I can think only of:

  • After many years of using ido I migrated to ivy and I’m super happy with it
  • I’d dropped my custom comment annotations highlighting code in favour of hl-todo
  • I’ve rediscovered easy-kill
  • I’ve discovered how awesome AsciiDoc is (so much better than Markdown for writing technical documentation!!!) and I’ve started using adoc-mode. Unfortunately it’s somewhat buggy and incomplete, and it hasn’t seen a commit in 3 years. It’d be great if we had a better AsciiDoc mode for Emacs!

I’ll also add a shoutout here for Buttercup - the best testing library Emacs has to offer today! It’s so much better and easier to use than ERT, that I’m shocked so few people have discovered it yet. It definitely deserves a blog post or two!

As usual the packages I relied on the most this year were my own Projectile and crux.

My color theme is forever Zenburn. I’ve used it for over a decade and I still can’t find an alternative so appealing that it would make me switch!

MELPA

MELPA really crushed it this year and solidified its position as the only package.el repo that really matters. At this point it’s like homebrew for macOS - it has alternatives, but pretty relatively few people are using them. I’m happy about the consolidation of the package repo scene, but I’m a bit worried that still most people are installing snapshots instead of stable package releases.

Of course, that’s on MELPA - it’s on package maintainers who have adopt a more disciplined approach to releases.

Misc

I really loved reading “The Evolution of Emacs Lisp” paper by Emacs’s former head maintainer Stefan Monnier and Michael Sperber. I’ve been using Emacs for 15 year now and I still learned a lot of new things about the history of the language and the rationale behind certain design decisions. It was also a bit depressing to see how long certain features were being developed without ever making it to a stable Emacs release, but it is what it is…

As usual, throughout the year my best source of Emacs news and updates was Emacs News by Sacha Chua. I can’t recommend it highly enough!

Looking Forward

Frankly, there’s nothing big I’m looking forward to in 2019. I’d love for Emacs to finally start better supporting operating systems like Windows and macOS, but I know that’s a pipe dream at this point. Still, the need for something like an Emacs Mac Port to exist makes me sad. Users of all operating systems should get a great user experience, regardless of whether their OS is free or proprietary.

I do hope that more of the packages bundled with Emacs today would be moved to GNU ELPA, so they can be released separately and more frequently. Emacs’s core should become smaller IMO and the big focus of the Core Team should be improving the basic editing experience, UI and the core API libraries. And, of course, Emacs Lisp itself. I really don’t think that Emacs will ever replace Emacs Lisp with Common Lisp or Scheme (Guile), so we’d better develop a better version of Emacs Lisp instead.

By the way, I think it might be nice if the Emacs Team started running some annual “State of Emacs” survey similar in spirit to say to the “State of Clojure” survey. The results of such a survey can help the Emacs Team decide where to focus their efforts. They’d also be a great gauge of the progress Emacs is making towards solving the problems its users are facing and providing the functionality they need.

On a personal note I hope that I’ll write a few more articles here in 2019 and that I’ll manage to get CIDER to the coveted 1.0 release and Projectile to the next level. I’m also planning to work a bit on project.el, so it’d play nicer with Projectile and provide a better foundation for tools like Projectile.

I also have some vary vague plans to work on improving erlang-mode, take a stab at creating a new asciidoc-mode and maybe play a bit with Haskell-related packages (if I finally manage to learn Haskell that is). Time will tell whether any of this is going to happen.

I’m try to be more active here, but I’m not making any promises. The last couple of years really drained me and as much I’d love to work on many things it would probably be best for me not to work on anything at all.

Closing Thoughts

So, that was Emacs’s 2018 from my perspective. What about yours?

I’d really love to hear what were the Emacs highlights of the year from your perspective. Please, share in the comments what were you most excited about in 2018 and what are you looking forward to in the future.

Emacs had another great year and it’s all because of you - the great community around it! In M-x we trust!

-1:-- The Emacs Year in Review (Post Bozhidar Batsov)--L0--C0--January 10, 2019 08:37 AM

emacsair: Work with Git Forges inside Emacs

I am excited to announce the initial release of Forge, which allows you to work with Git forges, such as Github and Gitlab, from the comfort of Magit and the rest of Emacs.
-1:-- Work with Git Forges inside Emacs (Post)--L0--C0--December 19, 2018 09:40 PM

Alex Schroeder: Importing old Google Plus posts

As Google is planning to sunset Google+ by April 2019, you need to make a backup right now or you’ll forget!

I have written a little tool to help me browse my Google+ archive using Emacs. I posted over 2000 times on Google+, and left even more comments. Browsing speed is essential.

In addition to just browsing, I also want to copy some of these to my blog. They all need some editing before I do that, however: links need to be checked and fixed, tags need to be added, and so on.

Here’s how to get started: get a copy of my Google+ Stream archive from Google Takeout:

  1. select specific data and pick Posts
  2. change the format from HTML to JSON

This is what it should look like:

Takeout

Download the archive when it’s ready and unpack it.

For Emacs, you need the following:

Emacs

As you can see, the archive contains my posts and all the comments people left on it.

I’m happy to answer any questions or help you adapt the code to your own platform.

Also, remember that if your target platform is Wordpress or Blogger, you can always use Friends+Me to handle 3000 posts or less, or pay $20...

Anyway, expect to see some old, backdated posts pop up on this wiki as I work through my list.

Tags:

-1:-- Importing old Google Plus posts (Post)--L0--C0--December 16, 2018 12:03 PM

Emacs café: Indium 2.0 is out! 🎉

A while ago I detailed what was new with the upcoming major release of Indium. The wait is now over, Indium 2.0.0 is finally out, and you can install it from MELPA.

Indium is a JavaScript development environment for Emacs. It connects to a runtime (Browser or Node), and provides a REPL, inspector, live evaluation, and of course a stepping source debugger.

Indium now features much better project configuration with sourcemap support for most, if not all JavaScript projects, including React, VueJS, Meteor, Angular, and basically any project that uses Webpack or other bundlers that produce sourcemaps.

The new Indium is based on a client/server architecture, and requires the installation of the indium server like the following:

npm install -g indium

Indium debugger in action

As always, if you encounter issues, please report bug reports here.

-1:-- Indium 2.0 is out! 🎉 (Post Nicolas Petton)--L0--C0--November 28, 2018 01:20 PM

Flickr tag 'emacs': editor icecream

mararie posted a photo:

editor icecream

fenway, boston. august 2018

-1:-- editor icecream (Post mararie (nobody@flickr.com))--L0--C0--November 24, 2018 08:12 AM

emacspeak: Emacspeak 49.0 (WiseDog) Unleashed


Emacspeak 49.0—WiseDog—Unleashed!

*For Immediate Release:


San Jose, Calif., (Nov 21, 2018)


Emacspeak 49.0 (WiseDog):
Advancing Accessibility In The Age Of User-Aware Interfaces
— Zero cost of Ownership makes priceless software Universally affordable!


Emacspeak Inc (NASDOG: ESPK) — http://github.com/tvraman/emacspeak
— announces the immediate world-wide availability of Emacspeak 49.0
(WiseDog) — a powerful audio desktop for leveraging today's
evolving Data, Social and Assistant-Oriented Internet cloud.


1 Investors Note:

With several prominent tweeters expanding coverage of #emacspeak,
NASDOG: ESPK has now been consistently trading over the social net at
levels close to that once attained by DogCom high-fliers—and as of
November 2018 is trading at levels close to that achieved by once
better known stocks in the tech sector.


2 What Is It?

Emacspeak is a fully functional audio desktop that provides complete
eyes-free access to all major 32 and 64 bit operating environments. By
seamlessly blending live access to all aspects of the Internet such as
ubiquitous assistance, Web-surfing, blogging, social computing and
electronic messaging into the audio desktop, Emacspeak enables speech
access to local and remote information with a consistent and
well-integrated user interface. A rich suite of task-oriented tools
provides efficient speech-enabled access to the evolving
assistant-oriented social Internet cloud.


3 Major Enhancements:

This version requires emacs-26.1 or later.

  1. Emacs 26 Support 🤻
  2. Updated URL templates 🕷
  3. Speech-enabled SageMath ⟬⟭
  4. Updated folding-mode support 🙏
  5. Speech-enabled Lispy ƛ
  6. Updated websearch wizards 🕷
  7. Updated Bookshare support 📚
  8. Updated EWW support 🕸
  9. Updated DBus support 🚌

— And a lot more than will fit this margin. … 🗞


4 Establishing Liberty, Equality And Freedom:

Never a toy system, Emacspeak is voluntarily bundled with all
major Linux distributions. Though designed to be modular,
distributors have freely chosen to bundle the fully integrated
system without any undue pressure—a documented success for
the integrated innovation embodied by Emacspeak. As the system
evolves, both upgrades and downgrades continue to be available at
the same zero-cost to all users. The integrity of the Emacspeak
codebase is ensured by the reliable and secure Linux platform
used to develop and distribute the software.


Extensive studies have shown that thanks to these features, users
consider Emacspeak to be absolutely priceless. Thanks to this
wide-spread user demand, the present version remains priceless
as ever—it is being made available at the same zero-cost as
previous releases.


At the same time, Emacspeak continues to innovate in the area of
eyes-free Assistance and social interaction and carries forward the
well-established Open Source tradition of introducing user interface
features that eventually show up in luser environments.


On this theme, when once challenged by a proponent of a crash-prone
but well-marketed mousetrap with the assertion "Emacs is a system from
the 70's", the creator of Emacspeak evinced surprise at the unusual
candor manifest in the assertion that it would take popular
idiot-proven interfaces until the year 2070 to catch up to where the
Emacspeak audio desktop is today. Industry experts welcomed this
refreshing breath of Courage Certainty and Clarity (CCC) at a time
when users are reeling from the Fear Uncertainty and Doubt (FUD)
unleashed by complex software systems backed by even more convoluted
press releases.


5 Independent Test Results:

Independent test results have proven that unlike some modern (and
not so modern) software, Emacspeak can be safely uninstalled without
adversely affecting the continued performance of the computer. These
same tests also revealed that once uninstalled, the user stopped
functioning altogether. Speaking with Aster Labrador, the creator of
Emacspeak once pointed out that these results re-emphasize the
user-centric design of Emacspeak; “It is the user — and not the
computer– that stops functioning when Emacspeak is uninstalled!”.


5.1 Note from Aster,Bubbles and Tilden:

UnDoctored Videos Inc. is looking for volunteers to star in a
video demonstrating such complete user failure.


6 Obtaining Emacspeak:

Emacspeak can be downloaded from GitHub — see
https://github.com/tvraman/emacspeak you can visit Emacspeak on the
WWW at http://emacspeak.sf.net. You can subscribe to the emacspeak
mailing list — emacspeak@cs.vassar.edu — by sending mail to the
list request address emacspeak-request@cs.vassar.edu. The Emacspeak
Blog
is a good source for news about recent enhancements and how to
use them.


The latest development snapshot of Emacspeak is always available via
Git from GitHub at
Emacspeak GitHub .


7 History:

  • Emacspeak 49.0 (WiseDog) leverages the wisdom gleaned from
    earlier releases to provide an enhanced auditory experience.
  • Emacspeak 48.0 (ServiceDog) builds on earlier releases to provide
    continued end-user value.
  • Emacspeak 47.0 (GentleDog) goes the next step in being helpful
    while letting users learn and grow.
  • Emacspeak 46.0 (HelpfulDog) heralds the coming of Smart Assistants.
  • Emacspeak 45.0 (IdealDog) is named in recognition of Emacs'
    excellent integration with various programming language
    environments — thanks to this, Emacspeak is the IDE of choice
    for eyes-free software engineering.
  • Emacspeak 44.0 continues the steady pace of innovation on the
    audio desktop.
  • Emacspeak 43.0 brings even more end-user efficiency by leveraging the
    ability to spatially place multiple audio streams to provide timely
    auditory feedback.
  • Emacspeak 42.0 while moving to GitHub from Google Code continues to
    innovate in the areas of auditory user interfaces and efficient,
    light-weight Internet access.
  • Emacspeak 41.0 continues to improve
    on the desire to provide not just equal, but superior access —
    technology when correctly implemented can significantly enhance the
    human ability.
  • Emacspeak 40.0 goes back to Web basics by enabling
    efficient access to large amounts of readable Web content.
  • Emacspeak 39.0 continues the Emacspeak tradition of increasing the breadth of
    user tasks that are covered without introducing unnecessary
    bloatware.
  • Emacspeak 38.0 is the latest in a series of award-winning
    releases from Emacspeak Inc.
  • Emacspeak 37.0 continues the tradition of
    delivering robust software as reflected by its code-name.
  • Emacspeak 36.0 enhances the audio desktop with many new tools including full
    EPub support — hence the name EPubDog.
  • Emacspeak 35.0 is all about
    teaching a new dog old tricks — and is aptly code-named HeadDog in
    on of our new Press/Analyst contact. emacspeak-34.0 (AKA Bubbles)
    established a new beach-head with respect to rapid task completion in
    an eyes-free environment.
  • Emacspeak-33.0 AKA StarDog brings
    unparalleled cloud access to the audio desktop.
  • Emacspeak 32.0 AKA
    LuckyDog continues to innovate via open technologies for better
    access.
  • Emacspeak 31.0 AKA TweetDog — adds tweeting to the Emacspeak
    desktop.
  • Emacspeak 30.0 AKA SocialDog brings the Social Web to the
    audio desktop—you cant but be social if you speak!
  • Emacspeak 29.0—AKAAbleDog—is a testament to the resilliance and innovation
    embodied by Open Source software—it would not exist without the
    thriving Emacs community that continues to ensure that Emacs remains
    one of the premier user environments despite perhaps also being one of
    the oldest.
  • Emacspeak 28.0—AKA PuppyDog—exemplifies the rapid pace of
    development evinced by Open Source software.
  • Emacspeak 27.0—AKA
    FastDog—is the latest in a sequence of upgrades that make previous
    releases obsolete and downgrades unnecessary.
  • Emacspeak 26—AKA
    LeadDog—continues the tradition of introducing innovative access
    solutions that are unfettered by the constraints inherent in
    traditional adaptive technologies.
  • Emacspeak 25 —AKA ActiveDog
    —re-activates open, unfettered access to online
    information.
  • Emacspeak-Alive —AKA LiveDog —enlivens open, unfettered
    information access with a series of live updates that once again
    demonstrate the power and agility of open source software
    development.
  • Emacspeak 23.0 — AKA Retriever—went the extra mile in
    fetching full access.
  • Emacspeak 22.0 —AKA GuideDog —helps users
    navigate the Web more effectively than ever before.
  • Emacspeak 21.0
    —AKA PlayDog —continued the
    Emacspeak tradition of relying on enhanced
    productivity to liberate users.
  • Emacspeak-20.0 —AKA LeapDog —continues
    the long established GNU/Emacs tradition of integrated innovation to
    create a pleasurable computing environment for eyes-free
    interaction.
  • emacspeak-19.0 –AKA WorkDog– is designed to enhance
    user productivity at work and leisure.
  • Emacspeak-18.0 –code named
    GoodDog– continued the Emacspeak tradition of enhancing user
    productivity and thereby reducing total cost of
    ownership.
  • Emacspeak-17.0 –code named HappyDog– enhances user
    productivity by exploiting today's evolving WWW
    standards.
  • Emacspeak-16.0 –code named CleverDog– the follow-up to
    SmartDog– continued the tradition of working better, faster,
    smarter.
  • Emacspeak-15.0 –code named SmartDog–followed up on TopDog
    as the next in a continuing series of award-winning audio desktop
    releases from Emacspeak Inc.
  • Emacspeak-14.0 –code named TopDog–was

the first release of this millennium.

  • Emacspeak-13.0 –codenamed
    YellowLab– was the closing release of the
    20th. century.
  • Emacspeak-12.0 –code named GoldenDog– began
    leveraging the evolving semantic WWW to provide task-oriented speech
    access to Webformation.
  • Emacspeak-11.0 –code named Aster– went the
    final step in making Linux a zero-cost Internet access solution for
    blind and visually impaired users.
  • Emacspeak-10.0 –(AKA
    Emacspeak-2000) code named WonderDog– continued the tradition of
    award-winning software releases designed to make eyes-free computing a
    productive and pleasurable experience.
  • Emacspeak-9.0 –(AKA
    Emacspeak 99) code named BlackLab– continued to innovate in the areas
    of speech interaction and interactive accessibility.
  • Emacspeak-8.0 –(AKA Emacspeak-98++) code named BlackDog– was a major upgrade to
    the speech output extension to Emacs.
  • Emacspeak-95 (code named Illinois) was released as OpenSource on
    the Internet in May 1995 as the first complete speech interface
    to UNIX workstations. The subsequent release, Emacspeak-96 (code
    named Egypt) made available in May 1996 provided significant
    enhancements to the interface. Emacspeak-97 (Tennessee) went
    further in providing a true audio desktop. Emacspeak-98
    integrated Internetworking into all aspects of the audio desktop
    to provide the first fully interactive speech-enabled WebTop.

8 About Emacspeak:

Originally based at Cornell (NY) —
http://www.cs.cornell.edu/home/raman —home to Auditory User
Interfaces (AUI) on the WWW, Emacspeak is now maintained on GitHub
https://github.com/tvraman/emacspeak. The system is mirrored
world-wide by an international network of software archives and
bundled voluntarily with all major Linux distributions. On Monday,
April 12, 1999, Emacspeak became part of the Smithsonian's Permanent
Research Collection
on Information Technology at the Smithsonian's
National Museum of American History.


The Emacspeak mailing list is archived at Vassar –the home of the
Emacspeak mailing list– thanks to Greg Priest-Dorman, and provides a
valuable knowledge base for new users.


9 Press/Analyst Contact: Tilden Labrador

Going forward, Tilden acknowledges his exclusive monopoly on
setting the direction of the Emacspeak Audio Desktop, and
promises to exercise this freedom to innovate and her resulting
power responsibly (as before) in the interest of all dogs.


*About This Release:



Windows-Free (WF) is a favorite battle-cry of The League Against
Forced Fenestration (LAFF). –see
http://www.usdoj.gov/atr/cases/f3800/msjudgex.htm for details on
the ill-effects of Forced Fenestration.


CopyWrite )C( Aster, Hubbell and Tilden Labrador. All Writes Reserved.
HeadDog (DM), LiveDog (DM), GoldenDog (DM), BlackDog (DM) etc., are Registered
Dogmarks of Aster, Hubbell and Tilden Labrador. All other dogs belong to
their respective owners.


-1:-- Emacspeak 49.0 (WiseDog) Unleashed (Post T. V. Raman (noreply@blogger.com))--L0--C0--November 20, 2018 09:08 PM

Timo Geusch: Someone installed a Scheme development environment on their phone

Ben Simon has a post up on his blog describing how he set up a scheme development environment on his Galaxy S9 Android phone. It was also an especially timely post as I had been eyeing a Mac Quadra with Read More

The post Someone installed a Scheme development environment on their phone appeared first on The Lone C++ Coder's Blog.

-1:-- Someone installed a Scheme development environment on their phone (Post Timo Geusch)--L0--C0--November 05, 2018 12:00 PM

Alexander Gromnitsky: Elisp history for trivia buffs

From the majestic Evolution of Emacs Lisp paper (if you haven't read it yet, you're missing out):

  • 'lambda was not technically part of the Elisp language until around 1991 when it was added as a macro, early during the development of Emacs-19. In Emacs-18, anonymous functions were written as quoted values of the form:

      '(lambda (..ARGS..) ..BODY..)

    While the lambda macro has made this quote unnecessary for almost 30 years now, many instances of this practice still occur in Elisp code, even though it prevents byte-compilation of the body.'

  • 'The old TECO version of Emacs also allowed attaching hooks to variable changes, but this feature was not provided in Elisp because Richard Stallman considered it a misfeature, which could make it difficult to debug the code. Yet this very feature was finally added to Elisp in 2018 in the form of variable watchers, though they are ironically mostly meant to be used as debugging aides.'

  • 'Elisp does not optimize away tail calls. With Scheme being familiar to many Elisp developers, this is a disappointment for many. In 1991, Jamie Zawinski added an unbind all instruction to the Lucid Emacs byte-code engine (which appears in both Emacs and XEmacs to this day) that was intended to support tail-call optimization, but never implemented the optimization itself.'

  • 'During the learly years of Emacs, the main complaints from users about the simple mark&sweep algorithm were the GC pauses. These were solved very simply in Emacs-19.31 by removing the messages that indicated when GC was in progress. Since then complaints about the performance of the GC have been rare.'

    'Richard Stallman refused to incorporate XEmacs's FFI into Emacs for fear that it would open up a backdoor with which developers would be able to legally circumvent the GNU General Public License (GPL) and thus link Emacs's own code with code that does not abide by these licensing terms.

    After many years of pressure on this issue (not just within the Emacs project, since this affected several other GNU projects, most notably GCC), a solution was agreed to, which was to implement an FFI that would only accept to load libraries that came with a special symbol attesting that this library is compatible with the GPL.

    As a result, after a very long wait, 2016 finally saw the release of Emacs-25.1 with an FFI comparable in functionality to that of XEmacs. So far, we do not know of any publicly available package which makes use of this new functionality, sadly.'

-1:-- Elisp history for trivia buffs (Post ag (noreply@blogger.com))--L0--C0--November 05, 2018 05:24 AM