Der Spiegel (jedenfalls der Online Arm) jammert ja seit ein paar Tagen rum, man solle mal seinen Adblocker ausschalten. Wegen der Kinder, oder so. Das unerwartete Ergebnis: Es gab offenbar noch jede Menge Nutzer unter den SPON Lesern die noch garnicht wußten, was ein Adblocker ist... Dementsprechend positiv war der Effekt bei den Leuten von adblockplus.org:

Von daher hat SPON da doch ganz gute Aufklärungsarbeit geleistet... ;)

Die Titanic hat natürlich ihre eigene amüsante Sicht auf die Dinge:

Dpa-Flatrate, *schenkelklopf*. Dem habe ich nichts hinzuzufügen. :-)

(Jaja, die Onlineangebote von anderen Zeitungsverlagen jammern gerade ebenfalls rum. Nicht nur der Spiegel. Aber irgendwie klingt die Meldung die der Spiegel einblendet am drastischsten - und soweit ich weiß waren sie auch die ersten die damit angefangen haben.)

    

There is a lot of information around for the emacs OS. Most people probably know about the emacswiki, which probably the single most useful resource in connection with the emacs manual and the emacs lisp reference manual.

Those resources are static, though. Sure, the manuals are updated as emacs changes and people update and improve the wiki as well. But by and large they are fixed resources.

But there are also a lot of resources on the web, that feature emacs-related stories on a regular basis as well. Some are collected via Planet Emacsen, but even though I don't want to sound too harsh, I think that the signal-to-noise ratio is a bit low over there. Here are a few sources of periodically updated emacs resources, that I actually enjoy:

Blogs:

• Emacs-Fu: Dirk-Jan Binnema's blog (otherwise known as "djcb"); around since 2008; this blog was one of the most helpful resources, when I made the transition to emacs.

• Mastering Emacs: Mickey Petersen's blog; younger than emacs-fu: started in 2010; original idea was to close the gap between the emacs tutorial and the knowledge required to understand how the emacs cosmos works; very neatly organised.

• Emacs Redux: Bozhidar Batsov's blog; started off in March of 2013, so this is the youngest of the mentioned blogs; always picks one topic and discusses in just about the right amount of extend; never too much, never too little; you should take a look.

Screencasts:

• Emacs Movies: This series by Noufal Ibrahim features in depth looks at different features and add-ons to emacs; lost a bit of steam in the last few month, but screencasts of that magnitude surely take a large amount of time to prepare.

• Emacs Rocks!: These are Magnar Sveen's short takes on interesting emacs features; short, sweet and entertaining; Magnar also has a blog: What the .emacs.d!? which I find a bit too terse, though.

So... this idea isn't new. The idea came up a couple of times in the last few years. The most concrete notions started to come up early in 2011, when sourceforge had their major downtime due to compromised infrastructure. With centralised version control, if the server is gone, you're kind of screwed. With distributed version control, it doesn't matter. You can just keep on working and if your usual canonical location doesn't come back to life you can just set up another one elsewhere.

• Absolute pathnames similar to expand-cmd-path
• Next release

I wasn't quite sure if it ever would, but now it finally happened:

• zsh has migrated from cvs to git

Side effect: Fast `diff' and `log' sub commands. ;)

Ihr kennt das: Man will irgendein Dokument abgeben, stellt aus Versehen, in großer Eile seine Kaffeetasse darauf ab und *schwupps* hat man einen Kaffeefleck gut sichtbar plaziert.

Fehlen diese Flecken, kann man schon mal auf die Idee kommen, daß der Autor zuviel Zeit übrig hat. Denn offenbar kann er Sorgfalt walten lassen, während er arbeitet. Um solchen Situationen aus dem Weg zu gehen, gibt es von Hanno Rein ein LaTeX Paket, das in der Lage ist, diese essentielle Verunreinigung automatisch hinzuzufügen. Hervorragende Lösung, für Leute mit vorhandener Komfortzone oder Nicht-Kaffeetrinker. ;)

