ftblog

...auf der Suche nach einem IRC Client.

Momentan nutze ich irssi. Von der grundsätzlichen Funktionalität ist der ja
ganz nett. Aber ich habe zwei Dinge, die mich über alle Masse nerven. Erstens,
ist irssi praktisch undokumentiert. Die Kommandos haben Online-Hilfe. Nett,
aber wenn man das Ding anpassen will... die Formate? das Perlinterface? Nada.
Und zweitens: die Art und Weise wie irssi seine Konfiguration handhabt. Das
Ding ist so konzipiert, das man über "/set" Kommandos konfiguriert und dann
Änderungen per "/save" auf die Platte bringt. Völliger Scheiß, wenn man die
Konfiguration in Versionskontrolle pflegen will. Nun kann man da wenn man
vorsichtig ist, eine Menge machen. Aber da nichts richtig dokumentiert ist,
weiß man nie in welcher Sektion welche Variable erwartet wird... Ausserdem ist
die Syntax der Konfigurationsdatei einigermassen gewöhnungsbedürftig.

Lange Rede, kurzer Sinn: Ich suche Ersatz.

Die coolen Kinder heut zu Tage scheinen ja weechat zu nutzen. Aber mal
ehrlich, die default Konfiguration ist nicht auszuhalten. Ständig wechselnde
Farben für alle möglichen Nicks im Channel? Eine Nickliste? Come on... Das ist
in jedem Fall keine Alternative für mich. (Ja, ich habe einige der nervenden
Dinge abgeschaltet, aber ich habe keine Lust Default-Settings aufzuräumen. Ich
komme klar, wenn ein Programm sehr spartanisch daher kommt und ich dann alles
meinem Gusto entsprechend einstelle. Aber ich habe genau keine Lust ein
Feature-ShowOff aufzuräumen.) - Oh, und weechats Config in VCS aufzubewahren
ist auch nicht trivial, da jeder Plugin seine eigene Config hat. Auch
ini-artig mit Sektionen. Die Doku ist besser (lies: kompletter) als bei irssi,
aber nichts, was mich aus den Socken hauen würde.

Ich möchte einen Multi-Fenster-Programm haben. Jeder Channel soll sein Fenster
haben. Das Programm der Wahl muß im Terminal laufen können. Ich will Support
für SSL Verbindungen. Brauchbaren Support für Nickserv. Automatisches Setup
beim Start (also, verbinden zu N Server, dann Nickserv wenn nötig, und erst
dann Channel joinen - und zwar in die richtigen Fenster).

Was bleibt mir also? Ich habe EPIC5 ausgechecked. Das ist vom Interface sehr
nett. Aber ich sehe Null Unterstützung für Nickserv oder automatisches Setup.
Ich will das eigentlich nicht alles ranskripten müssen. Aber wenn es keinen
anderen Kandidaten gibt, dann werde ich das vielleicht müssen. Die Doku könnte
auch besser sein.

Ich schaue mir grad auch `sirc' an. Das ist ein Client in Perl. Aber auch wenn
ich die Sprache mag, der Client wird mein Leben glaube ich nicht ändern.

Gibt's da noch sinnvolle Alternativen?

Letztens meinte mal jemand in #grml, daß `git-svn' der einzige brauchbare
Subversion Client sei. Und nun, da ich das Ding seit ein paar Wochen nutze, da
muß ich vorbehaltlos zustimmen. Ich fasse das svn Ding selbst nur noch an,
wenn ich nicht plane am Code zu schrauben und nur den Trunk tracken will.

IK a cappella.

Die C=64 Version. Eh klar.

I've recently started to use zsh's vi like keyboard mode. I used to say, that
this was pretty much unusable for me, even though I'm a long-time vi user.

