PEP8 and 4 spaces
rosuav at gmail.com
Tue Jul 8 13:37:40 CEST 2014
On Tue, Jul 8, 2014 at 9:13 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>> Not quite; tools like diff that put a character at the beginning of
>> the line are likely to be tab-aware,
> No, just tried it again: diff outputs tabs as tabs.
> $ diff abc def
> < abc
> < abc
> > def
> > def
> where line 1 begins with a tab and line 2 begins with 8 spaces in each
Check out its -t and -T options; diff is definitely tab-aware.
>> and gcc is certainly going to comprehend them
> $ gcc -c test.c
> test.c:1:2: error: expected identifier or ‘(’ at end of input
> where test.c contains
> IOW, gcc reports that the open parenthesis is in column 2.
It's easier to number the positions that way, in the same way that you
would number lines - by how many times you have to hit down or right
arrow to get there. In my MUD client, I measure text positions in
characters (within a line; a particular position is identified by
(line, char), because lines are generally far more important than
overall positions), even when tabs are involved; a tab simply counts
as one character, even though it displays as up to eight times the
width. Actually, I'm currently contemplating a reworking of how that's
all mapped out, which would mean that *any* character is allowed to
take up *any* width, including zero, in which case the only
significance is that a tab takes up a variable width depending on
where it is in the line (which is already coped with).
>> And I think less takes notice of them, too,
Shrink your terminal down to some weird width like 45, create a file
with long lines including tabs, 'less' the file, and use the right
arrow key to scroll horizontally. It takes note of tabs and renders
>> so it's only the very simplest tools like cat that actually ignore
>> them or treat them as single characters (or even bytes).
> They all seem to be "simple." At least Python is:
> $ python3 -c 'print ('
> File "<string>", line 1
> print (
> SyntaxError: unexpected EOF while parsing
> where the caret is pointing at the wrong visual column.
If someone cares enough to write a patch, I'm sure the traceback
renderer could be improved. But how many people actually use tabs
inside code like that?
More information about the Python-list