Function editing with Vim throws IndentError

[ptn]

Hi everybody,

I have a weird problem. Say I have a .py file with some functions in
it, like this:

# (...)
def foo():
print("bar")

When I open it and add a line to one of the functions,

# (...)
def foo():
troz = "bar"
print(troz)

I get the following traceback from the interpreter:

Traceback (most recent call last):
File "SOMEWHERE/example.py", line ??
troz = "bar"
^
IndentationError: unindent does not match any outer indentation
level

And so I'm forced to rewrite the function entirely just to add the new
line.

I thought that my problem was the w option from formatoptions, so I
changed my .vimrc file to this:

augroup filetype
autocmd BufNewFile,BufRead *.txt set filetype=human
augroup END
autocmd FileType human setlocal formatoptions+=ta2w
autocmd FileType lisp,scheme,python,c,java,vim setlocal
formatoptions-=ta2w

But the problem didn't go away. I don't think this has anything to
do
with the tabs and spaces, because I have them set up like this:

set tabstop=4 shiftwidth=4 expandtab

which is the standard way to handle them.

The scripts I load are: qbuf, TagList, indent/python.vim and a reduced
version of the standard python.vim

Could someone provide some pointers?

Thanks,

Pablo Torres N.

 

[Asun Friere]

Hi everybody,

I have a weird problem. Say I have a .py file with some functions in
it, like this:

# (...)
def foo():
print("bar")

When I open it and add a line to one of the functions,

# (...)
def foo():
troz = "bar"
print(troz)

I get the following traceback from the interpreter:

Traceback (most recent call last):
File "SOMEWHERE/example.py", line ??
troz = "bar"
^
IndentationError: unindent does not match any outer indentation
level

And so I'm forced to rewrite the function entirely just to add the new
line.

I thought that my problem was the w option from formatoptions, so I
changed my .vimrc file to this:

augroup filetype
autocmd BufNewFile,BufRead *.txt set filetype=human
augroup END
autocmd FileType human setlocal formatoptions+=ta2w
autocmd FileType lisp,scheme,python,c,java,vim setlocal
formatoptions-=ta2w

But the problem didn't go away.

It doesn't look like those formatoptions would be called when the
filetype is python. Or am I missing something?

I don't think this has anything to do
with the tabs and spaces, because I have them set up like this:

set tabstop=4 shiftwidth=4 expandtab

which is the standard way to handle them.

Did you actually search for tabs (/\t)? If the file was orginally
edited without expandtabs and later expandtabs was used this is
exactly the sort of problem you would encounter.

Also you don't need to set tabstop if you in- and de-dented using
[ctrl]-[t] and [ctrl]-[d] in insert mode, and '>>' and '<<' in command
mode.

 

[Thomas Troeger]

Hi everybody,

I have a weird problem. Say I have a .py file with some functions in
it, like this:
[...]

Could someone provide some pointers?

Thanks,

Pablo Torres N.

Have you enabled the `list' option to see which characters are acutally
on the lines of interest? Try out `:set list' and see the contents!
Otherwise helpful is `ga' to see the code values. Of course this will
not tell you why it is going wrong, but maybe it helps you to determine
what is going wrong

 

[Matimus]

Hi everybody,

I have a weird problem.  Say I have a .py file with some functions in
it, like this:

    # (...)
    def foo():
        print("bar")

When I open it and add a line to one of the functions,

    # (...)
    def foo():
        troz = "bar"
        print(troz)

I get the following traceback from the interpreter:

    Traceback (most recent call last):
      File "SOMEWHERE/example.py", line ??
        troz = "bar"
                          ^
    IndentationError: unindent does not match any outer indentation
level

And so I'm forced to rewrite the function entirely just to add the new
line.

I thought that my problem was the w option from formatoptions, so I
changed my .vimrc file to this:

    augroup filetype
      autocmd BufNewFile,BufRead *.txt set filetype=human
    augroup END
    autocmd FileType human setlocal formatoptions+=ta2w
    autocmd FileType lisp,scheme,python,c,java,vim setlocal
formatoptions-=ta2w

But the problem didn't go away.  I don't think this has anything to
do
with the tabs and spaces, because I have them set up like this:

    set tabstop=4 shiftwidth=4 expandtab

which is the standard way to handle them.

The scripts I load are: qbuf, TagList, indent/python.vim and a reduced
version of the standard python.vim

Could someone provide some pointers?

Thanks,

Pablo Torres N.

That isn't the standard. With that setup tabs will show up as 4
spaces, and still confuse you. You want this:

set shiftwidth=4
set tabstop=8
set softtabstop=4
set expandtab

tab characters in the file will show up as 8 characters long (which is
how the python interpreter sees them also) but pressing tab will
insert 4 spaces.

Matt

 

[Lawrence D'Oliveiro]

In message

That isn't the standard. With that setup tabs will show up as 4
spaces, and still confuse you.

Why should that be confusing? The most common tab-stop setting is 4 columns.

 

[Matimus]

In message


Why should that be confusing? The most common tab-stop setting is 4 columns.

I think if you continued reading my post you would see. The tabstop
feature in Vi(m) sets how many spaces a tab character is displayed as.
A tab character is specified as 8 spaces. The real problem is that the
python interpreter itself follows the spec and interprets a tab as 8
spaces. If you are viewing the code and have mixed tabs and spaces and
all of the tabs are showing up as 4 spaces you will not be able to
spot the issues that will come up.

4 columns is not the most common setting, the most common setting is
the default, which is 8. It is just very common for people to change
it. I suggest that instead of changing the tabstop, just use spaces
(not both) and use the `softtabstop` setting to allow a press of the
tab key to insert four spaces instead.

Matt

 

[Lawrence D'Oliveiro]

In message

A tab character is specified as 8 spaces.

Specified by whom? The most common setting these days is 4 columns.

 

[Thomas Troeger]

Specified by whom? The most common setting these days is 4 columns.

Where? I've randomly seen code snipplets that indent using spaces or,
worse, tabstop != 8, but most code I've come across uses tabstop width
8, which is how it was meant to be from the beginning of time.

Unfortunately, for many people it's hard to understand that a tabstop is
not the same as indenting with spaces, but I think this is leading too
far and will end in a dogmatic discussion like the `ViM vs. Emacs' war.

Anyways, if you claim tabstop 4 is most widely used I'd like to see some
kind of a reference for that since it contradicts not only my experience.

Finally, I'd like to throw in this one from the Linux kernel sources,
from `Documentation/CodingStyle:

------------------------------------------------------------------------

Chapter 1: Indentation

Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3.

[...]

Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.

In short, 8-char indents make things easier to read, and have the added
benefit of warning you when you're nesting your functions too deep.
Heed that warning.
------------------------------------------------------------------------

 

[Matimus]

In message



Specified by whom? The most common setting these days is 4 columns.

All argument about specification aside, Python interprets a tab
character as equivalent to 8 spaces. If you are treating tabs as
equivalent to 4 spaces in your python code it will cause
IndentationError exceptions to be raised.

If you set 'tabstop' to 4 in Vim all of the blocks of code indented
using 4 spaces will be aligned with code indented with tabs. That is
obviously problematic. Setting 'et' will fix the problem of inserting
tabs, but does nothing to adjust the way tabs are displayed.

Vim has a feature 'softtabspace'/'sts' which is used to modify the way
tabs are inserted without modifying the way they are displayed. If you
are writing python code using Vim and you intend to indent using 4
spaces (as recommended by pep8), the best practice I have found is to
`set sw=4 ts=8 sts=4 et`.

Matt

 

[Lawrence D'Oliveiro]

In message

All argument about specification aside, Python interprets a tab
character as equivalent to 8 spaces. If you are treating tabs as
equivalent to 4 spaces in your python code it will cause
IndentationError exceptions to be raised.

I have Emacs configured to show tabs as 4 columns wide, and I've never had
such an exception happen in my Python code as a result.

 

[Lawrence D'Oliveiro]

Finally, I'd like to throw in this one from the Linux kernel sources,
from `Documentation/CodingStyle:

------------------------------------------------------------------------

Chapter 1: Indentation

Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3.

[...]

Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.

Which is, of course, a load of nonsense.

 

[Ethan Furman]

All argument about specification aside, Python interprets a tab
character as equivalent to 8 spaces. If you are treating tabs as
equivalent to 4 spaces in your python code it will cause
IndentationError exceptions to be raised.

If you set 'tabstop' to 4 in Vim all of the blocks of code indented
using 4 spaces will be aligned with code indented with tabs. That is
obviously problematic. Setting 'et' will fix the problem of inserting
tabs, but does nothing to adjust the way tabs are displayed.

Vim has a feature 'softtabspace'/'sts' which is used to modify the way
tabs are inserted without modifying the way they are displayed. If you
are writing python code using Vim and you intend to indent using 4
spaces (as recommended by pep8), the best practice I have found is to
`set sw=4 ts=8 sts=4 et`.

Matt

When in doubt, try doing :retab as well -- it takes any tab characters
in the file and converts them to spaces. Very handy.

~Ethan~

 

[Ethan Furman]

In message
<[email protected]>, Matimus
wrote:




I have Emacs configured to show tabs as 4 columns wide, and I've never had
such an exception happen in my Python code as a result.

I have no Emacs experience -- does it actually put tabs in the file, or
spaces?

~Ethan~