Wednesday, 7 May 2014

Pentadactyl: The better Vim Monster for Firefox

Most people who love Vim have like the idea of bringing vim-like behaviour to browsers. The quality of actual implementations have been mixed. There are some extensions for Chrome which in my opinion all lack functionality. And there is dwb which is a complete browser based on vim-like-behaviour (Which is really nice but dwb likes to crash and hang quite a lot.). And there is Vimperator, the Firefox monster. A slow, creaky beast. I used it as it was the best option so far but it has some serious flaws. Fortunately, most of the developers behind Vimperator have forked their own project: Pentadactyl It is an amazing extension for Firefox. It is faster and more like Vim than Vimperator. You should give it a try!


Check out Pentadactyl here:
(1) Homepage: http://5digits.org/pentadactyl/
(2) Google Code: https://code.google.com/p/dactyl/
(3) Firefox plugin: https://addons.mozilla.org/en-US/firefox/addon/pentadactyl/

Take care,
Christian

Wednesday, 30 April 2014

tslime.vim: Send commands from vim to a running tmux session

As I am doing a lot of programming in R and Julia and my favourite text editor for such repl sessions is Vim it was only logical to look into possible ways to combine Vim and different repl sessions at the same time. I only placed the following condition on such a solution: It must be as simple as possible. I found tslime.vim but thought it lacked some features. Thus, I forked it and added some changes I thought would make it even better. One of my main objectives is to keep it as simple as possible (asap). This means the script does not pull in any dependencies or requires the presence of any other programming language. Here is the summary of what this script does:

It is a simple vim script to send portion of text from a vim buffer to a running tmux session.
It is based on slime.vim http://technotales.wordpress.com/2007/10/03/like-slime-for-vim/, but use tmux instead of screen. However, compared to tmux, screen doesn't have the notion of panes. So, the script was adapted to take panes into account.
Note: If you use version of tmux ealier than 1.3, you should use the stable branch. The version available in that branch isn't aware of panes so it will paste to pane 0 of the window.

(1) This fork provides the ability to send multiple keys to a tmux target at once.
(2) The tmux target is set on buffer basis. This means that every tab in Vim can have its own tmux target. (E.g. you could have a tab in which you edit a Python script and send text and keys to a Python repl and another tab in which you edit an R script and send text and keys to an R repl. See picture.)




(3) This fork allows you to refer to panes either via their dynamic identifier which is a simple number. Or via their unique identifier which is a number prefixed with %.

a) Demonstrative Reference/Dynamic Reference: If you choose to refer to a pane via its dynamic identifier the target of any given send function in this script will change when you insert a new pane before the pane you used.

b) Proper Name/Static Reference: If you choose to refer to a pane via its unique identifier the target of any given send function in this script will stay fixed.

Tip: You can find out the unique identifier of a pane by either passing tmux list-panes -t x where x is the name of the session. Or (the easier way) you let the unique identifier of every pane be shown in your tmux status bar with the option #D; e.g.: set -g status-left #D. (All possible options about what to display in the statusbar can be found via man tmux or some internet searching.)

(4) In this fork of tslime.vim, keybindings are not set automatically for you. Instead, you can map whatever you'd like to one of the plugin-specific bindings in your .vimrc file.

The script can be downloaded here:  https://github.com/lord-garbage/tslime.vim


Take care,
Christian

Sunday, 23 February 2014

Prevent Google Hangouts from auto-adjusting volume levels

A lot of users have noticed that Google Hangouts auto-adjusts your microphone and volume level. This is quite annoying leading to most unpleasant problems while hanging out (on Google). But there is an easy workaround for GNU/Linux-distributions. Got to ~/.config/google-googletalkplugin/ and edit the file named “options”. In it you will find the following variables:

audio-flags=  
audio-input=
audio-output=
known-audio-flags=

video-capture=

Now, set audio-flags from its current value (most likely 16) to 1:

audio-flags=1

Reboot your system and your done.

P.S.: Here is an optional test to see if it worked. Before changing the value in ~/.config/google-googletalkplugin/options open a terminal and type alsamixer. Then press F4 to go to the capture devices sections. There you will see a bar entitled “capture” set it to a high value such as 90 or so. Then open Google Hangout with a friend (or not - that doesn’t really matter). Say a couple of loud things and observe how Google adjusts the level as shown in the capture bar.

Now go on and make the changes as explained above. (Don’t forget to reboot.) Then repeat the test-procedure I just explained and observe that Google won’t adjust the level as shown in the capture bar anymore.

Take Care
Christian

Saturday, 8 February 2014

Mutt and Ethan Schoonover’s solarized color scheme

I am a huge fan of Ethan Schoonover’s solarized color palette. Basically, I use it with every application which allows me to do so: xterm, dwm and of course the mighty mutt. But as some people have noticed when mutt is compiled against ncurses not all colors of the solarized scheme are displayed correctly. To wit:

Names and Subjects blackened.

I use the light solarized scheme. So obviously the background should not be, well..., black. (One obvious solution would be to compile mutt against slang. Not a solution I prefer as I do not want to install another package. Keeping a minimal system etc. etc. blabla... Ncurses is good enough.)