• LaTeX Coffee Stains: Mit Beispiel-PDF!

Hanno hat auch schon ein paar Mitstreiter gefunden, die ihm Patches für sein Paket geschickt haben. Am besten gefällt mir die Verbesserung von Adrian Robson: "I find I rarely manage to put my coffee mug down exacly in the middle of my papers. So I have amended coffee3.sty to support off centre coffee stains."

Indeed.

I gave an introduction into the new promptsys themes in the last few days. The themes are part of grml's current zsh setup and cures one of the major issues I had with the setup. So that's great.

Recently however, fellow grml developer Evgeni Golov had a problem with the way in which Virtualenv extends existing shell prompts to reflect the effects of the package. What they did is essentially this:

PS1="foobar $PS1"

Which doesn't work with the way zsh's prompt themes work. As I've explained before, the prompt themes work as code that is registered to certain hooks, that takes control of the prompt variables. In our case, that's PS1 and RSP1. If you change PS1 in someplace, the theme code will just replace that value, with what the theme intents the prompt to look like. In any case, your change is gone.

Now, we could certainly add a special case for handling Virtualenv, but then the next day, the Ruby crowd will have something else that will require a special case; then any the the gazillion of linux distributions will have a special case... and that goes on and on. So instead, let's add something that enables the user to add items, he/she can then use in the items style for configuring the grml prompt theme. That would be a general solution, that people can use to extend the prompt's information gathering with at will. We like general solutions, so that's what we went with.

First, let's take a look at how to add new stuff: That's where the new `grml_theme_add_token()' function comes into play. If called without arguments, it will produce a short help text:

Usage: grml_theme_add_token <name> [-f|-i] <token/function> [<pre> <post>]

<name> is the name for the newly added token. If the `-f' or `-i' options
are used, <token/function> is the name of the function (see below for
details). Otherwise it is the literal token string to be used. <pre> and
<post> are optional.

Options:

 -f <function>   Use a function named `<function>' each time the token
                 is to be expanded.

 -i <function>   Use a function named `<function>' to initialise the
                 value of the token _once_ at runtime.

The functions are called with one argument: the token's new name. The
return value is expected in the $REPLY parameter. The use of these
options is mutually exclusive.

So it is as easy as this to add an item called `day', that is printed in green foreground colour:

grml_theme_add_token day '%D{%A}' '%F{green}' '%f'

Let's take a look at the Virtualenv case: The actual code does this:

PS1="(`basename \"$VIRTUAL_ENV\"`)$PS1")

We are using zsh, so we'll replace the basename with an expansion modifier. But other than that, the following could be a first version:

grml_theme_add_token virtual-env ${VIRTUAL_ENV+(${VIRTUAL_ENV:t}) }

Looks weird? It isn't. The parameter expansion form ${parameter+value} expands to value if $parameter is non-empty. So, if $VIRTUAL_ENV is non-empty, the value of the newly created `virtual-env' token is a string that is enclosed by parentheses and a trailing space. The string itself is ${VIRTUAL_ENV:t}. The ":t" has the effect of `basename': If you the value of the variable in question is "/some/where/on/disk", the ":t" modifier will cause the expansion to result in "disk".

This is what we wanted, so: YAY!

But wait a minute. What if the value of $VIRTUAL_ENV could potentially change during the lifetime of a shell session? This is only a static solution that wouldn't pick up on changes like that. Now, we could change the value a little bit and use zsh's "PROMPT_SUBST" option. That would work, but I don't like that option, because it makes the prompt somewhat fragile, depending on what strings you put in there. Luckily, our helper function provides its "-f" option. With that, instead of a static value, you may supply the name of a function, that produces the right expansion each time the prompt theme code runs. Let's introduce a function, called `virtual_env_prompt':

function virtual_env_prompt () {
    REPLY=${VIRTUAL_ENV+(${VIRTUAL_ENV:t}) }
}

