Closed RastaDill closed 2 years ago
@jiangmiao This issue is annoying indeed. I've tried his patch in my local and it's working as intended. Please merge this PR asap. Thanks :)
@ranelpadon #309 - jiangmiao isn't around to merge this.
I've documented this properly in my fork, but the short story is that it's a limitation of Vim's indent systems. At least the built-in ones. There's a plugin (don't have the link right now) that adds pep8 indentation - that should be enough to fix this. Alternatively, it's bundled into the polyglot plugin. Both options should work.
It's also a substantially more compatible option in terms of custom indentexprs, which is why I haven't merged this into my fork. I'm reasonably certain this change will break indentation for anyone with the pep8 plugin as well (or the polyglot plugin, which I think bundles the pep8 plugin), or just in general for anyone who has indent systems that doesn't indent the closing bracket this weirdly.
In my opinion, polyglot it's big combine and not everyone needs it. Install new plug for fix problem another plug - not the best approach. But thanks for show yours frok.
The pep8-indent also works (checked yesterday for good measure).
You're right it's not the best approach, but it's a portable one. It's compatible with all indentexprs and options, and doesn't break indent more than what the indentexpr breaks.
The patch here would actually break the plugin for anyone using polyglot, pep8-indent, or any other indentexpr that indents the brackets properly in the first place. It can also be perceived as breaking the plugin for people who actually don't want this type of align - that's part of why indentexprs have priority in the first place.
In that case, shouldn't it be added as an option? Like g:AutoPairsPythonPep8
and set it to 0
or 1
for those who want this behavior. By default it could be set to 0
so it won't break any changes
But why? We already have formatting engines that are made to deal with this exact thing in whatever format you want. Even if it's set to 0 not to break by default, why? It's reimplementing the wheel we've so graciously been given by devs who actually care enough about formatting to implement tools for it. Formatters work regardless of the original input, and gives whatever desired output any arbitrary programmer wants for some arbitrary project.
The list of cons here is bigger than the list of pros by an order of magnitude; the only two pros is that this is an easy implementation, and that it, localized, gets the right output; that it doesn't universally, assumes everyone follows pep8 to the letter, has vim configured in a way that lets it delete indent. It also assumes everyone is using the default formatter, that said default formatter doesn't ever change, and that it remains consistent between Vim implementations (read: Vim and Neovim).
It also assumes the config is set up identical to OP, and that it behaves identically across different versions of both Vim and Neovim. Every other case is an ignored edge-case with this pull request, and represents people who either have to use a formatter, or submit an equally unreliable PR to fix their particular edge-case. This would also not be portable to other languages, and assumes specific pairs.
As an exercise to the reader, install the fork here with Your Favorite Plugin Manager:tm:, and try using it on a multi-byte pair, or a pair that doesn't indent. A prime candidate for this is """|"""
. Here's a minimal vimrc for this exercise:
set nocompatible
filetype off
call plug#begin()
Plug 'RastaDill/auto-pairs'
call plug#end()
filetype on
filetype plugin indent on
filetype plugin on
syntax on
set autoindent
set smartindent
set cindent
let g:AutoPairsMapBS = 1
set backspace=eol,start,indent
On this rabbithole, this entire PR only works on pairs that indent. If there's any contexts where it doesn't, the entire plugin breaks. """|"""
is one example. Another example is accidental enter in this configuration:
x = "|"
Similar situation if you press enter in a double pair:
((|))
Also reproducible in triples, and in other types of pairs. How are you going to solve those? And all of these ones are just with the dummy config. It's reproducible everywhere else for anyone who uses a formatting plugin that adheres to pep8, because those prevent the situation from occurring in the first place.
More fun also happens if bs
doesn't have indent
at all. in fact, nothing happens, because it doesn't delete any spaces. You could of course argue "who wouldn't have indent set?", but I guarantee you that some people do, particularly people who are rigid on not using insert mode for any deletion.
If you actually evolve this PR to fix these issues, you're left with a relatively light-weight indentexpr
that probably still has edge-cases, doesn't indent while typing, still takes up space on your disk, that actively prohibits you from making any changes to certain config, and that could've been so much better if replaced with a formatter.
TL;DR: formatters good, this hard-coded approach bad. Use them, they exist for a reason. (tangentially related on computers and time: https://www.youtube.com/watch?v=-5wpm-gesOY)
This pull request opened very long time. Original author @jiangmiao not support this project. I guess can closed PR. If someone wants to use the package with my edits, it's easier to take my fork directly I personally switched on vim-python-pep8-indent You can also see my simple own config for Python (neovim has not been updated for a long time) In an extreme case, black or yapf will save you.
After press Retunr in pair have result: dict( ....| ) Issue #295