tools, Uncategorized

VIM: Find in files

It’s not a surprise that there is a built-in way to find in files in VIM. You can use four commands: :grep, :lgrep, :vimgrep, :lvimgrep.


:grep will use the default “find” tool for your operating system (“grep” for linux family, “findstr” for Windows). :vimgrep will use built-in vim search (same as for “/” searching) which is slower than system search (but works if you have problems with grep/findstr/other). On the other hand vimgrep has the same syntax everywhere (:grep depends on external tool used). Search result is presented using Quickfix window (opened with :copen). :lgrep/:lvimgrep will do the same, but using location list (opened with :lopen). In practise the difference is that if you use Quickfix window (:copen) it will stick to the current editor. Location window will show in the same way, but if you select anything then the window will disappear and you will have to run :lopen again.

I guess you have to choose yourself which command you like most.  The syntax is as follows:

:grep searchpattern locationpattern


:grep MyMethod *.*

Will look for phrase “MyMethod” in all files in current workind directory (you can check currect directory using :pwd). By default it does not perform recursive search (it will not search in subdirectories). And here the fun part starts.

In order to search in subdirectories you would have to use **/*.* pattern. However this works for :vimgrep and :grep in linux, but does not work for Windows. In order to make it work on Windows you would need to use /S parameter (linux grep also accepts -R parameter which does the same thing). You can pass it like that:

:grep /S MyMethod *.*

This will work on Windows and will find all “MyMethod” phrases in all files in all subdirectories of current working directory. However you can still make it the default behaviour in VIM. But first you neeed to know one thing:

:set grepprg

This is a variable that controls the usage of external grep tool in VIM. Depending on your operating system you will have different results:

grepprg=findstr /n    # <--- on Windows
grepprg=grep -n $* /dev/null # <---- on Linux

So in order to use recursive search you have to modify grepprg and add a proper parameter:

grepprg=findstr /S /n                  # <--- on Windows
grepprg=grep -nR $* /dev/null          # <---- on Linux

The same way you can add more parameters or make more complex commands.

tools, Uncategorized

CMDer/ConEmu – starting new tab in current folder from command line

Quite frequently I found myself opening several console tabs in the same folder (for vim, for running unit tests, for git, for executing the application etc). Starting new tab and navigating to my project’s directory is not optimal so I created a short !cmd.bat snippet that I can run everywhere (added as global alias) and it will create a new tab for me in the same directory. Here’s the content:

cmd /k "%ConEmuDir%\..\init.bat" -new_console:C:"%CMDER_ROOT%\cmder.exe"

It’s taken from “ConEmu -> Settings -> Tasks” with slight modification (adding tab icon). Here’s explanation of switches used by the snippet:2017-03-26_23-52-18

/k - run initial script just after running console
-new_console - open process in a new tab
:C:"file location" - path to file containing tab icon

Alternative way is to use shortcut for creating new tab and then selecting current folder from drop-down menu (see below).


Unfortunately because of some bug it does not work in my current version of Cmder/ConEmu (build 161022). The other this is that it requires more clicking 🙂


Review/Planning no. 0


The following features have been developed so far:

  • The app reads the structure of given folder
  • It saves the structure to a file
  • It calculates hash of every file
  • Other: Environment configuration (VIM + dotnet core SDK 1.0.1)

Some of the features delivered here does not bring real value i.e. calculating file hash or saving data to a file. This highlights the lack of planning last time. Up till now the app is not useful and does not solve any real problem.


The goal of the next iteration is to create functionality to move media files from source folder to target, applying some simple file reorganisation.
Files are organised by file’s creation year and month. Files structure from source location should be preserved. In order to avoid conflicts/errors the target directory must be empty.
The operation must generate some kind of a journal so that the operation can be rolled back or resumed if needed.


  • Generate dry-run file in order to review the moving/organisation process.
    File moving cannot be done on-the-fly. This operation can take a while and it may mess up files structure, so it’s better first to review the file showing suggested list of “source location -> target location” entries.
  • Generate journal file based on source file structure.
    The application should always leave track of every change as it is about moving sensitive data (personal media files). In case of any issues it should be possible to resume the operation or roll it back.
  • Move files to proper folders updating journal.
    Moving physical files from one place to another, based on generated dry-run file.

Currently I do not set the date of next Review/Planning. I expect to have it at latest in 3 weeks but I want to check my velocity first.


DSP2017 – What’s your methodology?

Almost three weeks have passed since the start of DSP2017. I cannot say that I feel excited about what I did. Nothing really changed since the last year (which was unsuccessful). Maybe it’s time for a quick recap? Maybe the way I drive my project after-hours is less serious than then one I do at work? Why? Wiseman said: Pay yourself first.

Maybe the thing is that I miss some kind of a process, rules to proceed, methodology? Why not to take the best of what I do and practice at work?


Talking about me, from now on I want to introduce some scrum ceremonies into my project. I do want to have iterations. And what’s related I want to have a review session followed by planning for the next iteration. I want to make it public, so expect Review/Planning post every iteration (I guess it will be done bi-weekly but this may change).


I feel I need review session to motivate myself. And nothings is a better motivation than making the progress public. Praise if it’s good, sling mud at me if it’s bad. Let it be colorful with clear decision that I want to go on or not.


Planing is also crucial for such project. It makes me know what to do next, so I can focus on coding instead of looking for the next thing to do. The worst excuse for not planning is not having time for it. I was about wasting a lot of time for doing stuff which turned out to be low-priority. Not only once.

Expect the first post soon.

tools, Uncategorized

Vim for .NET – flickering omnicomplete problem

Since the beginning of my journey with vim I have experienced a problem with flickering screen. After a several tries with Google it turned out that it’s mostly about vim omnicomplete, and even more specifically Omnisharp-vim preview functionality.

In order to get rid of the flickering, you need to change the default omnisharp switch:
set completeopt=longest,menuone,preview
set completeopt=longest,menuone

The consequences are that you will not see the details of selected item in preview window, but actually I have never used it (since what’s shown in the menu is enough).


Why am I moving from Visual Studio to VIM?

As I mentioned in my previous post I want to use VIM instead of Visual Studio to work on my logcmd project. This would be a kind of an experiment, but I do have some fair reasons behind that decision. Why do I think VIM is a good alternative to Visual Studio?

It encourages automation

If you’ve ever worked in VIM, you know, that the most important & personal thing is _vimrc file. It’s not that all the keybindings and plugins are already there. You have to create them, customize, sometimes create scripts that boosts your development, and you do it all the time. The other things you need to run directly from console. And obviously you do not retype all the kilobytes of commands all the time. After the second try you want to automate it and have a script that works for you. Although it may sound prehistoric to some of you, it has a lot of long-term benefits. You don’t have to teach new people (or even your future “you”) how to validate JavaScript, do merging/branching, compile LESS, deploy to DEV server, upgrade release notes etc. This way you also get stronger in command line scripting.

It cures bad habits of debugging

All the people praise VS for astonishing debuggig features. It’s all true, but I think overused almost all the time. I know it allows to solve the most hardcore and unexpected behaviour that you could imagine, but on the other hand it’s like using excel for simple arithmetic. I experienced it on my own. Do you remeber one of the following:

  • running the application to check some business logic (writing unit test would take too much time (sic!))
  • fixing some hard issue after hours of debugging and forget how to debug again
  • wishing you could debug your application on PROD?

This all is because of relying on Visual Studio “debugger”. Other people not so tightly coupled with debugger invented better approach decades ago. It’s LOGGING. I’m always amazed how people solve their problems with RaspberryPi or Linux problems on discussion boards – it’s always clear after sending the logfile. Having a good habit of logging also works on “debugging” production.

It has better performace

It’s all about automation and the keyboard. Have you ever seen a hacking movie where they open “My computer -> My documents -> my hacking -> Visual Hacking studio -> create new project”? Or drag and drop viruses from “My downloads”. It’s because mouse is slower than keyboard (unless you participate in Quake 3 Arena world championship). Of course it’s slower if you started with mouse, but give it some time. You can self-check how much faster it is to use vim’s “ci(” instead of searching the starting parenthesis, selecting the text with mouse, finding the closing parenthesis and pressing BACKSPACE.
It’s also a better performance of the editor itself. Visual Studio is slow, but how can an application that takes a couple of GB on disk be fast all the time? On the contrary VIM is pretty leighweigh and blazing fast (unless you install everything you find on Github).

It’s more universal

VIM is everywhere, not only C, C++, C#, Java, JavaScript, Go, Haskel and friends. And VIM is there for years (VI released in 1976). It’s important if you hesitate about the future of Microsoft, or feel bored of .NET (or burnt).

It has the spark of extravagance

Have you seen Rob Ashton coding? Have you seen other people’s faces during that? But, that’s mixture of freak and performance.

It’s raw in a positive way

You think programming is not only about writing the code fast? It’s mainly about reading, right? Then even better, because VIM is raw. There are no codelens, different toolbars/toolboxes, variety of windows, resharper rainbow of tips and tricks. You can focus on code only.

Changing your environment is good

It opens up your mind, it’s like being polyglot programmer. In case of programming languages, if you knew C# only, you would solve each and every problem using classes. Same with environment/IDE. It’s obvious for us that using Visual Studio debugger we can set the next statement there and back. I believe other environments also has such obvious things that we are not aware of.

In the end I’d like to share some video of VIM coding in action.

tools, Uncategorized

Challenge accepted: starting ‘logcmd’ – a console logs browser

I know that I was not blogging for a while. The only cheap excuse that comes to my mind is having a second job of begin father of two evils angels. I tried hard several times but stuck without publishing. Because of that I realized that I really need some actuation. And then Maciej Aniserowicz came with his “Daj sie poznac 2016” initiative (or maybe I just got tired of the idea that I will stay inproductive, and keep wathing movies every evening till my children go to university).
I was fighting for a long with the same cheap excuse, but won, and joined 10 mins before the registration was to be closed.

The rule is to blog about some pet project, so here is mine: logcmd. It will be a simple tool to read application logs (from file, console and more) and then search, filter, browse. The idea was born out of the need some time ago, when I searched for some online log4net log browser, because I wanted to filter NHibernate queries from the logfile.
As the subject is not very demanding, I decided to add two cool features on top of that. First, it will be done without Visual Studio but in VIM + OmniSharp (soon I’ll try to explain why, who knows, maybe there will be some live-coding video). Second, the tool itself will also be done as a console application. Why? Because of many reasons:
* console seems to be much closer to developer than another Visual-Log-Studio,
* console application can be easily integrated with tmux/tmux-like plugins or used for automation
* console is more portable than desktop
* I fell in love with the way git interacts with the user in command-line
* I don’t like desktop programming. All the desktop applications that I did in the past just seemed ugly to me.

Did I think about other projects? Sure, but there were some ambitious ones, that would probably die unfinished. There was also JavaScript game “Battlecity” and some Commodore 64 project. Who knows, maybe I’ll get back to them in the interim.

When talking about pet projects, I always have one picture in the back of my mind: