UPDATE Nov 7, 2009: Better parsing of traceback. UPDATE Nov 4, 2009: Now passing a “-b” flag to the script opens the parsed stack frame references in a BBEdit results browser, inspired by an AppleScript script by Marc Liyanage. When things go wrong in a Python script, the interpreter dumps a stack trace, which looks something like this: $ python y.py Calling f1 ... Traceback (most recent call last): File "y.
This is pretty slick: enter “fc” in the shell and your last command opens up for editing in your default editor (as given by “$EDITOR”). Works perfectly with vi. With vi, “:cq” aborts execution of the command.
If you have opened a file, and see a bunch “\^M” or “\^J” characters in it, chances are that for some reason Vim is confused as to the line-ending type. You can force it to interpret the file with a specific line-ending by using the “++ff” argument and asking Vim to re-read the file using the “:e” command: :e ++ff=unix :e ++ff=mac :e ++ff=dos This will not actually change any characters in the file, just the way the file is interpreted.
Just discovered “vidir“, a way to manipulate filenames inside your favorite text editor (better known as Vim). Previously, I would use complex and cumbersome BASH constructs using “for;do;done”, “sed”, “awk” etc., coupled with the operation itself: $ for f in *.txt; do mv $f $(echo $f | sed -e 's/foo\(\d\+\)_\(.*\)\.txt/bar_\1_blah_\2.txt/'); done Which almost always involved a “pre-flight” dummy run to make sure the reg-ex’s were correct: $ for f in *.
There are a number of solutions for executing Python code in your active buffer in Vim. All of these expect the buffer lines to be well-formatted Python code, with correct indentation. Many times, however, I am working on program or other documentation (in, for example reStructuredTex or Markdown format), and the code fragments that I want to execute have extra indentation or line leaders. For example, a reStructuredText buffer might look like:
I love Vim! It is so easy enough to edit a remote file with my local Vim through the Secure Copy protocol: $ vi scp://firstname.lastname@example.org/projects/foo/bar.py However, I often find myself wishing that bash completion was available to expand/complete paths on the remote system. Furthermore, when editing files outside of my home directory hierarchy, I have to remember to add an extra slash after the host name, e.g.: $ vi scp://email@example.com//var/www/html/index.htm A solution is to write a custom wrapper function that takes scp-style remote file paths, converts them into Vim-style remote file paths, and then invokes Vim on them.
Description provided include (among others): :Bsgrep[!] Search all buffers (or just current buffer if “!” given) for regular expression pattern, . :Bstoc[!] Construct a “table-of-contents” consisting of filetype-dependent “important” patterns (e.g. class and method/function definitions). provided include (among others): :Bsgrep[!] Search all buffers (or just current buffer if “!” given) for regular expression pattern, . :Bstoc[!] Construct a “table-of-contents” consisting of filetype-dependent “important” patterns (e.g. class and method/function definitions).
Every day I discover at least one new thing about Vim. Sometimes useful, sometimes not. Sometimes rather prosaic, sometimes sublime. This one falls in the useful but prosaic category: to get a count of the number of characters, lines, words etc. in the current selection, type “g CTRL-G”. This is a useful command, and good to know, but its invocation is a rather obscure key-mapping. In other words, just like most of the commands of your garden-variety “dumb” modeless editor, it can only be memorized (or looked up) and reproduced, instead of being generated based on grammatic-/syntactic- princples, like a language-based construct.
Vim continues to surprise me with its wonders. Sometimes (many times, in fact) things do not make sense, and I am perplexed as to the reasoning behind them. Then, one day, I grokked it. And from that day on, I can never imagine any other way of doing it. An example of this was my confusion over the apparent redundancy of two fundamental commands. In normal mode Vim, “s“ (mnemonic: “substitute”) and “c” (mnemonic: “change”) are both ways to remove some existing text and then go into insert mode.
The Great Controversy A standard dictum amongst experienced Vim users is not to use the arrow keys to move around your document. This dictum is often repeated again and again, in tones that range from the taken-for-granted to hysterical-zeal. The most common reason given for this is that using the arrow keys takes your hands away from the home row of your keyboard, and thus is wasteful both in terms of time and energy, whereas the standard Vim movement keys — h, j, k, and l — keep your hands on the home row, and therefore is far more efficient.