Tag Archive | vim

Stuff in my vimrc: 04 Spelling and Natural Language

I use vim for almost everything I write, regardless of that being a program, data file, email, blog post, research paper, etc. To write such things I need to use natural languages such as English. A blog post or documentation, for example, will be almost entirely in English. A program, while being a very different form of text, will still have variable names, comments, and so on, in English.

The thing is… Natural language is hard to spell, and I tend to make a few more typos then I would like. (I’m sure you will find some example in my blog posts).

Luckily, Vim comes with a built in spell check feature that works very well! In particular, it can do spell check in certain sections of code files. For example, while editing a Python file, it will do spell check in comments and identifier names. It will even spell check the individual words in an underscored identifier such_as_this.

Vim will also give the user correction options by pressing z=.

Like this, while using Vim, I can have a very high degree of certainty that what I’m writing is correctly spelled.

Basics In Vim

To get the basics working is pretty easy. To enable spell check we use the following command:

:set spell

We can set a language by using the command:

:set spelllang=en

Or, just join both:

:set spell spelllang=en

If all you want if to have English spell check enabled at startup, them simple place that last command in your vimrc, and your done. You might want to, at some point, change the language or turn off spell check, and when that happens, simple run these commands:

:set spelllang=pt
:set nospell

Off course, we can go a bit further then that. But first, I must speak about my usage of language in Vim.

My Natural Languages

The vast majority of time that I use Vim, I use it to write in English. But sometimes I want to write a text in another language, those languages being my native Portuguese or the language which I’m currently learning, German.

Because I use these three languages, it is very common that I open a new vim instance and want to quickly change the current spell checked languages from the default English to either Portuguese or German. So I’ve implemented a state machine that lets me alternate from English, to Portuguese, to German, back to English. The alternation happens when I press <leader>a.

It is also common for me to want to turn off spell check. This may happen because I might open some plain text file that may not contain an actual natural language text, or a language which I don’t use. It also may be that a given file type doesn’t have proper spell check like a Python file, so it happens that Vim identifies every ASCII character as a spelling mistake. To turn spell check off, and back on, I press <leader>s.

On The vimrc

This is the language section in the vimrc:

fu! InitLanguage()
    set spell spelllang=en
    let b:language = 0

fu! ToggleSpell()
    set spell!

" Function to toggle between the used languages
fu! ToggleLanguage()
    if b:language == 0
        set spelllang=pt
        let b:language = 1
    elseif b:language == 1
        set spelllang=de
        let b:language = 2
        set spelllang=en
        let b:language = 0

" Initialize language variables for every new buffer
autocmd BufWinEnter,FileType * :call InitLanguage()

" Toggle between the languages, or just toggle the spell functionality
nnoremap <silent> <leader>a :call ToggleLanguage()<CR>
nnoremap <silent> <leader>s :call ToggleSpell()<CR>

" Underline spelling mistakes
hi clear SpellBad
hi SpellBad cterm=underline

" Remove spell check from some files
autocmd BufEnter *.sql :set nospell
autocmd BufEnter *.erl :set nospell
autocmd BufEnter *.asm :set nospell
autocmd BufEnter *.s :set nospell
autocmd BufEnter *.go :set nospell

Functions and State Machine

To begin with, we define the functions InitLanguage, ToggleSpell, and ToggleLanguage. The first function simply sets spell check using the single liner like stated before and initializes the state machine. The second function toggles the value of the spell setting. So every time this is called, spell check either turns off or on. The third function alternated the three states of the state machine, making spell check go from EN, to PT, to DE, back to EN.

The state is kept by the variable b:language. It is a buffer variable (the leading b: indicates that). This because spell checking is kept at a buffer level, meaning that, different files in vim might be set to different spell checking languages.

Initialize Language

Continuing in the vimrc, we have the auto command:

" Initialize language variables for every new buffer
autocmd BufWinEnter,FileType * :call InitLanguage()

This makes Vim set our default spell check and initialize our state machine by running the init function. The function executes when a buffer is displayed in a window or when the file type for that buffer changes.

Key Binds

Next, we set the already mention key binds. They are <leader>a and <leader>s. Both are key binds for normal mode only:

" Toggle between the languages, or just toggle the spell functionality
nnoremap <silent> <leader>a :call ToggleLanguage()<CR>
nnoremap <silent> <leader>s :call ToggleSpell()<CR>


To display the actual errors, we need to tell vim to underline them using the following lines:

