Content from 2014-07

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.


Short excursion

Published on:

I took a short excursion to the Ghost blogging platform, which I installed locally, just to try it out. I've been keeping up my posts there, though I did decrease the number. Posting every day is too much of a strain still, so I've decided to post once every two days, tuesdays, thursdays and saturdays. I've just copied the posts over from Ghost to here.

This article is tagged as: meta

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.


Syncthing: Syncing...

Published on:

SyncThing is a very interesting distributed file sharing option. It is a lot like (what I understand of) Dropbox and the file sharing capabilities of ownCloud, as well as SparkleShare, SeaFile and others. The biggest difference compared to all of these, though, is that SyncThing is distributed, or peer-to-peer, there is no central server used in the file sharing.

Setting it up is a breeze. Install it, run it and you're almost done. Once you have it installed on at least two computers (or know someone else who has installed it), you have to let them know eachother. You do this by exchanging their node ids. SyncThing know two things: Nodes and Repositories. Nodes are the different machines you want to share with and repositories are the different directories you want to share with certain nodes. Exchanging node ids requires an actual exchange. If you're managing both machines yourself it shouldn't be too hard to manage, if you're sharing with someone else you need another channel of communication to get this data across. Once you've exchanged node ids and your firewall is setup properly (it needs to let through a special TCP port for global discovery) your machines will connect. If you're both on a local network it should happen quickly, if you're across a large gap of land it should still happen fairly quickly.

After both your machines are connected, or even before, you should setup some repositories and share them with the node you just connected with, otherwise nothing will happen. Again there's some communication involved here, because both sides will have to share a repository with the same name. If either side doesn't share a repository with the other side, it won't sync. After you've communicated which names to use, though, all should go smoothly. It check once every 60 seconds whether or not anything's changed and if it has it'll try and sync with the other machine(s).

One downside to this program, at least on Linux, compared to ownCloud, at least using the ownCloud Client, is that there is no notification of newly arrived files. So again you'd have to send the person owning the node you're sharing with a message telling them that something new should be waiting for them.

A very nice thing on the other hand, is that everything is encrypted. And because there's no central server involved, only the people you choose to share with (and possibly they choose to share with) will have the files. There is no single server that can get hacked into where all your files can be found. It's also open source, which of course makes it possible for you, or anyone else, to look at, improve, audit or do anything with the code you want to or need to to ensure to yourself that it's not doing anything it shouldn't be doing.

I haven't been able to test it thoroughly in the real world. I'm currently just sharing between my desktop PC and my laptop, and I'm sharing with a good friend of mine. So I'm looking forward to seeing more of it.


rcm: Another dotfile manager

Published on:

A little while ago I saw a link pass by about rcm, a RC file (or dotfile) manager. It seems a lot like using GNU Stow for your dotfiles.

The basic idea seems to be that you create links to all your dotfiles and the actual files are all kept in a single directory structure, presumably for easy sharing with, for example, git.

The good...

It seems that rcm has a few interesting features.

Host-specific dotfiles

It gives you an option to have host-specific dotfiles, which is very handy when you're working on multiple (types of) system. My laptop doesn't always have the same needs as my PC and my server(s) definitely have different needs.

The bad...

In the short time I've spent with it, I've also found a few things I don't much like.

Everything in a single directory

I'm not so sure about the choice to put everything in a single directory structure, which top-level dotfiles in the top-level directory. This links all the files together in a repository-idea kind-of way. I can't have a zsh repository and an Emacs repository without also having different rcm source directories.

Actually, this isn't entirely true. I can still separate them, with the use of labels, but not in an ideal fashion.

Unfriendly to directories

It doesn't seem to like linking directories, though it can. Linking directories is essential for me as I can on occasion remove a file from one of my configuration directories and I don't want to have to keep track of dead links like that manually. If you do link a directory, instead of it showing up in lsrc as a single entry, all the files in the directory are shown separately.

Labels

The labels are a nice idea, but they aren't what I expected them to be when I read the description. Like host-specific dotfiles, labeled dotfiles are put in their own directory. This allows you to separate the dotfiles from others. What I didn't like about this implementation is that afterwards you always have to specify which label you want to use, which seems to make it impossible to still setup your dotfiles in a single command.

Conclusion

I personally won't be using rcm to manage my dotfiles. The solution I have right now with GNU Stow works better and is easier to setup, although that too has its drawbacks.

This is not a definitive description or review of the software, I have spent only a small amount of time with it and these are the findings I made when trying to set it up with a few config files. If you really want to know about it you should try it, it has quite a bit of documentation to get you going.


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.


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