Tabs versus Spaces in Source Code

Duncan Booth duncan.booth at invalid.invalid
Tue May 16 06:19:33 EDT 2006


Sybren Stuvel wrote:

>> An editor should be capable of letting you create or modify files
>> containing control characters without gratuitously corrupting them,
>> but the keys should perform the expected operations
> 
> I agree with that.
> 
>> not insert the characters.
> 
> But not with that, since it is contradicting. "Inserting the
> characters" could very well be the same as "performing the expected
> operations".

It could be, and for some keys (q, w, e, r, t, y, etc. spring to mind) that 
is quite a reasonable implementation. For others 'tab', 'backspace', 
'enter', 'delete', etc. it is less reasonable, but it is a quality of 
implementation issue. If I had an editor which entered a control character 
for each of these I would simply move to a better editor.

Some keys will of course do both (e.g. space bar in some editors does 
completion and inserts a space), but I prefer editors which keep things 
simple. The tab key is particularly prone to excessively complicated 
actions, for example the editor I use has the following (not simple at 
all, and in fact not even an accurate description of what it does) binding 
for the tab key:

> indent-previous command
>
> Indent based on the previous line. 
> 
> This command makes the current line start at the same column as the
> previous non-blank line.  Specifically, if you invoke this command
> with point in or adjacent to a line's indentation, indent-previous
> replaces that indentation with the indentation of the previous
> non-blank line.  If point's indentation exceeds that of the previous
> non-blank line, or if you invoke this command with point outside of
> the line's indentation, this command simply inserts a tab character. 
> 
> If a region is highlighted, Epsilon indents all lines in the region by
> one tab stop.  With a numeric prefix argument, Epsilon indents by that
> amount. 
> 
(and it is even more complex when you are editing something like Python 
where it takes continuation lines into account working out the 
indentation).

The problem is that behaviour like this is useful, and mostly even 
intuitive, but it's a long way from the definition of a tab or even 
the little metal clips you used to stick on the back of a manual 
typewriter.



More information about the Python-list mailing list