" Underline spelling mistakes
hi clear SpellBad
hi SpellBad cterm=underline

I only need this because there is a plugin that interferes with spelling underlining. Without these lines in my file, I don’t see spelling errors underlined.

Remove Spell Check For Certain File Types

With some file types, I prefer to simply have spell check off by default. This might happen because the spell checking in those files might not be good enough, or not exist at all.

To do this, I have the following auto commands

" Remove spell check from some files
autocmd BufEnter *.sql :set nospell
autocmd BufEnter *.erl :set nospell
autocmd BufEnter *.asm :set nospell
autocmd BufEnter *.s :set nospell
autocmd BufEnter *.go :set nospell

In order, we have files of types: SQL, Erlang, Assembly, Assembly* again, and Go. With Erlang and Assembly, the native syntax support does not distinguish what should be spell checked and what should not, so opening a file with spell check on will lead to having everything marked as an error.

With SQL and Go, spell checking works, but it happens that I see far to much code written in camel case, or having identifier names that are not regular words and are instead abbreviations. Because of this, a file in SQL or Go will be marked with many spelling errors, even if they are not technically an error.

Beside, I can simply do <leader>s to turn on spell checking to see if a comment, for example, is correctly written, and turn the thing off again to continue working.

(* By Assembly files with extensions .asm and .s, I mean programs written for the x86 instruction set using the AT&T syntax, since that was what I used when writing Assembly)


This is how I use spell checking in Vim. There are other native shortcuts that allow a user to jump to the next/previous error. I actually never use these, so I don’t even remember them.

<- Prev – 03 Folds and why I don’t use them

Stuff in my vimrc: 03 Folds and why I don’t use them

Part three is going to be a bit different. Initially, this part was suppose to be about Vim Folds and about what I have in my vimrc to handle them. But there isn’t much related with folds in my file, and I don’t usually use them in my workflow. Because of this I though about skipping this part entirely.

But then it hit me, rather then skipping, why don’t I simply talk about why I don’t use them and what I do instead to orientate myself in a big file of code?

What Folds Are

In any project, you’ll find files which have a few dozens of functions, classes, structures, etc. It is not easy to get a mental overview of such files, since you have to scroll though several lines of code, sometimes passing by functions or classes which have over 100 lines of code, 7 levels of indentation, and obscure names.

Off course, one can always argue that if a file as such structures, then the code might need to be refactored. Be that as it may, such files are out there, and we have to maintain them.

A very common way to get such an overview is to fold the code, like in this image:

This is folds.c file in the Vim code that implements this feature. In it, all of the code of the functions is folded away and we only see their names and order within the file. We quickly get an overview of the content with little to no scrolling.

Such folding features are present in most (if not all) IDEs and in many editors. Vim has folding out of the box. It comes with a variety of key binds based on using the z key to open and close folds, and like in anything else, you need to specify a few settings before being able to use it.

To enable folding, I have the following:

let c_no_comment_fold = 1

" Function to start using folds, but only when I want
fu! StartFolds()
    set foldnestmax=1     " Only fold one level
    set foldmethod=indent " Use syntax to determine where to fold

nnoremap <silent> <leader>z :call StartFolds()<CR>

There is a constant declarations, a function, and a custom key bind.

The constant c_no_comment_fold is there to make Vim not fold C-like comment blocks. These are blocks like so:

 * This is a C comment block

Such syntax is present in languages such as C, C++, C#, Go, Java, CSS, and so many many others. It just so happens that when I have folded code, I simply like to have the comments still present. This is because if I’m folding, then that is because I’m trying to understand the code in a file, and having any comments helping me with that task is important.

So having a bulk of code away of view is important until I decide to open it explicitly. But having a comment block is always important.

Next, the function StartFolds. This function only executes when I press the custom key bind defined right bellow <leader>z. This function simply sets the two variables:

set foldnestmax=1     " Only fold one level
set foldmethod=indent " Use syntax to determine where to fold

About foldnestmax. Vim can fold in many levels of indentation. Think for example that you can fold a whole function, an if block inside a function, an if block inside another if block, and so on. I decided that it is enough to fold only one level, so I set that option.

About foldmethod. Vim can fold according to many rules. For example, it is possible to set manual markers between two lines, and have Vim fold in those lines. It is also possible to let Vim fold according to the current syntax. I have it set to indent. Like this, Vim picks indentation blocks to fold.

