Showing posts with label Text Editor. Show all posts
Showing posts with label Text Editor. Show all posts

Tuesday, April 23, 2013

Why VIM + Syntastic? My editor has had syntax checking for years!



After my initial post on using Vim and Syntastic, I thought it would be a good idea to expound on *why* I'm using Vim. After all, there are numerous highly developed, great IDEs that have the same functionality plus lots more. (That being said, there are plugins that make those IDEs act like Vim: several plugins for EclipseViEmu for Visual Studio)

First, Vim runs pretty much everywhere (vim for *nixgVim for WindowsMacVim). The interface and commands are *consistent* between all of these locations. That means that whatever computer I'm logged into, I don't need to think about how to do something in the particular IDE that I'm using. Muscle memory takes over and I can focus on the content. Muscle memory does take practice to form, but it's worth it in any case and especially if switching environments is a necessity of what you're working on.

Vim's powerful commands and macros help me to edit text considerably faster I can when I only have the standard cut, copy, paste, and highlight commands available from the keyboard. Take a look at the explanation of how Vim evolved it's command syntax and the examples here (pardon some of the language). I'd explain some of the reasons, but why repeat information?

Vim is fast. It starts up almost instantaneously, especially when compared to larger IDEs with more functionality. It's commands and macros run quickly. This is another way in which Vim does not get in the way of my train of thought but allows me to continue working. When I've started up Eclipse in the past, I can go get a cup of coffee in the time it takes to start up. If I have to start it up or use any other functionality that takes a significant amount of time my train of thought will come to a screeching halt and it'll take a while to get back in the zone. (Yes, there are ways to get around these things, but that's not the point here)

Vim is open source, free, and extensible. That means that if something goes wrong with it, I can take a look under the hood myself and fix it (or write a plugin to do something I want to do). It also means there are many other users who are doing the same thing. Chances are that, if you're running into a problem, somebody else has too and might have found a solution. Additionally, I take pride in the fact that I've been able to help with a plugin, simple though the help might have been. I'd encourage you to pay with your time by contributing to vim itself or a plugin.


Are there cases in which Vim should NOT be used or in which it is not helpful?

Projects where IDEs are already used and the project setup files are static. It doesn't make sense to waste time trying to setup Vim to work with a project when all of it's settings (dependencies, paths, etc) are already setup in an IDE. However, as mentioned above, there are plugins that can be used with the IDEs to allow keyboard shortcut muscle memory to still help your productivity. That being said some projects can be setup to use multiple types of builders. If that's the case, you might be able to set it up in a way that is conducive to using Vim.

Vim's commands and macros are powerful, but  they only help when I know exactly what I need to edit. It does NOT help me to determine what and how to edit the source code. Figuring out the what, why, and how is, of course, the hard part of software engineering.

While I can work on Vim itself or a plugin, it means that I'm paying for Vim with my time. Depending on what I'm working on at the time, this may or may not be worth it. There is certainly something to be said for paying for a product, being able to call somebody responsible for said product, and getting them to fix the problems you've got while you continue your work.

Debugging is an inevitable chore when working on a program. IDEs with integrated debuggers can make this job a lot easier. Here is a StackOverflow answer suggesting several plugins that can do the trick for C/C++ with Vim. However, not having tried them and being used to Visual Studio's debugger, I'm marking this under a negative (if you've got other suggestions for other languages, please let me know).


All in all, Vim has helped my productivity a lot. What are your thoughts?

Tuesday, April 9, 2013

Vim and Syntastic



Since the days of writing everything from a "Hello World" app to a ray tracer in college, I've used the vim editor. Of late, I've had several projects touching apps that run on our Linux machines and, having read about the great power and extensibility of vim, it seemed like a great time to dig in and make myself more productive with it. (Here is a good argument for easing yourself into vim instead of diving headfirst into the hard stuff.)

Over the years, I had already started collecting a small set of settings for vim. I thought it'd be a great idea to make that set of settings public so that they might be of use to someone else (or so somebody can clue me in to a better way to do things). So here they are.

Of course, wanting to be more productive, I started hunting around the web for ideas on how to use vim better. In the process, I stumbled across this entry by Ian Langworth about how he uses vim and the plugins that he uses. Given that we had just turned on static analysis on some of our code, Syntastic stood out to me as a great idea.

               ,
              / \,,_  .'|
           ,{{| /}}}}/_.'            _____________________________________________
          }}}}` '{{'  '.            /                                             \
        {{{{{    _   ;, \          /            Ladies and Gentlemen,              \
     ,}}}}}}    /o`\  ` ;)        |                                                |
    {{{{{{   /           (        |                 this is ...                    |
    }}}}}}   |            \       |                                                |
   {{{{{{{{   \            \      |                                                |
   }}}}}}}}}   '.__      _  |     |    _____             __             __  _      |
   {{{{{{{{       /`._  (_\ /     |   / ___/__  ______  / /_____ ______/ /_(_)____ |
    }}}}}}'      |    //___/   --=:   \__ \/ / / / __ \/ __/ __ `/ ___/ __/ / ___/ |
jgs `{{{{`       |     '--'       |  ___/ / /_/ / / / / /_/ /_/ (__  ) /_/ / /__   |
     }}}`                         | /____/\__, /_/ /_/\__/\__,_/____/\__/_/\___/   |
                                  |      /____/                                    |
                                  |                                               /
                                   \_____________________________________________/
Simply saving the file I'm working on calls the appropriate compiler and instructs it to run a syntax check on the file. From there it visually highlights the lines with errors and, when the cursor is moved to that line, it displays the error at that line. Incidentally, it can also load the errors into the location list by running `:Errors`.

Of course, it took a little tweaking to get exactly right, for several reasons:

  1. Using the compiler to compile a single C file doesn't make much sense if it's part of a larger project. You'll get a lot of errors that are non-sensical because the appropriate headers aren't loaded, among other things. Running make makes a lot more sense. I updated the make command called by make.vim (located in the c syntax checker folder) so that it would call the appropriate target with the syntax checking flag turned on.
  2. We're using a different compiler than is assumed by Syntastic, so I came up with an appropriate error format that would parse the errors correctly. The discussion of this is here.

Syntastic is now providing me with immediate feedback to changes I make which is critically important to being productive. The sooner I find out something is wrong, the sooner I can fix it. Now, on to getting more done.