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

Autoindent guess incorrect for files with more than 32 lines of non-indented code #588

Closed
esetnik opened this issue Oct 14, 2020 · 3 comments

Comments

@esetnik
Copy link

esetnik commented Oct 14, 2020

https://github.com/sheerun/vim-polyglot/blob/master/ftdetect/polyglot.vim#L2609

Does this bug happen when you install plugin without vim-polyglot?
No

Describe the bug:
vim-polyglot autoindent only checks the first 32 lines of the file when guessing. In php files with a large number of include statements, there is typically no indentation information available in the first 32 lines. This means that the autoindent plugin will fail to produce the correct results for php files based solely on the number of includes in the file. For example, a file with a small number of includes ends up with shiftwidth=4, while another file ends up with shiftwidth=2 even though they are in the same project. I think the guess should traverse the entire file until it finds the first line with a leading space, instead of terminating early after only 32 lines. The number of lines to traverse when guessing could be configurable, if performance is a concern, but it should be quite fast to find the first line containing line[0] == " ".

To Reproduce:
Create any two php files, one of which has at least 32 lines of non-indented top-level statements.

@sheerun
Copy link
Owner

sheerun commented Oct 14, 2020

Thanks for noticing. vim-polyglot now fallbacks to checking 1024 lines if checking 32 doesn't detect indentaton

@esetnik
Copy link
Author

esetnik commented Oct 14, 2020

Thanks for the fix. Wouldn't it be simpler and more efficient just to call getline(1,1024) from the start? That way it doesn't need to check the same initial 32 lines a second time.

@sheerun
Copy link
Owner

sheerun commented Oct 14, 2020

I think getline(1,1024) can be much slower and not needed in 95% of cases. Better check 1024+32 lines in 5% cases than 1024 lines in 100% of cases

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

No branches or pull requests

2 participants