My current setup could be improved by having a function to disable folding. And now that I’m writing this post I’m starting to think that I would like to try having manual markers…

Tag Bar as Alternative

The key issue is getting orientated in a big file and knowing what is declared in it. I like to use a tags bar:

A bar such as this gives me the necessary overview. I can sort the bar according to different rules, scroll it, and select one item to have my view jump directly to the element in the file. Because this is jumping, I can also use the Go Back feature builtin in Vim. Basically, every time you jump within a file or to another file in Vim, it creates an internal stack of locations. You can then traverse that stack backwards to get back to a previous location.

I have a simple key bind to show or hide the bar which is <leader>t. I usually only bring the bar up when I have a single file in view, or at most a vertical split. Anything else and the screen becomes to cluttered.

The content of the tags bar is filled according to the tag information of Vim. I use the plugin You Complete Me that fills that tag information. Off course, any tag information will always depend on how the support for tagging that a language as. So when working with a common programming language, you will most probably have tag information.

In future posts, I’ll talk about semantic completion and the usage of these plugins in more detail.

<- Prev – 02 File ExtentionsNext – 04 Spelling and Natural Language ->

Stuff in my vimrc: 02 File Extensions

In my previous post I wrote about the general settings in my vimrc. I continue to explore my file, hosted here. In this post, I’ll be talking about File Extensions.

File Extensions

When editing a file in Vim, you can choose which is its file type. Knowing the file type, Vim can load the correct syntax highlighting, and in some cases certain functionalities of plugins may be activated and used.

To have syntax highlighting, you need this setting:

syntax enable

After this, Vim will set the file type for any opened file automatically. So if you open a Python file, Vim will set the type to python, a JavaScript file will be javascript, and so on.

The user can always change the current file type to anything else. A common case is setting the file type to plaintext, which causes language specific syntax highlighting to go away but doesn’t shutdown the highlighting for other opened files:

set ft=plaintext

File Extension Conflicts

Sometimes, a file may be opened in Vim, but the file type is interpreted incorrectly. In this case we have to set the correct type by hand.

Take the example of opening a Prolog file. The file extension of Prolog is .pl. However, the extension for a Perl file is also .pl. So when a .pl file is open, regardless of it being a Prolog or Perl program, Vim assumes the Perl file type.

Vim assumes Perl simply because it is much more famous and highly used then Prolog. But for me personally, Prolog is more important. This is because I’ve made some development in Prolog in the passed, and have never actually used Perl for anything.

So every time I want to edit a Prolog file I would have to write:

set ft=prolog

But this would be extremely cumbersome to do. So I add an automatic command that executes every time a buffer which name ends in .pl is created or read. That line looks like this:

autocmd BufNewFile,BufRead *.pl :set ft=prolog

The command is autocmd, which is executed on the events BufNewFile or BufRead, for buffers which end in .pl. The automatic command which is executed is exactly what we saw before:

set ft=prolog

Like this, Vim assumes file type Prolog for any .pl file which I open.

File Extensions in my

At the time of writing, this section of my vimrc looks like this:

" Make .pl files load like Prolog and not like Perl
autocmd BufNewFile,BufRead *.pl :set ft=prolog

" Make .tex files load like tex files.
autocmd BufNewFile,BufRead *.tex :set ft=tex

" Make .md files load like Markdown files.
autocmd BufNewFile,BufRead *.md :set ft=markdown

" Make .rl file load as Go
autocmd BufNewFile,BufRead *.rl :set ft=go

" Make Emakefile files load like Erlang files.
autocmd BufNewFile,BufRead Emakefile :set ft=erlang

" Make ejs file load as HTML
autocmd BufNewFile,BufRead *.ejs :set ft=html

" Make .docker files load as Dockefile
autocmd BufNewFile,BufRead Dockerfile.* :set ft=dockerfile
autocmd BufNewFile,BufRead *.docker :set ft=dockerfile

Without these rules, .tex files would open as plaintext instead of LaTeX, and .md would also open as plain text instead of Markdown, although in recent versions of vim, they already open as Markdown out of the box.

The other rules I have are for specific library file types. We have the .rl files which are from a Go library called Ragel. This library is used to make Flex typed Lexers (to build parsers or compilers). I never actually used this library in a big project, but I’ve made experiments with it. Despite having a specific file name, the code contained in a Ragel file is Go, so my Vim will open these files as Go files.

