Posts Tagged ‘gVim’

Programming is one of my primary interests, mainly because it allows me to stimulate my brain with solving problems, but also force it to think in new ways.

Languages

I started programming in PHP, picked up Java and Erlang during classes at ITU, picked up Python on my own during my studies at ITU, and my latest addition would be shell scripting.

Slightly tangent to the topic are the markup languages I have picked up as well, html and css in high-school and LaTeX at ITU. I dabbled around for a while with both creole and markdown, but that didn’t last long.

Editor / IDE

My first and foremost tool of choice given nearly any situation will be (g)vim. The only two exceptions I can think of off the bat is Java (for which I use Eclipse and if I need to write a whole lot of text, with minimal distraction (more on that later).

The pragmatic programmers recommend learning one text-editor, and learn it well. If the name of that editor is vim, emacs, kate, gedit, or whatever, I really don’t care. Just pick up one that fits you, and LEARN IT WELL!

I have extended vim with a couple of plugins, the most prominent being NERD Commenter, matchit, snipMate and sparkup. There are at least two more plugins, but I will write more about those later.

And for Python, I usually install the IPython interactive prompt as it is a fair bit more useful than the standard python-prompt.

Version Control

While studying at ITU I had my eyes opened about the wonderful concept of version control.

I was first exposed to SVN, and while quite capable, I figured it was too much of a hassle to set it up myself, since that would require the presence of a server somewhere to host the SVN repositories.

But then mercurial entered the stage. Git or bazaar would have done the job just as good, but the people orchestrating the fourth term settled on mercurial, and it is so dead simple and still powerful enough for what I need that I haven’t had a reason to look elsewhere.

Issue tracking

For a course at ITU I tried using Mantis, a web-based bug tracker written in PHP, and while it worked well, it was a hassle to manipulate bug reports since it meant I’d have to go online and log in to yet another system.

I have however found a different solution which I am currently trying out: a plugin to mercurial called b with the tagline “distributed bug tracking”. It is a bit too early to tell if it will do, but for the time being it solves the immediate problem of having to go online somewhere to handle bugs.

Ok, so another adventure today… the story begins with a MySQL dump of a Drupal database, and inserts so large they span more than a screen. This ended with me wishing for a less cluttered dump, say, with only the “INSERT INTO …” statements left in the file.

This morning Identi.ca helped me learn something new about Vim; vimgrep. Granted, most, if not all, of these micro posts only point you in the right direction, then you need to actively go and search the knowledge out, which I did. Thesetwo pages in particular helped me out understanding how it works.

$ echo "# TODO:" > test1.py
$ echo "# TODO:" > test2.py
$ gvim

This just creates two files containing a “TODO” comment (i.e. something we wish to search for later), and starts up an instance of gvim. Then, inside gvim:

:vimgrep /TODO/gj ./*.py
:copen

This will search through all files in the current directory with the .py extension, looking for “TODO” and add the results to a list, which, if I have understood everything correctly, is called the quickfix list. :copen opens that quickfix list.

The result will be that the vim window is split in two, the upper window showing nothing (as we have yet to select one of the files listed in the window below), and the lower window listing all files matching the search.

The lower window will have focus, so just navigate to a file you wish to work with and hit enter. The file will open in the upper window, and that window will have focus now.

This is when I sat down and took the time to learn about “C^w k“, “C^w j” and “C^w o“. The first two are navigational, jumping up (k) and down (j) between the windows, while “C^w o” will close all but the window with focus. Nifty!

Being the curious person I am, I sought and found what it is and does. It adds wavy red underlines in Vim to Python code which is determined incorrect. I tried it out just for a second, seeing if it could keep all it promised, and it indeed seem like it. It identifies unnecessary (unused) imports, it identified when I tried to append stuff to a variable I hadn’t declared as a list yet. All in all pretty nice.

I would have to say that I didn’t care much for the packaging of the vim-scripts, when I extracted them they spread over my ~/src directory instead of confining themselves to a pyflakes-vim/ directory inside the ~/src directory, but it was only three items, a readme, a script and a directory. Easily moved. Installation from that point was even simpler.

And then I came along this post which got me thinking about what software I ended up using towards the end of my bachelors. Or the software I have learned of since, but wish I’d known about earlier. I began to write a comment to her post, but realized that it would be too long, so I write here instead. All credit to Hazel though, since without her post I wouldn’t have been inspired to write this one.

My list, as compared to Hazels, will not be as well-rounded, it won’t necessarily fit every student the way her list do. Also, the software I list will only be guaranteed to work in GNU/Linux, as that is what I used in the final semesters, and have continued to use since.

First of all, a text editor. It doesn’t really matter which, just evaluate a bunch until you find one you feel comfortable with. Once you have found “the one” become intimate with it. Become a frakking Jedi-master at wielding it. I’m still a padawan-level user of Vim, but I’m getting there.

I say the same about web browsers, mail clients and instant messaging clients. Find a good one, learn as much as you can about it, and use it effectively. Firefox, Thunderbird and Pidgin are my preferred tools.

A bug-tracker, although often web based creating a need for a web server, can often provide more “good stuff” than just tracking bugs. Stuff like statistics, or, if you think outside the box you’d be able to track things other than bugs, which I guess it was issue-trackers does. Some of these also include a wiki-system, which makes establishing a project-specific knowledge-base kindof easy. In the one university project where we used such a system (and where I realized its potential) we used Trac.

A blogging-system with an RSS-feed capable of being filtered on tags or categories could be used to distribute status updates to other members of a group. That I’m using WordPress should be fairly obvious to all.

Use a version control system wherever and whenever possible. With the next two suggestions on the list, “wherever” will be a lot more commonplace than one might first believe, even for non-programmers. At the university we had access to SVN-servers, and also tried Mercurial, a distributed vcs. Mercurial stuck with me ever since.

From generic suggestions, let’s go specific.

I could encourage you to check out markup languages such as reStructuredText or Markdown, to find one which suits you best and to run with it. And since I’ve now written the terms you’d need to Google, you could do that, but I’ll simply recommend LaTeX. The reason for markup languages in general, and LaTeX specifically is that you can then store your information in one plaintext format (which makes it easy to manage in version control) and can then transform it to a slew of other formats as needed.

Most of the time we needed to hand in PDFs. LaTeX excels in that and manages all the typesetting stuff and (obvious) formatting. Which leaves you with more time to focus on the content. One could also either extend LaTeX with Beamer, to create presentations, or simply generate a PDF and run Impress!ve.

For diagrams, graphs and flowcharts or representations of state-machines, Graphviz would be my recommended way to go. Again using plaintext to control the content, again with the benefits of version control. Inkscape saves files in the SVG format (again, plaintext) which might be usable (especially since it can also save files as both PS and PDF)

If you need graphical representations of statistical data or other plots, matplotlib could be the way to go.

I personally don’t like managing things, or management-related stuff, but lately I have been haunted by the feeling that if I used management tools, even if I would only be managing myself and my pet projects, I could be more organized and efficient. So I have started looking at TaskJuggler. It is similar to Microsoft Project, with the largest difference being that… you guessed it, you code the project plan ;D. Plaintext yet again. And then you compile the plan and TaskJuggler attempts to verify that no resources have been double-booked.

Considering each piece in this list on their own, it might seem like a waste of time to exchange one software with another. I do find each of these softwares impressive in and on their own, but it is when they are put together, when all their strengths are combined, that you tend to get the most out of it.

The all plaintext approach I have tried, both in groupwork at the university, and later on my own, work rather well. That so many of the softwares on the list can be used to communicate and transfer information between parties is also intentional as without communication the chance of a successful project outcome diminish rapidly.

The last (bonus?) item on the list would be to recommend learning, at least superficially, a programming language which you could hack together small scripts with. Something which you could use to “glue” together the other parts. I adore Python, and many of the softwares listed above have python-bindings ready to use. Perl, Ruby and others, which elude me right now, would undoubtedly work equally well or better, but as with the text editor, pick a language you feel comfortable with, and rock on.

Having used Vim (mostly gVim) exclusively for the last year or so my muscle-memory has thoroughly set. Which I was reminded of yesterday when a classmate from Uni asked me if I could lighten his load a bit by quickly adding a piece of functionality to some code he was working on.

“Sure” I thought, I can do this. So I launched Eclipse to carry out a small scale controlled environment kind of test. The task was to, from an existing for-loop with its own functionality, add in the required statements to have the loop also build a comma-separated string of the values retrieved by the loop.

That little adventure made me discover of two things:

“:w” won’t save the file in Eclipse… it will however insert those very characters into the code, breaking it. The same goes for “V”, “d” and “Y”. Also, “,cc” won’t comment out a line… that readjustment from Vim to Eclipse took way more time than hacking the actual Java

Python has spoiled me

But all in all, it worked out pretty good, and I got to use StringBuilder for the first time ever. The resulting code looked something like this:

I’m sure there are better ways to accomplish this, like just tacking on a comma after each append and then on the resulting string working some string-manipulation magic to remove the final trailing comma, but for some inexplicable reason this just “felt” like a better solution.

It might just be that now most of the actual code is grouped together, so in the event of a refactoring, there is less of a risk that the string manipulation code is forgotten.

For me, that ended up pretty easy, I don’t know why, but for some reason, on my stationary computer, the default font was “Sans” and that actually works out pretty well on that screen. It looks neat. In any case, my ~/.gvimrc now contains the following line:

I spent most of the night finishing up some work I was doing to help a friend, and finally got some time over to recoup and start addressing things in my backlog (primarily writing a blog post about a recent late night coding excursion). That plan was immediately sidetracked by the fact that WordPress 2.7.1 was released (and, for some reason the WP Automatic Upgrade plugin failed to upgrade) so I had to manually upgrade the blag. I also realized that I suck at documentation which left me almost dumbfounded as to what modifications I have made. Which meant spending some time with a local copy of the 2.7.0 install and the new release, and getting intimate with diff. This time around it is documented.

It seems that one of my modifications (aimed at separating the pingbacks from regular comments) are now an integral part of WordPress (or, if this is not the case, I suck at reading code).

I was unsuccessful in finding a way to bring back another modification however; in the previous version I had managed to get comments written by the post-author to be treated with a different style, making it stand out from the other comments. This is no longer the case. Will have to investigate this further.

One really nice outcome of this little detour is that I now know how to jump between lines in gVim.