Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect auto-indenting after decorator line? #41

Open
goodboy opened this issue Feb 14, 2017 · 4 comments
Open

Incorrect auto-indenting after decorator line? #41

goodboy opened this issue Feb 14, 2017 · 4 comments

Comments

@goodboy
Copy link
Contributor

goodboy commented Feb 14, 2017

Whenever I write out a decorator line and then hit enter braceless seems to increase the indent level:

@mydecorator<ENTER>
    def myfunc(...

This seems wrong; there should be not indent added - maybe I'm also wrong in guessing this is braceless's doing?
It seems to go away when I disable the plugin though...

@tweekmonster
Copy link
Owner

Yeah, this is due to a bit of goofiness in the way block matching works. Decorators are seen as part of the function, so it's correctly (questionable) indenting what it thinks is the function body. It should autocorrect the indent when you complete the function signature with ):, though.

@goodboy
Copy link
Contributor Author

goodboy commented Feb 15, 2017

@tweekmonster yeah I'm not sure I follow.

so it's correctly (questionable) indenting what it thinks is the function body.

@ syntax does not necessarily mean the next line will be a def line let alone a function body? In fact this same problem exists if you try to stack decorator lines:

@pytest.fixture<ENTER>
    |  # <- that's the cursor...
@classmethod
def my_func(cls):
    pass

A decorator is more like a function call no?

def decorator(**kwargs):
    def wrapper(*args):
        func(*args, **kwargs)
    return wrapper

decorator()<ENTER>

will take you to the next line as expected. It seems that only when a @ is present is the needless indentation done?

@decorator(doggy='dirty')<ENTER>
    def...

Decorators are seen as part of the function

Yeah that just seems confusing to me because why should they be seen that way?
Decorator syntax is language specific sugar - I don't think it should have anything to do with block detection? In fact I would argue that since braceless is attempting to be non-Python specific then this especially shouldn't happen.

You're right though the def line does fix it self once you right the terminating :
I still find it unexpected/un-intuitive.

@tweekmonster
Copy link
Owner

What I meant by it being questionably correct is that a decorator is part of the function's block (as far as braceless is concerned). If you type vaP, just the function is selected. If you add an additional aP, the selection will be extended to the decorator. Block selection is a bit detached from autoindent, however.

It is unintuitive. But, I don't have time to dig deep into it right now. If you want to delve into it, you'll want to look at s:indent_handler.block in autoload/braceless/python.vim or s:handle_blocks in autoload/braceless/indent.vim.

Something else I noticed is that if you press == on the incorrectly indented line, it will be corrected.

A little off topic: I'm hoping that this progresses into something that'll allow me to create a much simpler version of braceless: neovim/neovim#6052. But, it most likely won't find it's way upstream to Vim.

@goodboy
Copy link
Contributor Author

goodboy commented Feb 15, 2017

@tweekmonster cool sounds good. Not sure if I'll be able to dig any sooner then you but I appreciate at least getting this on the backlog 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants