## Pragmatic Emacs: Get that spacemacs look without spacemacs

Spacemacs is an active, popular, and very comprehensive modular Emacs configuration. I’ve heard lots of good things about it but am happy with my own personal configuration so don’t want to switch. However, I really like the appearance of spacemacs. Happily, the key components are available stand-alone without needing the full spacemacs configuration.

I used the zenburn theme for a long time but more recently have switched to the spacemacs theme. I set this up using the following code in my emacs config file

(use-package spacemacs-theme
:ensure t
:init
(setq spacemacs-theme-org-agenda-height nil)
(setq spacemacs-theme-org-height nil))


This contains a couple of options to stop the theme using variable heights for org-mode agenda items and headings. However, they didn’t have the desired effect for me to I also needed to add the following lines to my org-mode configuration:

;; set sizes here to stop spacemacs theme resizing these
(set-face-attribute 'org-level-1 nil :height 1.0)
(set-face-attribute 'org-level-2 nil :height 1.0)
(set-face-attribute 'org-level-3 nil :height 1.0)
(set-face-attribute 'org-scheduled-today nil :height 1.0)
(set-face-attribute 'org-agenda-date-today nil :height 1.1)
(set-face-attribute 'org-table nil :foreground "#008787")


The other aspect of the spacemacs appearance I like is the modeline. This is replicated using the spaceline package

(use-package spaceline
:demand t
:init
:config
(require 'spaceline-config)
(spaceline-spacemacs-theme))

-1:-- Get that spacemacs look without spacemacs (Post Ben Maughan)--L0--C0--September 24, 2017 11:38 PM

## Irreal: Zamansky 37: Treemacs

Mike Zamansky has a new video up. This time he discusses the Treemacs file browser. The idea is to recreate file browser side tab that editors like Atom popularized. You can watch the video to see its features and how it works or you can check out the project README at GitHub. One nice feature is its integration with Evil and Projectile.

Coincidentally, I read the project description just before I saw Zamansky’s video. Like him, my first thought was, “That’s nice but I probably won’t use it.” My reason for that is that it takes up valuable screen real estate but doesn’t offer me a compensating efficiency gain. I don’t use the mouse in Emacs so navigating through the menus would take longer than finding the file with my usual Avy assist. Helm or ido users would doubtless find the same.

You could argue that it helps when you’re not familiar with a directory structure but in those cases Dired offers the same functionality and gets out of the way once you’ve picked your file. Still, if you’re coming from Atom or one of the other editors offering a file browser or if just like the idea, you might want to give Treemacs a try. It’s not that I think there’s anything wrong with the package, it’s just that it doesn’t fit in with my workflow.

Zamansky’s video is just short of 10 minutes so it should be easy to fit it in. Like all of Zamansky’s videos, it’s definitely worth the time.

-1:-- Zamansky 37: Treemacs (Post jcs)--L0--C0--September 24, 2017 05:50 PM

## Irreal: Karl Voit on the Superiority of Org Mode Markup

I’ve been following a tweet discussion between Karl Voit and several others over the relative merits of light weight markup languages. You can get a feel for the arguments by expanding the following:

Tweets are not, of course, a very good platform for making reasoned arguments about technical issues or anything else for that matter so Voit has pulled his arguments into a blog post in which he make the case that Org-Mode Is One of the Most Reasonable Markup Language to Use for Text. As I’ve said many times, I do almost all my writing these days in Org mode so I already agreed with his conclusion but Voit makes a good case for his conclusion.

He looks at several light weight markup languages such as Org mode, Markdown, AsciiDoc, Wikitext, and reStructuredText and identifies how Org is superior to them. He notes that Org is better even without Emacs because you can write it in any editor and use tools like pandoc to get it into whatever final form you need.

Of course, the right tools make all the difference and using Org markup from within Emacs is a real win. Still, even some people who prefer not to use Emacs, write Org markdown in some other editor and convert it using pandoc. Even if you don’t already agree that Org syntax is the best, be sure to read Voit’s post. He’s got some good arguments and may convince you.

-1:-- Karl Voit on the Superiority of Org Mode Markup (Post jcs)--L0--C0--September 23, 2017 05:44 PM

## Endless Parentheses: It’s Magit! And you’re the magician!

There’s nothing I can praise about Magit that hasn’t been written in a dozen blogs already, but since Jonas started a kickstarter campaign for it I knew I had to say something. If you use Magit, you already know the greatness of it. And if you don’t, hopefully I can convince you to try it in time to back the campaign.

I could go on and on about the virtues of this gem. It’s probably the package that most saves me time, and has taught me more about git than I learned reading a whole book on it. But that’s all just sparks and glitter on top of the real show. For Magit is a magic show, and its real feature is making you the magician.

Controlling Magit feels like putting on a performance. Move your fingers quickly enough, and you’ll be rebasing faster than the eye can see. But if your crowd is not impressed yet, you move on to tagging, cherry-picking, rewriting, reflogging until they’re left staring unblinkingly at your monitor, their jaws unknowingly open in awe.

But, if you’re one of those that only cares about practical benefits, then here are few Magit commands I use just about everyday.

f a Fetch all remotes
Usually how I start my day. Updates information about all remote branches, without messing with your local branch. Really helps that it’s a one-handed combo, so I can do it while sipping the morning coffee.
r u Rebase upstream
Upstream usually means origin/master. If fetch-all indicates that my local branch is out of date with upstream, this will quickly bring it up to date. If I don’t want to rebase this branch, I can m m and merge instead. Since fetch-all has already done all of the slow networking, both merge and rebase are super quick.
b s Branch spin-off
Creates and checks out a new branch, while carrying over any ongoing (and possibly committed) changes. It even undoes the commits on the previous branch. Super useful if you realise you forgot to branch-off from master before starting to work.
b c Branch create
Over time I’ve been gradually using less b s and more b c. When I need a new working branch, instead of having to switch to master, pull origin, and then spin-off, I simply b c straight from origin/master (it never really matters if my local master is outdated).
P … Push!
Feels silly that pushing is so far down my list, but here you go. P p is 95% of my usage, but P t is also useful and you’ll occasionally need a -f in there.
c … Commit powers
c c is your basic commit. But I couldn’t live without c w (for quickly fixing a commit message) or c e (for throwing more changes into the last commit).
l l Log current
Magit is pretty good at keeping you informed of the commit difference between local and remote, but l l is a quick way to get your bearings if you ever feel lost.
y Branch viewer
Concise list of all refs. Great for finding and removing old branches with k (both local and remote). Magit even warns if you try to delete a branch that isn’t merged.

And a few commands I don’t really use everyday, but rather eagerly look forward to the next chance to use them.

l r Reflog
Don’t know what reflog is? Neither did I! Magit taught me about reflog without saying a word, and you should learn it too (it feels like a superpower).
r s Rebase subset
At work, when I need to hotfix something I branch-off from origin/production instead of origin/master. Occasionally though, I’ll forget to do that, commit my hotfix, only to realise my branch is now 100 commits ahead of production. Rebase subset solves this is a blink, by taking only the commit I want and placing it on top of another branch.
r i Rebase interactively
I admit, I was a little scared when I first tried this feature. I had no idea what it did, but that “interactively” menu option had been teasing me for months. If I explain it here I feel like I’d be robing you of the discovery, so I’ll just describe it as “omnipotence over history”.

All of this arsenal combines into some fast and powerful git manipulation. Just yesterday a colleague asked for help on one of his branches. The whole checkout, edit, commit, push process took less than 30 seconds. One more b b and I was back in my branch doing my own stuff.

What’s more, it all feels right. My editor is where I manipulate the source code, that’s where I ought to be changing branches, not alt-tabbing to a terminal.

Comment on this.

-1:-- It’s Magit! And you’re the magician! (Post)--L0--C0--September 20, 2017 10:38 PM

## Jonas Bernoulli: Borg 2.0 and Epkg 3.0 released

I am excited to announce the release of Borg v2.0, Epkg v3.0, Closql v0.4 and Emir v2.0.
-1:-- Borg 2.0 and Epkg 3.0 released (Post)--L0--C0--September 20, 2017 03:00 PM

## Marcin Borkowski: How to hide repeating entries from the Org agenda

For today, I only have a short tip I learned from the Org-mode mailing list recently. If you have a repeating task in your agenda, say every other day, and you show the agenda for, say, the next 15 days, it is quite annoying to see that task displayed for seven or eight days. You can now say (setq org-agenda-show-future-repeats nil) in your init file and see only one instance of this task. If you set it to 'next instead, you’ll see one more instance (which can be quite handy, I imagine). Cool!
-1:-- How to hide repeating entries from the Org agenda (Post)--L0--C0--September 18, 2017 04:47 AM

## Endless Parentheses: Keep your Slack distractions under control with Emacs

There’s no denying slack is a useful tool for intrateam communication, but it’s also a powerful source of distractions. Though I can’t just turn it off all day, I can certainly keep the spam in check.

Slack’s Webapp does allow you to partially mute certain channels, but that’s about as far as it goes. On the other hand, with the power of Emacs and the Alert package, we can perfectly filter out anything we don’t care about.

Start by installing the Slack package from Melpa. It takes a bit of effort to get it set up, but once you’re done following the instructions you should have a (surprisingly featureful) Slack client running inside Emacs.

I’ll probably write further posts on how you can perfect your workflow with this package, but for now we can just go over some basic keybinds.

Now you might think I’ve got it all backwards. Connecting Emacs with Slack could only bring the distractions closer to me. But that’s where Alert comes in. The Slack package automatically uses Alert for sending notifications, so you have full control over them by customizing alert-user-configuration.

That’s super easy to do via the customization interface (M-x customize-variable). But the examples below use plain Elisp. Just keep in mind that the first element is an alist determining which messages to match, and the second element is a symbol specifying what to do (the third is not important here).

For instance, let’s start by telling alert not to notify anything. Sounds blissful, doesn’t it?

There are a couple of important channels I’d like to be notified about anything, so add a rule for them.

Then there are a few channels where I only need to pay attention if explicitly mentioned.

Both of the rules above are more-or-less supported by Slack already (although you can’t really mute channels completely without leaving them). Below is one example where Alert really shines.

We use Rollbar for exception tracking, and I like being notified whenever something explodes in the server. However, it makes no sense to notify me whenever someone resolves an issue. That can be resolved with two short rules.

I have 4 other rules similar to this one. This kind of fine-grained control is great for reducing spam while staying aware of what matters.

Overall, I’m really happy with the setup I’ve got, and I’ll try to post about other aspects of it.

Comment on this.

-1:-- Keep your Slack distractions under control with Emacs (Post)--L0--C0--September 18, 2017 12:00 AM

## Pragmatic Emacs: Highlight latex text in org mode

Here is a tiny tweak for org-mode. If you add the following option to your emacs config file

(setq org-highlight-latex-and-related '(latex))


Then inline latex like $y=mx+c$ will appear in a different colour in an org-mode file to help it stand out.

-1:-- Highlight latex text in org mode (Post Ben Maughan)--L0--C0--September 17, 2017 11:37 PM

## Manuel Uberti: Taming closing delimiters in my s-expressions

As I explained when I wrote about my daily Clojure workflow, I rely heavily on Smartparens for my editing. With Lisp-like languages in particular, I enable smartparens-strict-mode to keep my s-expressions balanced even when I happen to use delete-char or kill-word dangerously near a closing parenthesis.

I have sp-kill-sexp bound to C-M-k, however out of habit I often use C-k to kill a line, which in my configuration is set up as Artur Malabarba explained in his Kill Entire Line with Prefix Argument. Doing that in the middle of an s-expression creates unnerving chaos.

Smartparens comes with a handy binding to temporarily disable the enforced balancing and let me insert a closing delimiter. Just pressing C-q followed by the desired matching parenthesis brings the order back.

Unfortunately, it’s not always that easy. Take this snippet which appears at the end of a ClojureScript function:

(when-not (empty? @data)
[:div
[graph]])]]))))


Carelessly hitting C-k near [graph] disrupts an otherwise elegant s-expression. I could undo, of course, but what if after C-k I do other kill-and-yank edits?

This is exactly why I have come to love syntactic-close.

(use-package syntactic-close            ; Automatically insert closing delimiter
:ensure t
:bind ("C-c x c" . syntactic-close))


As soon as I discover an unbalanced s-expression, I can use C-c x c as many times as needed to add back the right closing delimiters.

-1:-- Taming closing delimiters in my s-expressions (Post)--L0--C0--September 17, 2017 12:00 AM

## Bryan Murdock: Not Leaky, Just Wrong

Intel recently announced new tools for FPGA design. I should probably try to understand OpenCL better before bagging on it, but when I read, "[OpenCL] allows users to abstract away hardware-specific development and use a higher-level software development flow." I cringe. I don't think that's how we get to a productive, higher-level of abstraction in FPGA design. When you look at the progress of software from low-level detailed design to high-level abstract design you see assembly to C to Java to Python (to pick one line of progression among many). The thing that happened every time a new higher-level language gained traction is people recognized patterns that developers were using over and over in one language and made language features in a new language that made those patterns one-liners to implement.

Examples of design patterns turning into language features are, in assembly people developed the patterns of function calls: push arguments onto the stack, save the program counter, jump to the code the implements the function, the function code pops arguments off the stack, does it's thing, then jumps back to the the code that called it. In C the tedium of all that was abstracted away by the language providing you with syntax to define a function, pass it arguments, and just call return at the end. In C people then started developing patterns of structs containing data and function pointers for operating on that data which turned into classes and objects in Java. Java also abstracted away memory management with a garbage collector. Patterns in Java (Visitor, State, etc.) are no longer needed in Python because of features in that language (related discussion here).

This is the path that makes most sense to me for logic design as well. Right now in RTL Verilog people use patterns like registers (always block that activates on posedge clk, has reset, inputs, outputs, etc.), state machines (case statement and state registers, next_state logic...), interfaces (SV actually attempted to add syntax for this), and so on. It seems like the next step in raising the abstraction level is to have a language with those sorts of constructs built-in. Then let people use that for a while and see what new patterns develop and encapsulate those patterns in new language features. Maybe OpenCL does this? I kind of doubt it if it's a "software development flow." It's probably still abstracting away CPU instructions.

-1:-- Not Leaky, Just Wrong (Post Bryan (noreply@blogger.com))--L0--C0--September 15, 2017 03:04 PM

## Timo Geusch: Emacs 25.3 released

Emacs 25.3 has been released on Monday. Given that it’s a security fix I’m downloading the source as I write this. If you’re using the latest Emacs I’d recommend you update your Emacs. The vulnerability as been around since Emacs Read More

The post Emacs 25.3 released appeared first on The Lone C++ Coder's Blog.

-1:-- Emacs 25.3 released (Post Timo Geusch)--L0--C0--September 15, 2017 04:20 AM

## punchagan: Emacs frame as a pop-up input

I wanted to try using a dialog box/pop-up window as a prompt to remind me to periodically make journal entries. I had the following requirements:

• Simple, light-weight dialog box that allows text of arbitrary length
• Ability to launch the dialog from the shell
• Ability to have some placeholder or template text, each time the dialog is shown
• Save the input text to a specific org-mode file
• Write as little code of my own, as possible, to do this

I had initially thought about using a tool like zenity, or write a simple dialog box in Python using Qt, wx or even tk, and then yank the input text at the desired location. This probably wouldn’t have turned out to be too hard, but getting things to look and work exactly the way I wanted would have required more code than I was willing to write or maintain.

After avoiding doing this for a while, I finally realized that I could simply use Emacs with a new frame with the appropriate dimensions, and with the correct file/buffer open to the desired location. This would

• eliminate the need for me to write the UI myself
• eliminate the need to do text manipulation in code, to yank it at the right place, in the right form. By directly opening up the editor at the required location, the onus is on me (as a text inputting user) to put it in, the way I want it.
• additionally provide me the comfort of being able to write with the full power of Emacs - keybindings and all that jazz.
• let me leverage elisp to do essentially whatever I want with the buffer being displayed as the dialog box.

I ended up with a command that looks something like this

emacsclient -c -n\
-F '((title . "Title") (left . (+ 550)) (top . (+ 400)) (width . 110) (height . 12))'\
-e '(pc/open-journal-buffer)'


This worked pretty nicely, except for the fact that with gnome-shell, the pop-up frame doesn’t always appear raised. It often gets hidden in the Emacs windows group, and the whole idea of the pop-up acting as a reminder goes for a toss! But, thanks to this Ask Ubuntu post, I could fix this pretty easily.

emacsclient -c -n\
-F '((title . "Title") (left . (+ 550)) (top . (+ 400)) (width . 110) (height . 12))'\
-e '(progn (pc/open-journal-buffer) (raise-frame) (x-focus-frame (selected-frame)))'

-1:-- Emacs frame as a pop-up input (Post)--L0--C0--September 14, 2017 04:56 PM

## Jonas Bernoulli: Magit 2.11 released

I am excited to announce the release of Magit version 2.11, consisting of 303 commits since the last feature release six months ago.
-1:-- Magit 2.11 released (Post)--L0--C0--September 13, 2017 11:00 AM

## Steven Pigeon: Undo that mess

During last marking season (at the end of the semester), I had, of course, to grade a lot of assignments. For some reason, every semester, I have a good number of students that write code like they just don’t care. I get code that looks like this:

int fonction              (int random_spacing)^M{           ^M
int            niaiseuses;

for (int i=0;i<random_spacing;         i++){
{
{
std::cout
<< bleh
<< std::endl;
}}

}
}


There’s a bit of everything. Random spacing. Traces of conversions from one OS to another, braces at the end of line. Of course, they lose points, but that doesn’t make the code any easier to read. In a previous installment, I proposed something to rebuild the whitespaces only. Now, let’s see how we can repair as many defects as possible with an Emacs function.

Let’s start at the beginning: a list of the things to repair:

• OS-related conversion. Linux/*nixes end lines in \n, Windows in \r\n. Other platforms may use something else. Let’s not concern ourselves with the ZX80.
• Replace longs series of (white)spaces by only one space.
• Deal with braces at the end of lines.
• Reindent everything else using the defined style.

The first two items can be combined. Since transforming \r\n into \n only requires to remove \r, we can bundle series of (white)spaces and \r for replacement. I’m not a regex ninja: I came up with this:

; replaces multiple spaces and stray ^M
(while (re-search-forward "[[:space:]\|?\r]+" nil t)
(replace-match " " nil nil))


Trailing braces are a bit more complicated. They may, or mayn’t, be preceded by spaces and followedby spaces. This time, the regex is a bit more complicated:

; remove fiendish { at end of (non-empty) line
(while (re-search-forward
"\$$[^[:space:]{?\n]+\$$\$$[[:space:]]*\$$\$${\$$\$$[[:space:]]*\$$" nil t)
(replace-match "\\1\n{" nil nil))


It matches three parts. Something that is not whitespaces, followed by something that is whitespaces, the brace {, then whitespaces to the end of line. OK, that makes four. The only one we’re interested in not replacing is the first (the \\1 argument in replace). Everything else, most of it whitespaces, is replaced by newline, { , newline.

Now, the buffer should be in a rather messy state, possibly with trailing whitespaces and destroyed indentation. Calls to whitespace-cleanup and indent-region should finish the job.

Putting all that together:

(defun cleanup-whole-buffer()
"Removes ^M, tabs, and reindent whole buffer"
(interactive)
(save-excursion
(undo-boundary)

(beginning-of-buffer)
; replaces multiple spaces and stray ^M
(while (re-search-forward "[[:space:]\|?\r]+" nil t)
(replace-match " " nil nil))

(beginning-of-buffer)
; remove fiendish { at end of (non-empty) line
(while (re-search-forward
"\$$[^[:space:]{?\n]+\$$\$$[[:space:]]*\$$\$${\$$\$$[[:space:]]*\$$" nil t)
(replace-match "\\1\n{" nil nil))

(beginning-of-buffer)
(whitespace-cleanup)
(indent-region (point-min) (point-max) nil)
)
)


A few explanations on the other stuff we haven’t discussed yet. The save-excursion primitive saves cursor position so that when the function ends, we are still where we called it from. The undo-boundary makes sure that we won’t need a series of undos to undo the cleanup. beginning-of-buffer moves the cursor… at the beginning of the buffer.

Applying it to the above code snippet, we end up with:

int fonction (int random_spacing)
{
int niaiseuses;

for (int i=0;i<random_spacing; i++)
{
{
{
std::cout
<< bleh
<< std::endl;
}}

}
}


There are still a number of issues. For example, i++ has still an extraneous space before it, and we still have two closing braces on the same line. Maybe we should fix that sometime.

Filed under: emacs, hacks Tagged: braces, elisp, n!, newline, whitespace, \r, \r\n
-1:-- Undo that mess (Post Steven Pigeon)--L0--C0--September 12, 2017 03:33 PM

## Marcin Borkowski: My email capturing workflow

I’m constantly fiddling with my email workflow. Those of you who are not professional procrastinators like me will probably never understand where the difficulty of answering a short email with a one-two sentence response may be a problem requiring a few days; those who are will probably nod their heads with the “been there, done that” gesture. And I guess many people will sympathize with me about the (sometimes quite important) emails lost forever down the “unread” list.
-1:-- My email capturing workflow (Post)--L0--C0--September 11, 2017 09:40 AM

## Chris Wellons: Gap Buffers Are Not Optimized for Multiple Cursors

Gap buffers are a common data structure for representing a text buffer in a text editor. Emacs famously uses gap buffers — long-standing proof that gap buffers are a perfectly sufficient way to represent a text buffer.

• Gap buffers are very easy to implement. A bare minimum implementation is about 60 lines of C.

• Gap buffers are especially efficient for the majority of typical editing commands, which tend to be clustered in a small area.

• Except for the gap, the content of the buffer is contiguous, making the search and display implementations simpler and more efficient. There’s also the potential for most of the gap buffer to be memory-mapped to the original file, though typical encoding and decoding operations prevent this from being realized.

• Due to having contiguous content, saving a gap buffer is basically just two write(2) system calls. (Plus fsync(2), etc.)

A gap buffer is really a pair of buffers where one buffer holds all of the content before the cursor (or point for Emacs), and the other buffer holds the content after the cursor. When the cursor is moved through the buffer, characters are copied from one buffer to the other. Inserts and deletes close to the gap are very efficient.

Typically it’s implemented as a single large buffer, with the pre-cursor content at the beginning, the post-cursor content at the end, and the gap spanning the middle. Here’s an illustration:

The top of the animation is the display of the text content and cursor as the user would see it. The bottom is the gap buffer state, where each character is represented as a gray block, and a literal gap for the cursor.

Ignoring for a moment more complicated concerns such as undo and Unicode, a gap buffer could be represented by something as simple as the following:

struct gapbuf {
char *buf;
size_t total;  /* total size of buf */
size_t front;  /* size of content before cursor */
size_t gap;    /* size of the gap */
};


This is close to how Emacs represents it. In the structure above, the size of the content after the cursor isn’t tracked directly, but can be computed on the fly from the other three quantities. That is to say, this data structure is normalized.

As an optimization, the cursor could be tracked separately from the gap such that non-destructive cursor movement is essentially free. The difference between cursor and gap would only need to be reconciled for a destructive change — an insert or delete.

A gap buffer certainly isn’t the only way to do it. For example, the original vi used an array of lines, which sort of explains some of its quirky line-oriented idioms. The BSD clone of vi, nvi, uses an entire database to represent buffers. Vim uses a fairly complex rope-like data structure with page-oriented blocks, which may be stored out-of-order in its swap file.

### Multiple cursors

Multiple cursors is fairly recent text editor invention that has gained a lot of popularity recent years. It seems every major editor either has the feature built in or a readily-available extension. I myself used Magnar Sveen’s well-polished package for several years. Though obviously the concept didn’t originate in Emacs or else it would have been called multiple points, which doesn’t quite roll off the tongue quite the same way.

The concept is simple: If the same operation needs to done in many different places in a buffer, you place a cursor at each position, then drive them all in parallel using the same commands. It’s super flashy and great for impressing all your friends.

However, as a result of improving my typing skills, I’ve come to the conclusion that multiple cursors is all hat and no cattle. It doesn’t compose well with other editing commands, it doesn’t scale up to large operations, and it’s got all sorts of flaky edge cases (off-screen cursors). Nearly anything you can do with multiple cursors, you can do better with old, well-established editing paradigms.

Somewhere around 99% of my multiple cursors usage was adding a common prefix to a contiguous serious of lines. As similar brute force options, Emacs already has rectangular editing, and Vim already has visual block mode.

The most sophisticated, flexible, and robust alternative is a good old macro. You can play it back anywhere it’s needed. You can zip it across a huge buffer. The only downside is that it’s less flashy and so you’ll get invited to a slightly smaller number of parties.

But if you don’t buy my arguments about multiple cursors being tasteless, there’s still a good technical argument: Gap buffers are not designed to work well in the face of multiple cursors!

For example, suppose we have a series of function calls and we’d like to add the same set of arguments to each. It’s a classic situation for a macro or for multiple cursors. Here’s the original code:

foo();
bar();
baz();


The example is tiny so that it will fit in the animations to come. Here’s the desired code:

foo(x, y);
bar(x, y);
baz(x, y);


With multiple cursors you would place a cursor inside each set of parenthesis, then type x, y. Visually it looks something like this:

Text is magically inserted in parallel in multiple places at a time. However, if this is a text editor that uses a gap buffer, the situation underneath isn’t quite so magical. The entire edit doesn’t happen at once. First the x is inserted in each location, then the comma, and so on. The edits are not clustered so nicely.

From the gap buffer’s point of view, here’s what it looks like:

For every individual character insertion the buffer has to visit each cursor in turn, performing lots of copying back and forth. The more cursors there are, the worse it gets. For an edit of length n with m cursors, that’s O(n * m) calls to memmove(3). Multiple cursors scales badly.

Compare that to the old school hacker who can’t be bothered with something as tacky and modern (eww!) as multiple cursors, instead choosing to record a macro, then play it back:

The entire edit is done locally before moving on to the next location. It’s perfectly in tune with the gap buffer’s expectations, only needing O(m) calls to memmove(3). Most of the work flows neatly into the gap.

So, don’t waste your time with multiple cursors, especially if you’re using a gap buffer text editor. Instead get more comfortable with your editor’s macro feature. If your editor doesn’t have a good macro feature, get a new editor.

If you want to make your own gap buffer animations, here’s the source code. It includes a tiny gap buffer implementation:

-1:-- Gap Buffers Are Not Optimized for Multiple Cursors (Post)--L0--C0--September 07, 2017 01:34 AM

## Chen Bin (redguardtoo): Split Emacs window with certain ratio

The idea comes from yangdaweihit. Here is the implementation.

(defvar my-ratio-dict
'((1 . 1.61803398875)
(2 . 2)
(3 . 3)
(4 . 4)
(5 . 0.61803398875))
"The ratio dictionary.")

(defun my-split-window-horizontally (&optional ratio)
"Split window horizontally and resize the new window.
Always focus bigger window."
(interactive "P")
(let* (ratio-val)
(cond
(ratio
(setq ratio-val (cdr (assoc ratio my-ratio-dict)))
(split-window-horizontally (floor (/ (window-body-width)
(1+ ratio-val)))))
(t
(split-window-horizontally)))
(set-window-buffer (next-window) (other-buffer))
(if (or (not ratio-val)
(>= ratio-val 1))
(windmove-right))))

(defun my-split-window-vertically (&optional ratio)
"Split window vertically and resize the new window.
Always focus bigger window."
(interactive "P")
(let* (ratio-val)
(cond
(ratio
(setq ratio-val (cdr (assoc ratio my-ratio-dict)))
(split-window-vertically (floor (/ (window-body-height)
(1+ ratio-val)))))
(t
(split-window-vertically)))
;; open another window with other-buffer
(set-window-buffer (next-window) (other-buffer))
;; move focus if new window bigger than current one
(if (or (not ratio-val)
(>= ratio-val 1))
(windmove-down))))

(global-set-key (kbd "C-x 2") 'my-split-window-vertically)
(global-set-key (kbd "C-x 3") 'my-split-window-horizontally)


Usage is simple. For example, C-x 2 is similar to original split-winddow-vertically while C-u 1 C-x 2 split the window in golden ratio.

-1:-- Split Emacs window with certain ratio (Post Chen Bin)--L0--C0--September 05, 2017 01:26 PM

## Raimon Grau: Everyone welcome Wilfred to the emacs hall of fame.

The recent emacs' hall of fame: Magnars, Malabarba, abo-abo..... and now, we have Wilfred Hughes.

Thank you all for inspiring us, each one with different styles, influences and strategies. Kudos!

-1:-- Everyone welcome Wilfred to the emacs hall of fame. (Post Raimon Grau (noreply@blogger.com))--L0--C0--August 31, 2017 06:38 PM

I’ve just released Helpful, a new way of getting help in Emacs!

The *Help* built-in to Emacs is already pretty good. Helpful goes a step further and includes lots of contextual info. Let’s take a look.

Have you ever wondered which major modes have a keybinding for a function? Helpful reports keybindings in all keymaps!

When you’re hacking on some new code, you might end up with old function aliases after renaming a function. Helpful provides discoverable debug buttons, so you don’t need to remember fmakunbound.

Helpful also has strong opinions on viewing docstrings. Summaries are given focus, and text is fontified. We solve the text-quoting-style debate by removing superfluous puncuation entirely.

Helpful will even show all the references to the symbol you’re looking at, using elisp-refs. This is great for understanding how and where a function is used.

Finally, Helpful will rifle through your Emacs instance to find source code to functions:

• If you’ve defined a function interactively, Helpful will use edebug properties to find the source code.

• If Emacs can only find the raw closure, helpful will convert it back to an equivalent defun.

• If Emacs can only find the byte-compiled files, helpful will just pretty-print that.

I’ve just released v0.1, so there will be bugs. Please give it a try, and let me know what you think, or how we can make it even more, well, helpful!

-1:-- Helpful: Adding Contextual Help to Emacs (Post Wilfred Hughes (me@wilfred.me.uk))--L0--C0--August 30, 2017 12:00 AM

## emacsninja: Parsing the Hard Way

Hello again and sorry for the long downtime! My current Emacs project is an EPUB reader, something that requires parsing XML and validating/extracting data from it. The former can be done just fine in Emacs Lisp with the help of libxml2 (or alternatively, xml.el), for the latter there is no good solution. Typically people go for one of the following approaches:

• Don’t parse at all and just use regular expressions on the raw XML. This works somewhat okayish if your input is predictable and doesn’t change much.
• Parse and walk manually through the parse tree with car, cdr and assoc. Rather tedious and requires writing your own tree traversal functions for anything less than static XML.
• Invent your own library and use a selector DSL for DOM traversal. I’ve seen a few of those, like xml+.el, enlive.el and xml-query.el, however they support relatively little features in their selectors, use their own language instead of a well-established one (such as CSS selectors or XPath) and are usually not available from a package archive for easy installation.

As I’m a big fan of APIs like Python’s lxml with the cssselect module and used the esxml package before, I decided to implement CSS selectors for it. The general strategy was to take parse a CSS selector into a suitable form, do tree traversal by interpreting the parse tree and return the nodes satisfying the selector. Surprisingly enough, the hardest part of this were the parsing bits, so I’ll go into a bit more of detail on how you’d do it properly without any dependencies.

The approach taken in esxml-query.el is recursive-descent parsing, as seen in software like GCC. Generally speaking, a language can be described by a set of rules where the left side refers to its name and the right side explains what it expands to. Expansions are sequences of other rules or constants (which naturally cannot be expanded) and may contain syntactic sugar, such as the Kleene star (as seen in regular expressions). Given an input string described by the grammar, a parser breaks it down according to its rules until it has found a valid combination. The easiest way to turn a grammar into code is by expressing it with a function for each rule, with each function being free to call others. Success and failure can be expressed by returning a piece of the parse tree, a special sentinel value (I’ve chosen to return nil if the rule wasn’t completely matched) or throwing an error, thereby terminating the computation. If all recursively called rule functions returned a bit of the parse tree, the top-level call returns the complete parse tree and the parsing attempt has been successful.

Traditionally there is an extra step before parsing the string, as it’s a bit tedious to express the terminating rules as a sequence of characters, the string is typically preprocessed by a so-called lexer into a list of tagged tokens. This is relatively simple to do in Emacs Lisp by treating the string like a buffer, finding a token that matches the current position, adding it to the list of found tokens and advancing the position until the input has been exhausted. There is one non-trivial problem though, depending on the token definitions it can happen that there are two different kinds of tokens for a given position in the input string. A simple solution here is picking the longer match, this is why the tokenization in esxml--tokenize-css-selector finds all possible matches and picks the longest one.

The syntactical sugar used for the official CSS grammars consists of alternation (|), grouping ([...]), optionals (?) and greedy repetition (* and +). Given the basic token operations (peek) (return first token in the stream) and (next) (pop first token in the stream), it’s straight-forward to translate them to working code by using conditionals and loops. For example, the rule whitespace: SPACE* is consumed by calling (next) while (pop) returns a whitespace. To make things easier, I’ve also introduced an (accept TYPE) helper that uses (peek) to check whether the following token matches TYPE and either consumes it and returns the value or returns nil without consuming. With it the preceding example can be shortened to (while (accept 'space)). Similarly, alternation is expressed with cond and grouping with a while where the body checks whether the grouped content could be matched.

This parsing strategy allows for highly flexible error reporting going beyond “Invalid selector” errors I’ve seen previously in a browser console as you immediately know at which place the parser fails and are free to insert code dealing with the error as you see fit. Be warned though that you must understand the grammar well enough to transform it into a more suitable form, yet equivalent form if you run into rules that are hard or even impossible to express as code. Debugging isn’t too bad either, you can observe the junctions taken by your code and quickly spot at which it goes wrong.

I’m looking forward to venture into parser combinators and PEGs next as they follow the same approach, but involve less code to achieve similar results.

-1:-- Parsing the Hard Way (Post Vasilij Schneidermann)--L0--C0--August 26, 2017 09:52 PM

## Chris Wellons: Vim vs. Emacs: The Working Directory

Vim and Emacs have different internals models for the current working directory, and these models influence the overall workflow for each editor. They decide how files are opened, how shell commands are executed, and how the build system is operated. These effects even reach outside the editor to influence the overall structure of the project being edited.

In the traditional unix model, which was eventually adopted everywhere else, each process has a particular working directory tracked by the operating system. When a process makes a request to the operating system using a relative path — a path that doesn’t begin with a slash — the operating system uses the process’ working directory to convert the path into an absolute path. When a process forks, its child starts in the same directory. A process can change its working directory at any time using chdir(2), though most programs never need to do it. The most obvious way this system call is exposed to regular users is through the shell’s built-in cd command.

Vim’s spiritual heritage is obviously rooted in vi, one of the classic unix text editors, and the most elaborate text editor standardized by POSIX. Like vi, Vim closely follows the unix model for working directories. At any given time Vim has exactly one working directory. Shell commands that are run within Vim will start in Vim’s working directory. Like a shell, the cd ex command changes and queries Vim’s working directory.

Emacs eschews this model and instead each buffer has its own working directory tracked using a buffer-local variable, default-directory. Emacs internally simulates working directories for its buffers like an operating system, resolving absolute paths itself, giving credence to the idea that Emacs is an operating system (“lacking only a decent editor”). Perhaps this model comes from ye olde lisp machines?

In contrast, Emacs’ M-x cd command manipulates the local variable and has no effect on the Emacs process’ working directory. In fact, Emacs completely hides its operating system working directory from Emacs Lisp. This can cause some trouble if that hidden working directory happens to be sitting on filesystem you’d like to unmount.

Vim can be configured to simulate Emacs’ model with its autochdir option. When set, Vim will literally chdir(2) each time the user changes buffers, switches windows, etc. To the user, this feels just like Emacs’ model, but this is just a convenience, and the core working directory model is still the same.

### Single instance editors

For most of my Emacs career, I’ve stuck to running a single, long-lived Emacs instance no matter how many different tasks I’m touching simultaneously. I start the Emacs daemon shortly after logging in, and it continues running until I log out — typically only when the machine is shut down. It’s common to have multiple Emacs windows (frames) for different tasks, but they’re all bound to the same daemon process.

While with care it’s possible to have a complex, rich Emacs configuration that doesn’t significantly impact Emacs’ startup time, the general consensus is that Emacs is slow to start. But since it has a really solid daemon, this doesn’t matter: hardcore Emacs users only ever start Emacs occasionally. The rest of the time they’re launching emacsclient and connecting to the daemon. Outside of system administration, it’s the most natural way to use Emacs.

The case isn’t so clear for Vim. Vim is so fast that many users fire it up on demand and exit when they’ve finished the immediate task. At the other end of the spectrum, others advocate using a single instance of Vim like running a single Emacs daemon. In my initial dive into Vim, I tried the single-instance, Emacs way of doing things. I set autochdir out of necessity and pretended each buffer had its own working directory.

At least for me, this isn’t the right way to use Vim, and it all comes down to working directories. I want Vim to be anchored at the project root with one Vim instance per project. Everything is smoother when it happens in the context of the project’s root directory, from opening files, to running shell commands (ctags in particular), to invoking the build system. With autochdir, these actions are difficult to do correctly, particularly the last two.

### Invoking the build

I suspect the Emacs’ model of per-buffer working directories has, in a Sapir-Whorf sort of way, been responsible for leading developers towards poorly-designed, recursive Makefiles. Without a global concept of working directory, it’s inconvenient to invoke the build system (M-x compile) in some particular grandparent directory that is the root of the project. If each directory has its own Makefile, it usually makes sense to invoke make in the same directory as the file being edited.

Over the years I’ve been reinventing the same solution to this problem, and it wasn’t until I spent time with Vim and its alternate working directory model that I truly understood the problem. Emacs itself has long had a solution lurking deep in its bowels, unseen by daylight: dominating files. The function I’m talking about is locate-dominating-file:

(locate-dominating-file FILE NAME)

Look up the directory hierarchy from FILE for a directory containing NAME. Stop at the first parent directory containing a file NAME, and return the directory. Return nil if not found. Instead of a string, NAME can also be a predicate taking one argument (a directory) and returning a non-nil value if that directory is the one for which we’re looking.

The trouble of invoking the build system at the project root is that Emacs doesn’t really have a concept of a project root. It doesn’t know where it is or how to find it. The vi model inherited by Vim is to leave the working directory at the project root. While Vim can simulate Emacs’ working directory model, Emacs cannot (currently) simulate Vim’s model.

Instead, by identifying a file name unique to the project’s root (i.e. a “dominating” file) such as Makefile or build.xml, then locate-dominating-file can discover the project root. All that’s left is wrapping M-x compile so that default-directory is temporarily adjusted to the project’s root.

That looks very roughly like this (and needs more work):

(defun my-compile ()
(interactive)
(let ((default-directory (locate-dominating-file "." "Makefile")))
(compile "make")))


It’s a pattern I’ve used again and again and again, working against the same old friction. By running one Vim instance per project at the project’s root, I get the correct behavior for free.

-1:-- Vim vs. Emacs: The Working Directory (Post)--L0--C0--August 22, 2017 04:51 AM

# Emacs Start-Up: Speeding It Up

## 1 TL;DR:

Describes my Emacs start-up file, and what I did to speed it up from
12 seconds to under 4 seconds.

## 2 Overview Of Steps

• Byte-compile start-up files.
• Temporarily increase gc-cons-threshold during startup.
• Lexically bind file-name-handler-alist to nil if start-up
is split across many files.
• Used memoization to avoid network lookup of current location during startup.

I have a large number of elpa/melpa packages installed:

(length load-path)

400



With the above, my emacs (Emacs 26 built from Git) startup time is on
average 4 seconds. This includes starting up emacspeak (including
speech servers), as well as launching a number of project-specific
shell buffers. Given that I rarely restart Emacs, the startup time is
academic — but speeding up Emacs startup did get me to clean-up my
Emacs setup.

## 3 Introduction

I have now used Emacs for more than 25 years, and my Emacs start-up
file
has followed the same structure through this time.

1. The init file defines a start-up-emacs function that does the
bulk of the work.
2. Package-specific configuration is split up into
<package>-prepare.el files.
3. All of these files are byte-compiled.

of various modules.

## 4 Load Byte-Compiled Start-Up File

I keep my emacs-startup.el checked into GitHub.
My Emacs init-file is a symlink to the byte-compiled version of the
above — this is something that goes back to my time as a
grad-student at Cornell (when GitHub of course did not exist).
That is also when I originally learnt the trick of temporarily setting
gc-cons-threshold to 8MB — Emacs' default is 800K.

## 5 Package Autoloads And eval-after-load

Over time, some of the package-specific setup files had come to
package-specific setup at the time. As part of the cleanup, I updated
setup code in eval-after-load — this is effectively the same as
using use-package.

means you can load compressed, encrypted or remote files without
having to worry about it. That flexibility comes at a cost — if you
are sure you dont need this flexibility during start-up, then locally
binding file-name-handler-alist to nil is a big win — in my
case, it sped things up by 50%.

## 7 Avoid Network Calls During Start-Up

In my case, I set calendar-latitude and calendar-longitude by
geocoding my address — geocoding is done by calling the Google Maps
API. The geocoding API is plenty fast that you normally dont notice
it — but it was adding anywhere from 1–3 seconds during
startup. Since my address doesn't change that often, I updated module
gmaps to use a memoized version. My address is set via Customize,
and the geocoded lat/long is saved to disk automatically.

## 8 References

1. Emacs Speed What got it all started.
2. file-name-handler-alist The article that gave me the most useful
tip of them all.

Net

-1:-- Emacs Start-Up: Speeding It Up (Post T. V. Raman (noreply@blogger.com))--L0--C0--August 21, 2017 08:01 PM

## sachachua: 2017-08-21 Emacs news

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

Past Emacs News round-ups

-1:-- 2017-08-21 Emacs news (Post Sacha Chua)--L0--C0--August 21, 2017 07:16 AM

## sachachua: 2017-08-14 Emacs news

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

Past Emacs News round-ups

-1:-- 2017-08-14 Emacs news (Post Sacha Chua)--L0--C0--August 14, 2017 06:33 AM

## emacshorrors: make-temp-name

Update: Reddit points out that this has been fixed on master by replacing most of the code with a call to gnulib’s gen_tempname.

For someone not terribly experienced in writing safe programs, one can only hope that building blocks like make-temp-file are doing the right thing and cannot be subverted by a malicious third party. The general advice here is that it’s preferable to use the primitive for creating the temporary file instead of the primitive to generate its name. Now, does Emacs reuse mkstemp(3) for this? Or at least tmpnam(3)? Of course not! Where we go, we can just invent our own source of randomness:

make-temp-file looks as follows:

static const char make_temp_name_tbl[64] =
{
'A','B','C','D','E','F','G','H',
'I','J','K','L','M','N','O','P',
'Q','R','S','T','U','V','W','X',
'Y','Z','a','b','c','d','e','f',
'g','h','i','j','k','l','m','n',
'o','p','q','r','s','t','u','v',
'w','x','y','z','0','1','2','3',
'4','5','6','7','8','9','-','_'
};

static unsigned make_temp_name_count, make_temp_name_count_initialized_p;

/* Value is a temporary file name starting with PREFIX, a string.

The Emacs process number forms part of the result, so there is
no danger of generating a name being used by another process.
In addition, this function makes an attempt to choose a name
which has no existing file.  To make this work, PREFIX should be
an absolute file name.

BASE64_P means add the pid as 3 characters in base64
encoding.  In this case, 6 characters will be added to PREFIX to
form the file name.  Otherwise, if Emacs is running on a system
with long file names, add the pid as a decimal number.

This function signals an error if no unique file name could be
generated.  */

Lisp_Object
make_temp_name (Lisp_Object prefix, bool base64_p)
{
Lisp_Object val, encoded_prefix;
ptrdiff_t len;
printmax_t pid;
char *p, *data;
char pidbuf[INT_BUFSIZE_BOUND (printmax_t)];
int pidlen;

CHECK_STRING (prefix);

/* VAL is created by adding 6 characters to PREFIX.  The first
three are the PID of this process, in base 64, and the second
three are incremented if the file already exists.  This ensures
262144 unique file names per PID per PREFIX.  */

pid = getpid ();

if (base64_p)
{
pidbuf[0] = make_temp_name_tbl[pid & 63], pid >>= 6;
pidbuf[1] = make_temp_name_tbl[pid & 63], pid >>= 6;
pidbuf[2] = make_temp_name_tbl[pid & 63], pid >>= 6;
pidlen = 3;
}
else
{
#ifdef HAVE_LONG_FILE_NAMES
pidlen = sprintf (pidbuf, "%"pMd, pid);
#else
pidbuf[0] = make_temp_name_tbl[pid & 63], pid >>= 6;
pidbuf[1] = make_temp_name_tbl[pid & 63], pid >>= 6;
pidbuf[2] = make_temp_name_tbl[pid & 63], pid >>= 6;
pidlen = 3;
#endif
}

encoded_prefix = ENCODE_FILE (prefix);
len = SBYTES (encoded_prefix);
val = make_uninit_string (len + 3 + pidlen);
data = SSDATA (val);
memcpy (data, SSDATA (encoded_prefix), len);
p = data + len;

memcpy (p, pidbuf, pidlen);
p += pidlen;

/* Here we try to minimize useless stat'ing when this function is
invoked many times successively with the same PREFIX.  We achieve
this by initializing count to a random value, and incrementing it
afterwards.

We don't want make-temp-name to be called while dumping,
because then make_temp_name_count_initialized_p would get set
and then make_temp_name_count would not be set when Emacs starts.  */

if (!make_temp_name_count_initialized_p)
{
make_temp_name_count = time (NULL);
make_temp_name_count_initialized_p = 1;
}

while (1)
{
unsigned num = make_temp_name_count;

p[0] = make_temp_name_tbl[num & 63], num >>= 6;
p[1] = make_temp_name_tbl[num & 63], num >>= 6;
p[2] = make_temp_name_tbl[num & 63], num >>= 6;

/* Poor man's congruential RN generator.  Replace with
++make_temp_name_count for debugging.  */
make_temp_name_count += 25229;
make_temp_name_count %= 225307;

if (!check_existing (data))
{
/* We want to return only if errno is ENOENT.  */
if (errno == ENOENT)
return DECODE_FILE (val);
else
/* The error here is dubious, but there is little else we
can do.  The alternatives are to return nil, which is
as bad as (and in many cases worse than) throwing the
error, or to ignore the error, which will likely result
in looping through 225307 stat's, which is not only
dog-slow, but also useless since eventually nil would
have to be returned anyway.  */
report_file_error ("Cannot create temporary name for prefix",
prefix);
/* not reached */
}
}
}

DEFUN ("make-temp-name", Fmake_temp_name, Smake_temp_name, 1, 1, 0,
doc: /* Generate temporary file name (string) starting with PREFIX (a string).
The Emacs process number forms part of the result, so there is no
danger of generating a name being used by another Emacs process
\(so long as only a single host can access the containing directory...).

This function tries to choose a name that has no existing file.
For this to work, PREFIX should be an absolute file name.

There is a race condition between calling make-temp-name' and creating the
file, which opens all kinds of security holes.  For that reason, you should
normally use make-temp-file' instead.  */)
(Lisp_Object prefix)
{
return make_temp_name (prefix, 0);
}


The generated file name is therefore a combination of the prefix, the Emacs PID and three characters from the above table. This makes about 200.000 possible temporary files that can be generated with a given prefix in an Emacs session. This range can be traversed in a negligible amount of time to recreate the state of the RNG and accurately predict the next temporary file name.

(defun make-temp-file (prefix &optional dir-flag suffix)
"Create a temporary file.
The returned file name (created by appending some random characters at the end
of PREFIX, and expanding against temporary-file-directory' if necessary),
is guaranteed to point to a newly created empty file.
You can then use write-region' to write new data into the file.

If DIR-FLAG is non-nil, create a new empty directory instead of a file.

If SUFFIX is non-nil, add that at the end of the file name."
;; Create temp files with strict access rights.  It's easy to
;; loosen them later, whereas it's impossible to close the
;; time-window of loose permissions otherwise.
(with-file-modes ?\700
(let (file)
(while (condition-case ()
(progn
(setq file
(make-temp-name
(if (zerop (length prefix))
(file-name-as-directory
temporary-file-directory)
(expand-file-name prefix
temporary-file-directory))))
(if suffix
(setq file (concat file suffix)))
(if dir-flag
(make-directory file)
(write-region "" nil file nil 'silent nil 'excl))
nil)
;; the file was somehow created by someone else between
;; make-temp-name' and write-region', let's try again.
nil)
file)))


It’s interesting that the docstring of this function states that the return value “is guaranteed to point to a newly created empty file.”. If there were to exist a file for every possible combination for a prefix, this function would just fall into an infinite loop and block Emacs for no apparent reason. Both of these issues have been solved in a better way in glibc.

At least the impact of predicting the name is lessened if one uses make-temp-file instead of make-temp-name on its own. An attacker cannot create a symlink pointing to a rogue location with the predicted name as that would trigger a file-already-exists error and make the function use the next random name. All they could do is read out the file afterwards iff they have the same permission as the user Emacs runs with. A symlink attack can only be executed successfully with a careless make-temp-name user, thankfully I’ve not been able to find one worth subverting on GitHub yet.

Thanks to dale on #emacs for bringing this to my attention!

-1:-- make-temp-name (Post Vasilij Schneidermann)--L0--C0--August 13, 2017 06:37 PM

I use Emacs as a glorified IRC client but with Bitlbee, the number of IRC channels I’m in has exploded. So many Discord channels. And some Mastodon channels. And my Twitter accounts. It’s crazy. The Emacs modeline is no longer enough to display IRC activity. I wrote a little Rcirc Menu mode to handle it for me.

This has also revived my interest in submitting packages to ELPA. I still have write access. In order to test the waters, I submitted Rcirc Menu and Rcirc Color to emacs-devel. We’ll see how it goes!

Tags:

-1:-- Rcirc Menu (Post)--L0--C0--August 10, 2017 01:15 PM

## Wilfred Hughes: Suggest.el: Synthesising Constants

Suggest.el v0.4 is now out, and it offers some really interesting new ways of making suggestions.

## Supplying Constants

Suppose the user gives us the input '(a b c d) and desired output 'a. We would already suggest car, but that only gets the first element of the list. They may have wanted elt or nth, which get elements at a specific position.

We now try adding constants to the user’s inputs, specifically nil, t, -1, 0, 1 and 2. This makes suggest.el much more effective.

Here’s the example we mentioned:

We can now suggest grouping items in a list pairwise:

Converting a vector to a list:

Truncating lists:

Choosing good values for constants is difficult, but the current set seems to be a good tradeoff between performance, the likelihood of finding a result, and the number of useful results.

## Ranking Suggestions

Now we have more possibilities, ordering our suggestions is more complex. The first prototype didn’t always get the ordering correct:

The user is probably looking for the increment function, 1+. (+ 0 1) feels like stating the obvious.

Suggest.el prefers function calls that don’t require extra arguments, giving us a better order:

If suggest.el tries a function and it returns, we save it. If it isn’t the value we’re looking for, it’s saved to a list of ‘intermediate’ values. This is important for finding nested function calls.

Some intermediate values are very common, especially when exploring arithmetic. There are many ways you can convert an integer to the same float value, for example:

Suggest.el previously considered every single way of generating the same value. v0.4 only tries each unique value 3 times. This allows us to explore more unique possibilities, increasing the likelihood of finding a result before giving up.

## Literature Review

Finally, I’ve spent some time researching similar tools, and documented them in the related projects section.

Not only has it been interesting to see other approaches, suggest.el has benefited from the comparisons. The Smalltalk Finder, for example, also explores bitwise operations, so suggest.el does too!

If there are simple code snippets that you think suggest.el should find, please file a bug. I’m routinely surprised by the results it finds, but I’m sure it could be smarter still.

-1:-- Suggest.el: Synthesising Constants (Post Wilfred Hughes (me@wilfred.me.uk))--L0--C0--August 06, 2017 12:00 AM

## Manuel Uberti: A better workflow with workspaces

I am not a big fan of workspaces on my desktop environments, maybe because to me Alt+Tab is enough. To be honest, I was using workspaces back in my Ratpoison days, but that is not the case any more.

Nevertheless, my daily workflow in Emacs improved so much with eyebrowse I can’t imagine going back to a configuration without it.

(use-package eyebrowse                  ; Easy workspaces creation and switching
:ensure t
:config
(validate-setq eyebrowse-mode-line-separator " "
eyebrowse-new-workspace t)

(eyebrowse-mode t))


As you can see, I am pretty much leaving eyebrowse with its default settings. I removed the comma that was used as a separator between the workspace numbers and made switching to a new workspace start from the *scratch* buffer.

Now my daily workflow in Emacs is thus organised:

• Workspace #1: this is dedicated to my GTD project, which simply follows the steps Nicolas Petton describes in Orgmode for GTD.

• Workspace #2: this is for Clojure and ClojureScript development, so everything from CIDER to project specific Magit buffers and EShells ends up here. In the rare case I need to work on a different project, I create a new workspace.

• Workspace #3: this is the “I need a break!” place. Elfeed is my preferred choice for a quiet and informative distraction. Otherwise, if I just want to hack on my Emacs configuration I do it here.

Combined with Projectile, eyebrowse is the definitive piece of the puzzle I was missing to have an optimised work environment.

-1:-- A better workflow with workspaces (Post)--L0--C0--August 06, 2017 12:00 AM

## counsel-rg

Lately, due to working with a large code base, I've grown more and more fond of counsel-rg. It's an Elisp wrapper around ripgrep - a relatively new recursive grep tool that aims to be faster than the competition (ag, git grep, pt, ack etc).

Besides being really fast, rg also has some really nice command switches. One such switch is especially useful for Emacs:

-M, --max-columns NUM : Don't print lines longer than this limit in bytes. Longer lines are omitted, and only the number of matches in that line is printed.

The -M switch is useful twofold:

• Emacs is slow when dealing long lines (by long I mean thousands of chars per line)
• Emacs is slow at accepting a huge amount of output from a process

For each character you add to your input, counsel-rg starts a new shell command to recalculate the matches with the new input. This means that in order to avoid keyboard lag there's only about 0.1 seconds available for both:

1. Running the shell command.
2. Accepting output from the shell command.

So I'm quite happy that rg speeds up both steps. Less time spent on these steps provides for much smoother searching.

## counsel-grep-or-swiper

I also work with large log files, one file at a time. For a long time, I've used counsel-grep-or-swiper as my main search command:

(global-set-key (kbd "C-s") 'counsel-grep-or-swiper)


But for a 40Mb log file with really long lines counsel-grep-or-swiper started to lag a bit. I tried counsel-rg, and it was actually faster than grep, although it was searching the whole directory. So I thought, why not use rg instead of grep? The switch is actually really easy and required only a simple user customization:

(setq counsel-grep-base-command
"rg -i -M 120 --no-heading --line-number --color never '%s' %s")


## Outro

If you haven't tried ripgrep so far, I suggest you give it a go. Happy hacking!

And if you're a C hacker and have some free time on your hands, why not look at the long lines and the process output issues in Emacs? I'd be very grateful:)

-1:-- Ripgrep (Post)--L0--C0--August 03, 2017 10:00 PM

## Emacs café: beginend.el

Thank you Nicolas for letting me borrow (again) your blog to talk about my work. This time, this will not only be my work, but the one of Matus Goljer too (aka Fuco1). Let me present beginend.

## Genesis

Four years ago, I started being really annoyed by the fact that M-< would go to the beginning of the dired buffer instead of the first file as shown in this picture:

I then wrote these lines of Emacs-lisp code to fix this.

(defun dired-back-to-top ()
(interactive)
(beginning-of-buffer)
(dired-next-line (if dired-omit-mode 2 4)))
(define-key dired-mode-map
(vector 'remap 'beginning-of-buffer) 'dired-back-to-top)


At this time, I took the same approach to bind M-< so that point would go to the beginning of an email body instead of before headers:

(defun mu4e-compose-goto-top ()
(interactive)
(let ((old-position (point)))
(message-goto-body)
(when (equal (point) old-position)
(beginning-of-buffer))))

(define-key mu4e-compose-mode-map
(vector 'remap 'beginning-of-buffer) 'mu4e-compose-goto-top)


You can see that this one is a bit smarter. The function moves point to the beginning of a message’s body, but if point is already there, the point is moved to the buffer’s real beginning instead. This makes it possible to press M-< several times to switch between the real buffer beginning and the meaningful one. I called this feature double-tap.

I did the same for M-> and this served me well for the next two years.

## Start of the beginend project

Two years ago, I started cleaning my init.el file and decided to extract useful bits of Emacs Lisp code into separate packages. That was the beginning of the beginend project.

I also took the opportunity to improve the code to avoid duplication by introducing a macro:

(defun beginend-message-goto-beginning ()
"Go to the beginning of an email, after the headers."
(interactive)
(beginend--double-tap-begin
(message-goto-body)))

(defmacro beginend--double-tap-begin (&rest body)
"Evaluate &BODY and goto real beginning if that did not change point."
(let ((tempvar (make-symbol "old-position")))
(let ((,tempvar (point)))
,@body
(when (equal ,tempvar (point))
(call-interactively #'beginning-of-buffer)))))


The function beginend-message-goto-beginning is equivalent to the function mu4e-compose-goto-top defined above except it is shorter. The macro beginend--double-tap-begin implements double-tap in a way independent of the kind of buffer being visited. The code handling dired buffers used the same macro.

I released version 1 of the project.

## Matus blog post and beginend on steroids

The project did not change for the next two years even though I was using it extensively. One day, I read Matus’ blog post titled:

Enhanced beginning- and end-of-buffer in special mode buffers (dired etc.)

This gave me energy to work on the package again. With Matus, we released version 2 featuring many changes:

• User visible:
• Add missing space to the mode lighter
• Add support for many major modes (magit-status, prog, occur, org-agenda, compilation, notmuch-search, elfeed, prodigy, …)
• Add a global minor mode
• Push mark when beginend moves point
• Make sure beginend is reasonable when buffer is narrowed
• Update README and include screencasts
• Make the end position coherent across modes
• Build process:
• Add Emacs-25.2 as build target
• Remove compiler warnings
• Implementation:
• Factor out common code into new macro making it easy to support more modes
• Testing:
• 84% of the code base is now covered by tests
• Convert tests to buttercup

Adding support for a new mode is a matter of a few lines of code now. Here is how beginend supports going to the meaningful beginning and end of message buffers now:

(beginend-define-mode message-mode
(progn
(message-goto-body))
(progn
(when (re-search-backward "^-- \$" nil t)
(beginend--goto-nonwhitespace))))


The first progn specifies how to go to the meaningful beginning (i.e., after message headers) and the second one specifies how to go to the meaningful end (i.e., before the signature). These six lines of code also support double-tap, bind M-< and M->, take care of buffer narrowing and set the mark appropriately.

Here are some screencasts demonstrating the behavior of beginend in some major modes.

### Dired mode

The following shows how beginend reacts in dired mode when dired-hide-details or dired-omit is activated.

### Message mode

This screencast shows how beginend allows ignoring both a message headers and signature.

### Programming mode

This shows how beginend moves point at start and end of the code block in programming buffers, ignoring comments and blank lines.

## Conclusion

I hope you enjoy using beginend as much as I enjoyed writing it.

-1:-- beginend.el (Post Damien Cassou)--L0--C0--August 01, 2017 08:38 AM`