I found the problem in my case to be my xterm background. I already use the solarized light scheme in xterm. Hence, the colors that get called by the mutt color scheme file seem to conflict with the background of my xterm. (Just my crude approximation of the problem.) This can be avoided by substituting some color definitions in the mutt solarized color file. The solution is to replace a lot of the very specific color specifications of the colorscheme by the value default. I have done this in the file you can download here. Although, this is only a solution for the light solarized 256 color scheme (And maybe even one only for my specific case.) it may give a hint that leads to a final solution.

After substituting the correct value:

Names and Subjects blackened.

Take care,
Christian

Wednesday, 20 November 2013

Copy from Vim to the clipboard without +xterm_clipboard enabled

The easiest way to copy from terminal-based Vim to the system clipboard without the +xterm_clipboard option compiled in your version is to edit your ~/.vimrc for a Linux system or, if you’re using Windows for whatever strange reason (joking), to edit your _vimrc file. The advantage is that you won’t need to recompile your own version of vim. Just comment out the following line:

set mouse=a

with

" set mouse=a

The cost is obvious, you will not be able to use the mouse in Vim. Hence, whereas before you could use the mouse to select portions of text in Vim and yank it to some buffer via y or yy you will now not be able to do so. Instead the highlighted text will now be treated the same way text is treated you select in your terminal or in other applications that do not have their own clipboards. Thus, you can copy the highlighted text in your terminal with the command (at least on Linux) ctrl+shift+C to the system clipboard and it is now available to other applications besides Vim.

If you have been using the mouse in Vim until now, commenting out the mouse-usage option in your ~/.vimrc file is a good opportunity to familiarize yourself with the beauties of a purely keyboard controlled editor. I would suggest that only now you can really start using Vim the way it was designed to be used. And while you’re at it you should really read this: Vim: Seven habits of effective text editing. Believe me, if you plan on using Vim or even if you have been using Vim for a long time but haven’t read this it is time well spent.

Linux hint: Another thing I deem useful is to enable copy on select in your terminal. By doing this you will save the time you need to press ctrl+shift+C.

Take Care,
Christian

Thursday, 5 September 2013

Spotify for OpenSuse 12.3: *.rpm package creation instructions and precompiled *.rpm package

Once again: Spotify has been available as a beta version for Linux for some time now but as far as I know only for *.deb (Quick remark: I use the symbol “*” as a string variable that in a specific situation needs to be replaced by the actual name of the package or file I'm referring to.) based distributions. I recently switched to OpenSuse 12.3 for technical reasons and wanted to install Spotify. This time I decided to post instructions on how to compile a *.rpm package from the most current *.deb package and at the same time provide a precompiled package. Here are the instructions:

0. Issue the command:
script spotify.log
to create a *.log file that serves as a documentation for what you did. (This step is optional and is only done in order to help you to reverse any changes you made to your system if you decide to uninstall Spotify later e. g. if a native OpenSuse package should be available at some point. I usually create *.log files with script to be able to reverse any changes I made that bypassed the software management system. Here it will be helpful because you can remove the symlinks you're going to create at the end of the installation process.)

1. Download the current *.deb package from http://repository.spotify.com/pool/non-free/s/spotify/.

2. Make sure that you have the “alien” and “rpm-build” packages installed on your *.rpm based distro.

3. Issue the following command: 
sudo alien -r *.deb
The command should exit with:
*.rpm generated

4. Next use:
sudo zypper install *.rpm
During the installation (at least on OpenSuse 12.3) you will run into the following problem:
Problem: nothing provides libcrypto.so.0.9.8(OPENSSL_0.9.8)(64bit) needed by spotify-client-0.9.1.55.gbdd3b79.203-2.x86_64
 Solution 1: do not install spotify-client-0.9.1.55.gbdd3b79.203-2.x86_64
 Solution 2: break spotify-client-0.9.1.55.gbdd3b79.203-2.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/c] (c):
Choose 2.

5. Set necessary symlinks:
sudo ln -s /usr/lib64/libnss3.so /usr/lib64/libnss3.so.1d
sudo ln -s /usr/lib64/libnssutil3.so /usr/lib64/libnssutil3.so.1d
sudo ln -s /usr/lib64/libsmime3.so /usr/lib64/libsmime3.so.1d
sudo ln -s libplc4.so /usr/lib64/libplc4.so.0d
sudo ln -s libnspr4.so /usr/lib64/libnspr4.so.0d

6. Issue the command:
exit
This will stop the script command started in step 0 and finish the creation of the spotify.log file.

If you want the easy solution:
Download the precompiled package here. Then only create the symlinks as is explained under 5.


Take Care,
Christian

Wednesday, 24 July 2013

Spotify for Fedora 19

A quick update: Spotify has been available as a beta version for Linux for some time now but as far as I know only for *.deb based distributions. If you wanted to install Spotify on *.rpm based distros you needed to compile it from source. I’m glad to announce this is no longer necessary. Find a precompiled package for Fedora 19 (the distro I use) here.

Take Care,
Christian