I’ve made some experiments with Erlang, and I like the language quite a lot. The Emakefile is a specific type of Makefile to compile an Erlang program to the Beam Virtual Machine. Like Ragel, the code in these files is simply Erlang, hence the rule.

In a personal project I’ve made two years ago, I’ve used ejs, Embedded JavaScript Templating. This is a Node.js templating library which I used to generate static HTML pages for a simple web application. The library is very similar to other templating libraries, such as Django Templates, Go Temples, Java Spring Templates, and others.

I want to see the ejs files as HTML, despite the fact that some of its code (the actual template code) is JavaScript. When I worked with this, there was no way of having syntax highlighting for HTML and JavaScript at the same time in an ejs files, but since the templating part was so simple, it was also not needed.

Finally, the last part of this section is about Docker files. I’ve seen and worked on many projects that used files with names starting with Dockerfile. and others ending with .docker. I naturally have rules to make these files open with the file type Dockerfile.

<- Prev – 01 General Options | Next – 03 Folds and why I don’t use them ->

Stuff in my vimrc: 01 General Options

Vim has been one of the most important tools in my toolbox. Since 2013, it has been the editor I’ve used for everything. From developing projects in Python, Node, Go, C, to writing my Master’s Degree Thesis, and this Blog Post.

Customization is quite common when using Vim. We want different key binds and features, and it is through these key binds and features that we adapt and develop our own Workflow.

Vim Customization comes mostly by writing a vimrc file. In this series of blog post, I will talk about stuff I have in my vimrc file.

My vimrc file is hosted in here.


A vimrc file is usually developed overtime by the person who uses it. People sometimes take ideas from other people’s vimrc, but one should never copy a whole file.

My file is not particularly big. I have the following structure to it:

  • Plugins
  • General Options
  • File Extensions
  • Folds
  • Language
  • Highlight Unwanted Spaces
  • Maps and Keybinds
  • Plugin Specific Options

I’ll make a post for each of these points or for specific details within the points. I’ll start by the General Options section of the file. I’ll talk about the Plugins later.

General Options

The General Options have the most basic kind of settings. When I’m using an instance of Vim which doesn’t have any configuration, for example in a server, I usually some of this setting directly on the command line.

I’ll be talking about my choice of options in no particular order.


I like to have a background highlight in the line where the cursor is located. This line is present in every windows which is showing in a particular tab, so if I have the screen split to display multiple files, of many locations in the same file, the cursor line will still be highlighted, even if the cursor is not currently on that window.

Off course the lines are also numbered. I use the regular numbering as opposed to the relative numbering, since I could never get used to the regular numbering.

For these things, I use the following options:

set cursorline
set number

Tab Completion

Not to be confused with semantic completion, this is about how the tab completion for the vim command line works. I have a lot to say about semantic completion, but that is not in the scope of this particular blog post.

Out of the box, the completion of the vim command line works like this. Suppose you want to open a file called logging.py. So you write :e log and now you would press tab to autocomplete to :e logging.py. But instead, you get :e login.py.

This is because vim will pick the first alphabetical option from a pool of options and present it for autocompletion. If you press tab again, you would get the next option, and tab again, you get the next, and so on.

I prefer to see the list of options first, and then start tabbing over the options until the one I want. Inside the editor, be that to pick files or commands, this just seems to make more sense to me. So I use these options:

set wildmode=longest,list,full
set wildmenu


When you split the current window either horizontally or vertically to see different sections of a file, or another file, that is called… well, a split.

You can issue a command to split the current window and open a file in the split at the same time. The thing is, by default, vim splits the window and the new file will be on top or on the left, depending if the split if horizontal or vertical respectfully.

I prefer the opposite behavior. So, I can issue the command split newfile, and the new file will open in the split on the bottom. Same with vsplit newfile which opens the file in the split to the right.

I have these settings for this:

set splitbelow
set splitright

Backup Copy

In many projects, you have a workflow which works like this: The project is running, you change a file, something auto compiles your changed files, the project restarts or reloads, and you see the results of your changes right away. You see this, for example in Django projects, where the runserver reloads and restarts the server upon a file change, or in an Angular project, where the files are compiled, and the browser refreshes.

Sometimes, Vim doesn’t write the changes to disk right away, or only the .swp is written. When this happens, the autoload features simply don’t work, because no file change could be detected.

To avoid this, I have this option which guaranties that the files are always written to disk when I issue the save command:

set backupcopy=yes