That's exactly the same expansion as before but now it is done dynamically in a function, that is called at the right times. The system expects the function to return the value it produces in the $REPLY parameter. Which is exactly what the code does.

Now we just need to add a new token, that calls the function. If we'd like the new token to appear in magenta foreground colour whent it's expanded, as well, the definition call has to look like this:

grml_theme_add_token virtual-env -f virtual_env_prompt '%F{magenta}' '%f'

Now we got a new item, that we can just include in the `items' style, that configures the prompt (again, the default items list is available in the output of "prompt -h grml"). One appropriate customisation may look like this:

zstyle ':prompt:grml:left:setup' items rc virtual-env change-root \
                                       user at host path vcs percent

You can apply this sort of extension to pretty much any problem you encounter. This should also be the final requirement for our new prompt themes. If you really want to do something that goes beyond this, write your own prompt theme. ;)

Someone had a problem with the new prompt theme, which is going to hit other people who use the same sort of customisation as he did. So let's clear this up. If you're doing something like this in your `~/.zshrc.local':

# I want my own prompt!
PS1='%~ %# '

You will have to turn off the grml theme (and any other theme for that matter) beforehand. So your customisation becomes this:

# I want my own prompt!
prompt off
PS1='%~ %# '

I could have seen this coming, but I didn't. The theme system works by registering hooks at the right times to set prompt variables. This way you can jump between prompt themes however you please. "prompt clint" switches to the "clint" prompt, "prompt pws" to "pws" and "prompt grml" switches back to the "grml" theme. While this modularity is wanted within the system, so switching between prompts is possible (even for very complex prompts that do far more than just set $PS1) at relative ease, it conflicts with static prompt settings like the above, because the system takes control over how the prompt is set.

The "prompt off" call tells zsh's theme system to let go of $PS1 (or its synonym $PROMPT) and other prompt related variables, so your static setting will be picked up.

On a similar note, if you construct your prompt in `precmd()', you want to turn the theme system off, too.

If you have further questions or problems regarding the new prompt in grml's zshrc, drop by "#grml" on the freenode IRC network and tell us.

The zsh setup, provided by the grml team, enjoys a fair amount of popularity. One of the things we suck at (there are not a lot of those, but this definitely was one of them) was the way we were setting our prompt.

It used to be a conglomerate of string settings to "$PROMPT" with all the goodies you want to see in code you maintain: Inconceivable dependency upon random shell variables you never heard of, code and string duplication. It wasn't a pretty sight.

Needless to say, we didn't adhere to zsh's prompt system (or any other system for that matter) at all. There was a "$PROMPT" string, that was assembled at initialisation time, static precmd() and preexec() functions that did related stuff and no modularisation or customisability to speak of. If people wanted to do even little changes, our response was: "Look, wade through the zshrc file, and extract the precmd() function and all relevant lines that set $PROMPT and copy those to your `~/.zshrc.local' file and do your customisations there." It was truely rediculous.

But no more!

I spent the last two days to rewrite the whole way we went about dealing with prompts: It now conforms to zsh's prompt theme system; it is very much modularised; there is virtually no code duplication (except for maybe were a fallback prompt is defined, in case the prompt theme system isn't available); and about everything in the prompt can be customised via zsh's context-sensitive zstyle mechanism. It actually took a while until I had a mental model ready, of which I was convinced enough that it could handle all the aspects, that were important for maintaining a solid sense of backwards compatibility, while fixing all the things that were wrong with the old approach and adding all those features that we knew were nice to have. In the end, I came up with something that's largely based on the prompt I use in my own setup. Luckily however, we didn't need all of the complexity, so I was able to largely simplify the code. Simplified enough, that now grml's theming code is more readable than my own.

Anyway. Without further ado, here is the old prompt:

    

And here's the new one:

    

What!? Those are the same! ...Welcome to backward compatibility! :-)

The fun part about the new system is that the prompt is assembled from a set of items, that the user can decorate however he/she sees fit. So, say you don't like/need/want the version control part of the prompt, you can configure it away (the default list of items is available via the prompt's documentation "prompt -h grml"):

zstyle ':prompt:grml:left:setup' items rc change-root user at \
                                       host path percent

    
    [click thumbnail to enlarge]

It won't even run vcs_info anymore, because it doesn't need it.

Have the user-name green instead of blue? Sure, why not:

zstyle ':prompt:grml:left:items:user' pre '%F{green}'

    

Want to assemble it in a completely different way? Say with date and time instead of user@host and pathname and all that non-sense? Have it your way:

zstyle ':prompt:grml:left:setup' items date time percent

    

`date' and `time'? Those aren't in the default item list. Why would you implement superfluous stuff? Well, I didn't. The new setup ships three themes. They all share the same code, so they behave the same. But they use different default item lists by default. The grml-large theme uses `time' and `date'; so that's where those are from.

What do the other themes look like? Well, let the prompt system tell you:

prompt -p grml-large grml-chroot

    

(I'm setting $GRML_CHROOT before, because the `grml-chroot' theme is only used (by default) if that variable is non-empty.)

This should cure any urge for customisation with our esteemed user base. If you need more than this, write your own prompt theme. It's not hard.

Note: This code is in its own feature branch at the time of writing (you can still see those "ft/prompt-rewrite" strings in vcs_info's data), but a merge into master of grml-etc-core is imminent.

People often refered to emacs as being an awesome operating system, that thoroughly lacks a decent editor. I used to agree, because I vastly prefer modal editing as pioneered by vi and its various clones. But no more! While there have been multiple vi emulation modes for emacs (VIP and Viper for example; also vimpulse and vim-mode for a few of vim's more prominent features), none of them sat exactly comfortable with me. Then a few talented elisp hackers got together and wrote evil, the extensible vi layer for emacs.

Earlier today, Frank Fischer announced the release of version 1.0.0 of evil, which marks the first stable release of the software. I've been using evil for quite a while now and it is by far the single best piece of software to get modal editing into your emacs. Do check it out and let the developers know about any problems you encounter!

• Homepage
• Frank Fischer's 1.0.0 release announcement
• Page on emacswiki
• Mailinglist
• Git repository
• Michael Markert's rather large evil setup
• My rather small evil setup

Kennt ihr diese "127.0.0.1 sweet 127.0.0.1" Shirts? Für Computerhansel gibt's ja echt abartig viel lustigen Merchandise... ...für Nachrichtentechniker ist die Lage völlig anders. Da etwas spaßiges zu finden ist nicht direkt trivial. Um so neidischer bin ich ja auf einen Kollegen hier im Labor, der von Rohde&Schwarz eine Tasse mit nützlichen Umrechnungsskalen auf dem Tisch stehen hat. Die ist ein wenig so, wie die Referenz Tassen für Emacs und Vim. Nur etwas - nun - Hardware-näher. :-)

Nun hat aber der Timo, einer der Abschlußarbeiter hier im Labor, einen Geschenkkorb von R&S erbettelt und da waren ein paar wenige dieser Tassen mit drin. Ich hab dann beim Timo gebettelt und eine ab bekommen. :-)

    

Und aus der Nähe, damit man mal sieht, was für Skalen da überhaupt drauf sind:

    

Welches Amplitudenverhältnis stellen 6dB dar? Und für Leistungen? Welche Anpassung hat man nochmal bei einem Stehwellenverhältnis von 1.5? Wieviel Watt sind -100dBm? Das sind Dinge, die man im Griff hat, wenn man viel mit Netzwerkanalysatoren und Spektrum- bzw. Signalanalysatoren arbeitet. Aber das ist ja für "C-x C-c" bei emacs und ":wq" bei vim auch nicht anders. :)

Smack my Bitch up - Oktoberfestedition

Gut gemacht, trotz Oktoberfest. ;)