- a flotilla of handymen (all late)
- a Babel of coding standards
Interesting lesson of the day...Python. I know, being a hep systems programmer type, I really should know All Things Scripting language, but I've put off Python for a while. C and assembly are more my modus operandi. However, I've got a nifty, small little project and it seems a nice test subject for learning the language while I am stranded at home awaiting my flotilla of handymen.
Brief observations of the morning:
1. Any language where white space matters is ontically evil.
2. When one has directly-conflicting coding standards such as the Python recommendation and the Linux Kernel diktats, confusion ensues. Also side-diversions into mode-sensitive editor settings. Hence, a Babel of coding standards.
Now, I am sure that Emacs has some sort of artificially-intelligent agent inside it that automatically queries all currently-relevant authorities on coding standards and properly formats your code for you (once you issue the
<alt>-<meta>-\\-please-format-my-code-o-genii-of-coding-standards-<ctrl> command). However, current estimates from the National Bureau of Editing Standards indicate that you need 16 gigabytes of memory to run Emacs these days[1], and anyways, it's ontically evil.Today's word of the day is "ontically", in case you have not noticed.
Here's an interesting way to set your VIM settings depending on where you are in the directory structure (courtesy of the VIM wiki):
" Set directory-wise configuration.
" Search from the directory the file is located upwards to the root for
" a local configuration file called .lvimrc and sources it.
"
" The local configuration file is expected to have commands affecting
" only the current buffer.
function SetLocalOptions(fname)
let dirname = fnamemodify(a:fname, ":p:h")
while "/" != dirname
let lvimrc = dirname . "/.lvimrc"
if filereadable(lvimrc)
execute "source " . lvimrc
break
endif
let dirname = fnamemodify(dirname, ":p:h:h")
endwhile
endfunction
au BufNewFile,BufRead * call SetLocalOptions(bufname("%"))
That's neat, and would be handy for those cases where your personal C coding standard differs from the Linux standard, for example. However, what I really want is something that senses the language in which I'm writing and sets VIM up accordingly. And that's much easier.
Turns out that VIM has a filetype plugin that lets you bring in specific settings based on what type of file it is. Put
enable filetype plugin in your ~/.vimrc, and then create a file ~/.vim/ftplugin/python.vim containing, e.g., the following (recommendations from the inestimable VIM wiki, again):
" File ~/.vim/ftplugin/python.vim
" ($HOME/vimfiles/ftplugin/python.vim on Windows)
" Python specific settings.
setlocal tabstop=4
setlocal shiftwidth=4
setlocal expandtab
setlocal autoindent
setlocal smarttab
setlocal formatoptions=croql
Oh. One more thing? If you invoke Vim as "vi", as I do (creature of habit), it tends not to bring in the hip new Vim functionality. I fix this by aliasing "vi" to "vim" (e.g. for bash):
alias vi=vim
[1]Alas, my personal experiments show vim using 3/4 the memory of Emacs. It's catching up. Sigh.
2 comments:
The nice thing about "Standards" is that there are so many to choose from.
I'm with you on the whitespace thing. Why did they do that in Python? Just such a bad idea.
Post a Comment