I use spaces. Specifically, an indent block for me is four spaces. Unless a project requires tabs or a different indent block, I keep these settings.

I change the tab key to write an indent block instead of a tab character. Some file types, like Makefile, will ignore this behaviour since Makefiles actually need a tab character.

I also make it so a backspace over indent sections of the line deletes the whole block and not the individual spaces that make that block up. Lastly, in many languages, when I press return after an opened braked or after a colon, a new indent block is placed.

set shiftwidth=4 softtabstop=4
set tabstop=4
set expandtab
set backspace=indent,eol,start

Colors and Themes

I like light themes as opposed to dark themes. I also like the Solarized theme. I’ve been using Solarized Light for many years now, and don’t plan on changing it.

I use a Vim plugin to have the Solarized theme available and I set it as my theme with these commands:

set background=light
colorscheme solarized

So the theme is solarized, and the variant is light, as opposed to dark.

Next – 01 File Extensions ->

Compiling Vim

I’ve been using Vim since 2013. It is my main development tool for everything I do, both professionally and personally. I use it along a few plugins and I also add some costume commands, functions, and key binds to my vimrc file.

When I started using Vim I would simply install the vim-gnome package from the Debian repositories. But I like to keep up with the latest features, bug fixes, and improvements of the project. The easiest way to do so is to pull the latest version from the git repository, compile, and use it like that.

Here is what I do.

Get the Source

Vim is nowadays hosted at GitHub. The GitHub issues tracker is also used by the development team there, so if you are interested in contributing for Vim, this would be the place to go.

Since this is a Git repository, to begin we start by cloning the repository:

git clone https://github.com/vim/vim

At this point you might want to checkout a specific tag for a specific version of Vim. According to the Ubuntu 18.04 Bionic Beaver package page, the distributed Vim version for that Ubuntu is v8.0.1453, so you can checkout that tag since we are sure it is stable.

I keep up with the latest version, which would be ahead of version v8.0.1453.


Once we have the source we need to install a few packages in our system in order to compile Vim.

sudo apt-get install \
    build-essential \
    libncurses5-dev \
    libgnome2-dev \
    libgnomeui-dev \
    libgtk2.0-dev \
    libatk1.0-dev \
    libbonoboui2-dev \
    libcairo2-dev \
    libx11-dev \
    libxpm-dev \
    libxt-dev \
    python-dev \
    python3-dev \
    ruby-dev \
    lua5.1 \
    lua5.1-dev \
    libperl-dev \

In the list of packages we have things like build-essential which contains gcc and related tools, the libncurses5-def package which is the library that Vim uses to use ncurses, a few interpreter for python, ruby, etc, and few other things.

All this is necessary for the Vim I used. The Vim installed by the Debian package, gnome-vim, has similar dependencies.


To build Vim and make it ready for usage, we run the three usual steps, which are configure, make, and make install. First, here is the configuration I use for my build:

./configure --with-features=huge \
            --enable-multibyte \
            --enable-rubyinterp=yes \
            --enable-python3interp=yes \
            --with-python3-config-dir=/usr/lib/python3.4/config-3.4m-x86_64-linux-gnu \
            --enable-perlinterp=yes \
            --enable-luainterp=yes \
            --with-x=yes \
            --enable-cscope \

First, we have the flag for features. This flag defaults to huge, but we still set it explicitly:


There is a very big number of features which can be set or unset with the different values this flag takes. A listing of them is in here. Personally, I just leave the huge to enable everything, since that is what the Debian packages also do.

The next flag is used to compile Vim with multibyte support. This means that Vim will be able to use (natural) languages that need more then one byte per character, like Japanese, Chinese, and so on. Read more about it here.

Even if you only write English, you should still set this flag:


Next we have the interpreter:


I enable the interpreters for Python, Ruby, Perl, and Lua. I also set a specific path for the python interpreter. Without it, Vim could not find it.

We compile Vim with the X Windows System. This enables Vim to use the X’s Clipboard. Without this feature, copy and pasting to and from Vim becomes cumbersome. So we add:


Vim comes with support for cscope built in. If you don’t know what cscope is read here. I don’t do much C development nowadays, but still, I like to have this around.


Vim installs a few files which it needs at runtime for various purposes. These include, for example, the Syntax files, which set the specific syntax highlighting for each language. They also include the (natural) language files, the files which specify the color themes, and many other things.

The directory where these files is installed is specify by the following flag:


The default value of this flag is actually /usr/local. I believe that the Debian package for vim-gnome sets this prefix to /usr/share/vim/vim{VERSION}, since that is where these files show up in my system.

Build and Install

After the configuration is done, we simply run make and make install:

make install

You should be able to run vim now.

If you have any issues, such as missing features like the system clipboard, or Vim not being able to use the Python interpreter, check if the configuration flags are correct and if that step succeeds without issues.

Any change to that requires a new execution of make and make install. Just in case, you should also run make clean before.

New Ubuntu Setup – not_so_blue

I’ve been using Linux… I’ve been using Ubuntu since 2008. I saw many visual changes made to Ubuntu over the years, in particular there was that big change that made Ubuntu move from GNOME to Unity.

When I discovered /r/unixporn I was shock at finding out how I was missing out in terms of customization, and particularly in how I was missing out on tilling windows managers. Since them, I’ve made two setups. In this post I describe my third setup.

Tiling Windows Manager

The first two setups I had that had tiling managers used XMonad. XMonad is a manager that is programmed in Haskell and uses Haskell for configuration. I was a bit tired of XMonad because it felt a bit slow. I could actually see the tiles getting redrawn every time I changed workspace and there was always a laggy flash when I changed the tiles’ orientation. Also, I’ve tried learning Haskell but after a few hours spent with it I got to the conclusion that it is an annoying language and I don’t like it. So, I’m not really into configuring XMonad.

I decided to drop XMonad and try another manager. I tried i3 and I liked it way better.

First, i3 lets the user split tiles and move them around at will. It doesn’t stick with a more strict structure. You can also take a bunch of tiles and make them tabbed or stacked for different usages. It very cool.

Second, the problems I was having with lag in XMonad are not present in i3. My PC is a bit old and it was never a high performance machine. But Common! I’m not exactly rendering 3D graphics in Full HD resolution at 60 fps. i3 runs smoothly!

Third, configuring i3 is not done with any programming language directly like other managers. But its configuration features is enough to respond to my immediate needs.

Fourth, the default command are better.

My configuration file for my i3 setup at GitHub.

i3bar, dmenu, and Other Details

In my first setup I used a simple text based bar. But it was a terrible experience. In my second setup I used GNOME’s panel that came with GNOME for Ubuntu, and it was better.

This time I’m using i3bar and it is even better!! I use it pretty much out of the box and didn’t look much into its configurations because what I have now suits me just fine. Its configuration file is at GitHub.

To start any program in the background without having to open a terminal I just use dmenu. I use it with the option to make it show up at the bottom because I prefer it like that. The rest is out of the box! I may change its font later.

As a network manager I just use the nm_applet program that comes with Ubuntu. It works just fine.

The terminal I’m using is the gnome-terminal. The shell I’m using is zsh with the oh-my-zsh. I’ve thought about using other terminal and terminal multiplexer and all that. But I’ve never gotten around to do that. Using tmux might be cool.

I use Vim for every programming and file editing need I’ve add for some time. I enjoy the modal editing notion of Vim and all its other features. Using Vim in these kinds of setups is a perfect combination because of how it fells, meaning that everything you do is done thought key binds that make sens and you never have to use the mouse, and how it looks, which is good.

Colors and Wallpaper

In my previous setup I used the Solarized has the set of colors for everything. I never made my own color pallet or my own themes for Vim, terminal and tiles. But Solarized just looks good, and it is popular. For this setup I’ve sticked with it.

I needed a new wallpaper. I was using a wallpaper with the world map with timezones. But now I wanted something different. I decided to make a python script that used matplotlib to draw three sine waves, sum them toggether and draw that result. I also placed some hexadecimal characters in the bottom right corner. The hexadecimal is just the following text: “This is a sample text. K”.

I used the Solarized colors for the wallpaper. It looks… cool. I like it like this. I may change a few things.


I tried using Conky in the passed but never really did anything with it. This time I looked into it, copied this configuration, changed it a bit and now have two simple Conky windows in the background.

One of the windows shows the processes running (top), and the other shows information on CPU, memory and swap usage. With the wallpaper they actually look pretty cool.

I may add a window to show information on the network on some other thing. But for now I like it like this.


Here are the results. Three screen shows, taken with scrot, one clean and two dirty. The first screen shows Vim and two terminal windows opened. The second shows screen fetch and the colors used.

clean dirty_1 dirty_2

I also recorded a 1 minute video to show this setup in usage.

I am very satisfied with this setup!