Add a user configuration for the maxoff length #64
Conversation
Given that the maxoff seems to be a tradeoff between correctness and performance, allow the user to change it based off their needs.
|
@blueyed Can you merge this? |
|
I put it at 100, and I may increase it soon if this one really long dict I’m editing gets any longer...
~Theodore
… On Feb 22, 2017, at 12:40 PM, Daniel Hahler ***@***.***> wrote:
Given the feedback and the PR itself: should be also increase the default?
What would you use, @EdJoJob and @tbodt?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
So I think apart from this PR (which is good in general) we should also bump the default then.. maybe even 200 to be on the safe side? |
|
I was dealing with an absolutely huge list of dict of dicts at the time so I needed to set it to 500, but I do feel that that would be rather extreme as a default though |
|
Probably a better idea than setting a stopline when calling |
|
Actually, it looks like the timeout is not supported on some versions of vim... |
|
We could always assume to have a recent Vim by default, and then maybe fallback to something like 100-200 if the timeout is not supported? |
|
That is more "normal" in terms of wanting to use newer features, however we in all cases still need an override so that we can deal with 500-1000 line nested structures, uncommon, but absolutely necessary to deal with. If I really needed to I can fix indentation on small (~20 lines) things. I do not have the patience or desire to make sure that my behemoth structure is correct though |
|
oops, wrong button |
|
@EdJoJob And then the fallback could be 200 lines - but still awaiting more feedback on that though. |
|
@blueyed I'll have a look through this tonight |
|
Why not merge this as-is so people can start using the workaround right away? Perfect is the enemy of good. |
|
@mgedmin As for the PR itself: the name in the README does not match the code.. :/ diff --git c/README.rst i/README.rst
index 1c1ffc3..a354999 100644
--- c/README.rst
+++ i/README.rst
@@ -77,8 +77,9 @@ Existing indentation (including ``0``) in multiline strings will be kept, so thi
python_pep8_indent_max_back_search
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-If you have an error re-indenting a large list or dict set ``g:python_pep8_indent_max_back_search`` to a larger number.
-This defaults to ``50``
+If you have an error re-indenting a large list or dict set
+``g:python_pep8_indent_max_back_search`` to a larger number.
+This defaults to ``50``.
Notes
diff --git c/indent/python.vim i/indent/python.vim
index 4278498..0610f00 100644
--- c/indent/python.vim
+++ i/indent/python.vim
@@ -35,12 +35,8 @@ setlocal shiftwidth=4
if !exists('g:python_pep8_indent_multiline_string')
let g:python_pep8_indent_multiline_string = 0
endif
+let s:maxoff = get(g:, 'python_pep8_indent_max_back_search', 50)
-if !exists('g:python_pep_8_indent_max_back_search')
- let s:maxoff = 50
-else
- let s:maxoff = g:python_pep_8_indent_max_back_search
-endif
let s:block_rules = {
\ '^\s*elif\>': ['if', 'elif'],
\ '^\s*except\>': ['try', 'except'],I would also prefer to have a basic test for this then. As for the timeout feature, it could be done in a separate PR, but I think it is better to have it right away and avoid a config setting. |
The timeout is supported with Vim 7.3.429 at least. In case of issues (breaking older Vims), this could be wrapped to fallback to some (higher) max offset. Fixes #64.
|
Closing in favor of #90. |
This uses different offsets for the type of pairs: '()' and '[]' will
only look for just 20 lines above, while 1000 lines are used for '{}',
which might be a huge dict.
Ref: #64.
This uses different offsets for the type of pairs: '()' and '[]' will
only look for just 20 lines above, while 1000 lines are used for '{}',
which might be a huge dict.
Ref: #64.
|
Can you try #91, please? |
This uses different offsets for the type of pairs: '()' and '[]' will
only look for just 20 lines above, while 1000 lines are used for '{}',
which might be a huge dict.
Ref: #64.
|
Just for info: #91 is merged as an intermediate fix. |
Given that the maxoff seems to be a tradeoff between correctness and
performance, allow the user to change it based off their needs.
Closes #63