Content tagged emacs

Yoshi Theme 6

Published on:

According to github I released version 6 of my Yoshi theme 8 days ago. Consequently I uploaded it to Marmalade. I felt I should mention that, and it also gives me an excuse to write something.

This new version brings a newly added CHANGELOG, inspired by Keep a CHANGELOG. It doesn't completely follow the format suggested in there because it's in Org mode format and because I felt I could style this format better than the one they propose, at least when using Org mode. I still need to export it to somewhere nice.

Since the last release, which I don't think anyone has ever seen, there have been some major changes in magit's faces, so those have been added. The original ones are also still there in the hopes that anyone using an older version will still have nice colors.

I've also removed some color variations because I felt they were impurities in the theme. I don't think they actually bring anything to the table and it looks cleaner with just the basic set of colors.

If you have any suggestions, wishes, questions or insults you want to throw my way, please do so in the issue tracker.


Introducing ox-coleslaw

Published on:

I have a big problem: I can't write a blog in anything other than Org mode. I have another problem: I haven't found a good way to write a blog only in Org mode. This always keeps me going back and forth between blogging systems. I've used tekuti, WordPress, and I've tried a few others. Currently I'm using Coleslaw. I haven't written anything lately though because it supports Markdown and HTML and I was getting antsy for some Org mode again. So I've been on the lookout for something new.

Well… I've had enough. I'm not going away this time. I'm going to fix my problems and commit to this system. I picked Coleslaw because it's written en Common Lisp and has some interesting features. I'm going to write an exporter for org to whatever Coleslaw needs!

I've known that it's pretty easy to write an exporter for Org mode for some time, but I've never actually tried to write one. I modified some bits and bobs on org-blog, but that didn't really work out. Today though, while reading an old(er) post on Endless Parentheses, I ran into ox-jekyll. Jekyll has a pretty similar page/post definition syntax to Coleslaw, so it seemed easy to read what they're doing and copy the relevant parts. It's a very small Emacs Lisp file, which made it very easy. So congrats to them and the people writing Org mode for making some very clear code.

So I wrote (or copied) ox-coleslaw based on ox-jekyll. It's slightly smaller than ox-jekyll because, frankly, it offers less. I just need a simple way to export a .org file to a .post file, nothing fancy.

To write posts I will use Org mode. Once ox-coleslaw is loaded I use the org export function to export it to an HTML file with the proper header. You can also do this non-interactively from, for example, a Makefile, but that is a story for another time.

This document is the first attempt at publishing a blog post using ox-coleslaw.


display-graphic-p, cl-letf and themes

Published on:

I had a problem with my theme a while where the colors would be different depending on whether I was starting Emacs as a daemon or not. The colors module has some code that changes the way it works depending on whether a graphical or non-graphical display is run. This was messing with some of the colors in my theme.

My first thought was that it should just wait until the first frame is created before setting the theme. For a while this worked.

(if (daemonp)
    (add-hook 'after-make-frame-functions
              (lambda (frame) (load-theme 'yoshi t)))
  (add-hook 'emacs-startup-hook (lambda () (load-theme 'yoshi t))))

Some time later, that stopped working, because apparently display-graphic-p stopped returning true during the execution of the after-make-frame-functions hook. So I set out to change it so it would work again. This would have been easy in earlier versions of Emacs, where flet wasn't yet deprecated.

(if (daemonp)
    (add-hook 'after-make-frame-functions
              (lambda (frame)
                (flet ((display-graphic-p () t))
                  (load-theme 'yoshi t))))
  (add-hook 'emacs-startup-hook (lambda () (load-theme 'yoshi t))))

Unfortunately, as stated, flet is deprecated. Whenever you compile it you're warned and told that you should use cl-flet or cl-letf instead. I couldn't quite figure out how, though. cl-flet does almost the same thing as flet, but lexically, so you can't dynamically rebind display-graphic-p that way. cl-letf did't seem to be anything like flet at all, so I didn't know how to ever use that to accomplish this.

Thankfully, there was noflet. This, for my purposes at least, works the same way as flet did. It is not part of Emacs, however. But in this case I didn't know what else to do.

(if (daemonp)
    (add-hook 'after-make-frame-functions
              (lambda (frame)
                (noflet ((display-graphic-p (&optional display) t))
                  (load-theme 'yoshi t))))
  (add-hook 'emacs-startup-hook (lambda () (load-theme 'yoshi t))))

This worked perfectly, but I really don't like depending on external packages for starting up emacs.

Then Artur Malabarba wrote a post about using cl-letf and things became very clear.

(if (daemonp)
    (add-hook 'after-make-frame-functions
              (lambda (frame)
                (cl-letf (((symbol-function 'display-graphic-p))
                          (lambda (&optional display) t))
                  (load-theme 'yoshi-theme t))))
  (add-hook 'emacs-startup-hook (lambda () (load-theme 'yoshi-theme t))))

It's a bit more involved than the noflet solution, but it does remove a requirement from my init.el. What I failed to realize before reading Artur's post is that cl-letf works a lot like Emacs' new setf, which works a lot like Common Lisp's setf, which makes it very powerful.

By now, my theme doesn't use the colors module anymore.


Quick normal-state

Published on:

I realized today that most of the time (over 90%) of the time I save a file I feel I have finished typing something. Typing this out makes it sound very obvious, actually. One other thing I noticed is that I still forget to return to normal-state after I'm done editing. Emacs being hackable and not being content with twisting my brain to suit my editor but rather twisting my editor to suit me, I thought I might automate it a little.

My first idea was to have evil automatically revert to normal-state whenever I save and also whenever I switch buffers. I haven't found a hook that runs when switching buffers, so I'll need to brush up on my advising skills and have it run just before switching, perhaps even when execute-extended-command or smex run, so any explicit minibuffer action returns to normal state.

For now it's just the save file, and only for buffers that aren't in the emacs-state as default list:

(defun modes-starting-in (state)
  "Get a list of modes whose default state is STATE."
  (symbol-value (evil-state-property state :modes)))

(defun maybe-switch-to-normal-state ()
  "Switch the current buffer to normal state.

Only do this when the mode is not in emacs state by
default."
  (unless (memql major-mode (modes-starting-in 'emacs))
    (evil-normal-state)))

(with-eval-after-load 'evil
  (add-hook 'after-save-hook
            #'maybe-switch-to-normal-state))

I personally only use either normal-state or emacs-state as default states when a mode loads, if you want to check more you'll have to add some more calls to memq and change emacs to, for example insert or visual or whichever you need.


Clean completions

Published on:

Today's post is very short. In my quest to make GNU Emacs look ever better I thought about something new (to me). Not all buffers need have a mode line. As such I will now turn off the mode line for completion-list-mode, since that only shows up for a short while and I've so far never had any trouble distinguishing it from other buffers.

(add-hook 'completion-list-mode-hook
          (lambda () (setq mode-line-format nil)))

Now, whenever a completion buffer pops up, it'll use all the space available, including the line where the mode line used to be. If it shows up just above the minibuffer (which for me it always has done) it looks more like a part of the same thing instead of two separate windows.


There is an Evil in your Emacs

Published on:

When I first started using GNU/Linux I was looking for a proper text editor. I only had any experience with Visual Studio on Windows because I was a .Net developer at the time, and didn't really have much of a choice. One of the main things I wanted was an editor that worked in a terminal.

Naturally I came to Vim and Emacs (as well as Nano, and perhaps some others as well). For a few weeks I kept switching between Vim and Emacs. I liked Vim's syntax highlighting better, but on the other hand I liked Emacs' keybindings/modelessness better as well. I ended up going with Emacs mostly because of Vim's moded editing.

For years the thought of Vim's moded editing gave me nightmares. I never really realised the best thing about Vim. Even when a post appears on Stack Overflow about grokking Vim. I was already so blinded by the idea that Emacs was the superior editor for me that I failed to register the information. It took a long time, but eventually I opened up to the possibility of such moded editing. By now I was stuck with Emacs because I just couldn't give up its customizability or extensibility. Also, I've grown to love Lisp, and specifically Emacs Lisp, so to go from that to Vimscript wouldn't be quite ideal.

Eventually I decided I really did want to try it. Thankfully Emacs has a package for that: Evil, the Extensible Vi Layer for Emacs. There is one other problem, though: I use the Colemak keyboard layout. The usual hjkl keys are more like hynu, with the up key at the bottom of the keyboard, down at the top and left and right diagonally from eachother. Again Emacs has a package for that, colemak-evil. It rebinds some of the keys so that Evil will work with the Colemak keyboard layout. It is based on that the creator of the Colemak layout used to use in Vim. It's a bit aggressive, so I customized it to be a little less so, mostly removing rebindigs from the motion and emacs state maps.

The real power is in the composability of the commands. In Emacs you have commands like forward-kill-word, forward-kill-sexp and forward-kill-char. In Vim you have the delete operation, which can be combined with, for example, the forward-word motion, or the next-line or forward-char motion. I probably have the names wrong, but hopefully they convey the meaning of what they do. This is what it is all about, or at least from what I've learned to use so far. Of course the powerful ed-like editing features called forth through the Vim ex mode, such as %s/find/replace. Lastly, of course, the fact that a lot of editing can be done in normal mode helps in preventing Emacs-pinky.

I haven't yet been able to work with the extensible part, but some of the modules that exist for evil speak volumes of it.

If you are interested in increasing your productivity, or you like to experiment with new things, you might really want to try it. It may not completely be Vim, but it's still completely Emacs. If you use the colemak-evil package as well you'll also notice that in the insert state all your regular Emacs keys work normally, which is a great combination of the two editors. So far I feel that Vim is great for editing existing code and text, but Emacs still feels better when writing a lot of new code or text.


Stop shr from using background color

Published on:

Here's just one more example why Emacs is so awesome

Reading mail in Gnus is very nice, but shr has become a little too good at its job. Add to this the many occasions when a background is specified without specifying a foreground, plus a color theme that is the inverse of what is usually expected, and you can get hard-to-read HTML messages, gray foreground and gray background.

I've looked at the other possible renderers, but they don't look very nice compared to shr. So just remove its ability to add background colors.

(defun oni:shr-colorize-remove-last-arg (args)
  "If ARGS has more than 3 items, remove the last one."
  (if (> (length args) 3)
      (butlast args)
    args))

(with-eval-after-load 'shr
  (advice-add #'shr-colorize-region :filter-args
              #'oni:shr-colorize-remove-last-arg))

Hello, Cask

Published on:

I've been very resistant to looking at Cask. I felt that, much like for example el-get, it was trying to re-solve a problem that has been solved by ELPA since Emacs v24 in a way incompatible with ELPA.

I have finally looked at it, and to my pleasant surprise it works with ELPA instead of beside it, as a wrapper adding some extra functionality. Using and supporting Cask doesn't mean you don't support ELPA. And theoretically using Cask does open up possibilities for development by creating separate development environments (package wise), though I haven't tried this out yet.

I've switched over my configuration to using Cask, which will also help me keep the configuration on my laptop synchronized more easily.

Aside from a fairly long Cask file, making it work is pretty simple, as the website suggests.

(eval-and-compile
  (require 'cask "~/projects/ext/cask/cask.el")
  (cask-initialize))

I add an eval-and-compile so the external process compiling my init.el doesn't complain about not being able to load ELPA-installed packages.

Now instead of starting up Emacs, running M-x list-packages, pressing U and then X (and y at least once) it's a matter of

cd ~/.emacs.d
cask update

Much easier.


Filtering org tasks

Published on:

I want to be able to easily see a list of tasks that are relevant to the currently loaded desktop file. As I use desktop.el as a kind of project system, this means I only want the tasks for the project I'm currently working on.

First I wrote the tagify function, because org-mode tags can't contain . or - characters (among others I'm sure, but these are the only ones that have caused me any trouble so far). It's a simple string replacement:

(defun tagify (str)
  "Remove dots, replace - with _ in STR."
  (replace-regexp-in-string
   "-" "_" (replace-regexp-in-string "\\." "" (downcase str))))

Then I wrote a function to filter the task list by not showing anything that wasn't tagged with the name of the currently loaded desktop, unless it isn't tagged at all or no desktop has been loaded. And set this function to be the value of org-agenda-before-sorting-filter-function.

(defun filter-by-desktop (entry)
  "Return ENTRY if it has no tags or a tag corresponding to the desktop."
  (require 'desktop)
  (let ((label (when desktop-dirname
                 (tagify (file-name-base
                          (directory-file-name
                           (expand-file-name desktop-dirname))))))
        (tags (get-text-property 0 'tags entry)))
    (when (or (null desktop-dirname) (null tags) (member label tags))
      entry)))

(setq org-agenda-before-sorting-filter-function #'filter-by-desktop)

This works fine. I keep untagged tasks in the list as well because they might be important at all times and I don't want them falling through the cracks. I also want a complete list if no desktop has been loaded so I can browse through my tasks and decide what I'm going to do next.

The downside of this solution is that I have to close my current project in order to see the whole list.

Then I discovered the / key in the agenda buffer. I can't believe I didn't notice this key before. Anyway, that changed my solution.

Instead of setting org-agenda-before-sorting-filter-function I add a hook to the org-agenda-finalize-hook. The filter-by-desktop function looks a little different now:

(defun org-init-filter-by-desktop ()
  "Filter agenda by current label."
  (when desktop-dirname
    (let ((label (tagify (file-name-base
                          (directory-file-name
                           (expand-file-name desktop-dirname))))))
      (org-agenda-filter-apply (cons label nil) 'tag))))

(add-hook 'org-agenda-finalize-hook 'org-init-filter-by-desktop)

I don't need to compare any tags now, and if I want to see my entire list of tasks I can easily just press / /. Since it is easier to get back to the overview of my tasks it also doesn't bother me so much that this way any untagged tasks don't show up in the filtered buffer.

I haven't stopped using / since I discovered it. Filtering in this way is one of the things I like about ibuffer as well, now for org-mode it works excellently as well.


C-d to close eshell

Published on:

One of the "tricks" that I have learned to use when working with terminals is using C-d to close them, or when working on a TTY logout. It somehow grew to the extent that if I can't use it, I get annoyed, like with eshell.

I have customized ansi-term to immediately close its buffer after the shell quits. This makes it very easy to start an ansi-term, which I've bound to C-c t, run a quick command (perhaps make, or similar), C-d, and I'm out. I want that for my eshell too.

There are a few conditions that I want met before the buffer is killed, though.

  1. Since eshell is an Emacs mode like any other, C-d is usually used to forward-kill characters, I don't want to lose this.
  2. I only want it to quit when the line of input is empty.

The following piece of code make sure these conditions are met.

  1. It interactively calls delete-char, which keeps keybindings like C-4 C-d to delete 4 characters working.
  2. It catches the error condition which is signaled whenever delete-char can't do it's job (like when there's nothing left to delete in the buffer).
  3. It checks to make sure that the signaled error is the end-of-buffer error. I don't want to kill the buffer if I try to delete more characters than are in the buffer because I feel that could cause irritating surprises.
  4. It checks of the cursor is at the eshell prompt. This, combined with only responding to the end-of-buffer error, makes sure we're on an empty line and not just at the end of the input. Sometimes keys are pressed at the wrong time and I don't want to have to re-type a command just because I was being an idiot.
  5. If the right conditions aren't met, signal the error again so I can see what's going on.
(defun eshell-C-d ()
  "Either call `delete-char' interactively or quit."
  (interactive)
  (condition-case err
      (call-interactively #'delete-char)
    (error (if (and (eq (car err) 'end-of-buffer)
                    (looking-back eshell-prompt-regexp))
               (kill-buffer)
             (signal (car err) (cdr err))))))

I then bind this to C-d in eshell.

(add-hook 'eshell-mode-hook
          (lambda () (local-set-key (kbd "C-d") #'eshell-C-d)))

highlight VC diffs

Published on:

Sometimes you come across these gems of packages that seem to fulfill a wish that you didn't even realise you had.

Today I came across git-gutter for Emacs and its companion git-gutter-fringe, which are apparently based on an extension for Sumblime Text 2. These show the status of changes in a special "gutter" next to the fringe or in the fringe itself. This is very cool stuff.

To enable it I added the following code to my Emacs init file:

(eval-after-load "git-gutter" '(load "git-gutter-fringe"))

(defun maybe-use-git-gutter ()
  "Run `git-gutter' if the current file is being tracked by git."
  (when (eq (vc-backend (buffer-file-name)) 'Git)
    (git-gutter)))

(add-hook 'after-save-hook 'maybe-use-git-gutter)
(add-hook 'after-change-major-mode-hook 'maybe-use-git-gutter)
(add-hook 'window-configuration-change-hook 'maybe-use-git-gutter)

git-gutter was easily installed through MELPA, but I had to download git-gutter-fringe separately and use package-install-file to install that.

I had to load git-gutter-fringe manually because it didn't seem to have any autoloads defined, and I had to run it using these three hooks because the information seemed to disappear if I switched windows and came back, didn't automatically update after saving and didn't automatically show anything when first loading the file. This was all fine, since just calling the function updates the buffer it's easy to use this way.

Later, though, I stumbled upon diff-hl by accident. I was looking for anything involving the fringe, which I think, for the most part, is underused.

It does pretty much the same thing, except that it does so at least for git, bazaar and mercurial (according to the readme). It also defines some commands for working with the blocks of changes, like navigating between them and reverting them. It uses the fringe by default, and doesn't require a separate package to be installed. And it's much easier to set up.

It can also be installed through MELPA, and afterwards it's just a line in our init file away:

(global-diff-hl-mode)

Of course if you don't want it enabled globally you can call diff-hl-mode from some hooks, but this way works fine for me.

It's funny how I had no idea these existed, didn't even think about needing/wanting this feature and then finding two of them in the same day.


Org examples on github

Published on:

github has an org-mode parser for their README files, but I always thought it didn't handle #+BEGIN_SRC and #+BEGIN_EXAMPLE style blocks. And I'm not wrong, but it does handle : blocks.

So this won't work:

#+BEGIN_EXAMPLE
  This is an example
#+END_EXAMPLE

But this will:

: This is an example

That was a nice surprise for me, because I prefer org-mode for almost all of my documents.


This blog covers archlinux, avandu, avandu-lua, cask, ci, clark, common-lisp, config, conkeror, diff, dispass, dispass.el, editors, elisp, emacs, eshell, evil, exherbo, experiments, file-synchronization, games, git, github, gnus, hla, html, javascript, lisp, lua, markam, meta, mpd, notion, org-mode, ox-coleslaw, projects, rc, sbcl, small-recent-posts, software, stumpwm, systemd, tasks, tekuti, testing, tips, todo, ttrss, utility, vagrant, vc, vim, visual, wdocker docker docker-compose, wm, wordpress, yoshi-theme

View content from 2016-02, 2015-09, 2015-08, 2014-12, 2014-10, 2014-08, 2014-07, 2014-06, 2014-04, 2014-01, 2013-11, 2013-10, 2013-08, 2013-05, 2013-04, 2013-02, 2013-01