Sometimes however, I was missing some of the command-mode (well actually in
vi-lingo, that's "normal mode"...) editing capabilities. So, I tried to use
zsh's vi emulation. The biggest drawback for me was, that - since I'm using
many many shells in parallel - I was easily losing track of what mode a shell
was in. Was it insert mode? Command mode? Did I enable the overwrite bit?

I knew zsh gained the ability of running a special zle widget when there is
a keymap change. That's pretty good for tracking the keyboard state. Good,
but not perfect. So I worked out a few issues I was having and ultimately
came up with the following: ft's example vi mode setup for zsh

I'm tracking the current keyboard state in `psvar[1]' and use that at the
start of my prompt definition (the `i', `c', `im' etc. strings in the
following screenshots). At first I'll load up an xterm that runs zsh without
any configuration (the `-f' option):

PS1='zsh%% ' xterm -e zsh -f


Then I'm loading my example setup, which drops me into the following session:



See the little `i' at the beginning of the line? That tells me, I'm in insert
mode. There is a variable in my setup - `zle_default_mode' - which, if set to
`cmd' will cause zsh to put the line editor into command mode per default. I
used to think that was a very good idea. But I've since switched back to
insert mode per default. The code supports both modes as the default, though.

Like in vi, hitting `ESC' brings us to command mode. Or does it?
Well, in this setup it doesn't at least not per default. Why? First of all,
hitting Ctrl-d is easier then ESC (No, really. I'm doing that in vim and also
in emacs' viper mode). Also, in many terminals you'll experience a slight
delay between hitting ESC and the shell taking any action. That's due to how
the terminal interprets escape sequences; and you can't do much about it. If
you'd prefer to use `ESC' instead of `Ctrl-d' anyway, you can do that by
setting the variable `zle_use_ctrl_d' to `no'.

Here's how my prompt looks like after hitting `Ctrl-d'. The `c' tells me, my
shell's line editor is now in command mode:



Now let's go back to insert mode, but turn on the overwrite bit. That'll cause
the shell to overwrite an existing character if the cursor is on said
character and a new character is entered. Like in vi, hitting `R' will do that
for us (and the `r' will tell us of the mode change:



Now we'll hit `Ctrl-d' and `i' to go back to insert mode:



Now let's use a widget that opens a minibuffer; like one of the incremental
history searching widgets:



Since we moved from insert mode to a minibuffer, the prompt shows `im'. The
`m' signals the existence of a minibuffer.

Escaping from that minibuffer, by using `Ctrl-g' or `Ctrl-c' will also reset
the keyboard mode in the prompt:



The same works from command mode, too. Let's enter one of the vi-mode history
searching widgets:



Hitting `Ctrl-c' gets us back out of that again and the prompt will only
contain a `c' to tell us, the minibuffer is gone.

That's almost all. Almost.
Remember that I'm using `Ctrl-d' to switch from insert mode to command mode?
Sure you do. What about that key sending an `end-of-file' character, which
closes the shell quickly? Yeah. Bummer. But here's my way out. I've created
a widget which goes by the name `q'. So you can do `:q' like you would to
close vi. And to remind people about that, hitting `Ctrl-d' in command mode
will display the following:




There's one problem with this setup: When using the `execute-named-command'
widget, we cannot do any proper signaling at all. That's because you cannot
wrap that widget into your own. There's some nastiness in zsh's source code
that prevents that from working. See

    http://www.zsh.org/mla/workers/2005/msg00384.html

for details. If you read that thread, you'll conclude that fixing this
requires quite some knowledge of the involved code. And that takes me out of
the picture. :)

Until that gets fixed, you'll be seeing an `i' while `execute-named-command'
is active. Deal with it. Because except for that, this seems to be working
pretty damn well.

...buy him a beer.
Single Malt Scotch Whisky has been reported to work as well. :)

Das wird nun sicherlich alle genau so sehr schockieren wie mich... :-)

Mit Google Wave ist dann mal Schluß.

In dieser Ausgabe von ZUW: OpenBSD kann nun Multi-byte Locales

Dude. FRIENDSHIP OVER!

Abgefahren. Ehrlich.

Gerade mal eben meinen alten last.fm Account in Betrieb genommen. Mit xmms2
und xmms2-scrobbler - von cmc gesteuert. Man beachte wann ich das letzte mal
etwas davor "gescrobbled" habe. :-)

% perl6 -e \"Hello\ World.\".say
Hello World.

Rakudo Perl6!

There are a lot of possibilities for testing graphical user interfaces. If
you're more into terminal based applications you don't have such a plethora
to choose from. Andreas Krennmair's tuitest is the tool you're looking for
if you want to test your *curses/slang program's interface.

I'm using it for a pet project of mine and it works quite well. You record
a session using `tt-record' and that generates a ruby script which replays
the whole session and you can put in things you expect to happen. Andreas
made a short introduction in his blog (it's in German).

Now, using tuitest on Debian lenny is kind of a problem if you want it to
happen out of the box. The ruby static library is named differently from
what tuitest's Makefile expects and the installation directory is not
among the default search paths of the ruby1.8 interpreter.

Here's a patch which should fix the issue:

diff --git a/Makefile b/Makefile
index 0e1910b..ad059d0 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ $(TARGET): $(RECORDOBJS)
 
 $(RUBYMOD): $(RUBYMODOBJS)
 	cd swig && swig -ruby tuitest.i && ruby extconf.rb
-	$(MAKE) -C swig clean && $(MAKE) -C swig LIBS+="$(patsubst %,../%,$(RUBYMODOBJS)) $(LIBS) -lruby"
+	$(MAKE) -C swig clean && $(MAKE) -C swig LIBS+="$(patsubst %,../%,$(RUBYMODOBJS)) $(LIBS) -lruby1.8-static"
 
 %.o: %.c
 	$(CC) -o $@ $(CFLAGS) -c $<
@@ -37,7 +37,7 @@ $(RUBYMOD): $(RUBYMODOBJS)
 install:
 	mkdir -p $(DESTDIR)$(prefix)/bin
 	install -m 755 tt-record $(DESTDIR)$(prefix)/bin
-	$(MAKE) -C swig DESTDIR=$(DESTDIR) prefix=$(prefix) sitedir='$(DESTDIR)$(prefix)/lib/ruby' install
+	$(MAKE) -C swig DESTDIR=$(DESTDIR) prefix=$(prefix) sitedir='$(DESTDIR)$(prefix)/lib/site_ruby' install
 
 distclean clean: doc-clean
 	test -f swig/Makefile && $(MAKE) -C swig clean

Here's a link to a clean patch file: tuitest-on-lenny.patch.
Happy tui testing!