On Apr 6, 2007, at 9:31 AM, Steve King wrote:
On Thu, 5 Apr 2007, Charilaos Skiadas wrote:
I actually think what you want is to leave the tab key alone, and the same for the other keys, and to just write a trivial 3 line script to do the kind of change you need to the entire document whenever it's run. (I think someone already suggested something similar). Then, assuming you use some sort of svn type system, you should be able to have a pre/post-commit hook or whatnot that runs this script.
That's actually not such a good idea, at least not around here. I'm not the only one who works on this code, and it's considered somewhat anti-social to make formatting changes to parts of a module you're not actually changing. Even just changing whitespace messes with others when they do a 'diff' to see what changes were made. In an ideal world, the rest of the code would already be formatted appropriately so such a script wouldn't actually change anything other than lines I worked on. In an ideal world. :-)
I suppose you can then write a more interesting script, that first runs an svn diff on the file, and then finds the changed lines from there and only re-indents those, leaving the rest of the file untouched.
But my suggestion about the pre/post commit hook was really that this should be happening for anyone committing to the codebase, not just to your commits. If you have particular formatting requirements, then it seems to me that the right way about it is to not allow anything not following these instructions to be committed in the first place.
I can write such a script and assign a key to apply it to just a selection or block, though. I think that's what'll work best for me.
BTW, in 2.0 I really, *really* hope the API will expose a way for scripts to execute arbitrary editor commands. It makes weird scripting requests like this a lot easier.
-- Steve King, steve@narbat.com
Haris Skiadas Department of Mathematics and Computer Science Hanover College