lunarwatcher / auto-pairs Goto Github PK
View Code? Open in Web Editor NEWVim plugin, insert or delete brackets, parentheses, and quotes in pairs
License: MIT License
Vim plugin, insert or delete brackets, parentheses, and quotes in pairs
License: MIT License
Re: #59, that's not really something that should be discovered in the wild. A CI-based test to make sure there aren't duplicate tags in the help docs would be useful to keep that from happening again.
Another plugin that I use (registers.nvim) recently started using insert mode pop-ups, and I got hit by a compatibility issue between it and auto-pairs: tversteeg/registers.nvim#68 (comment)
I had a glance at the code and it seems a clean solution is to simply skip setting up auto-pairs key maps if file type is registers
.
I understand the long-term goal is skipping key maps while allowing auto-pairs to be re-enabled even if a buffer is in g:AutoPairsDirectoryBlacklist
or g:AutoPairsFiletypeBlacklist
, but in this case I really don't have the need to re-enable. So I wonder if it's ok to have some new options to achieve this for now? This seems quite straightforward and I'm happy to submit a PR. Thank you.
OS: Arch Linux
What vim? (+ version): nvim 0.9 nightly
Describe the bug
Since adding the new latex multibyte pairs recently, \( \)
and \[ \]
, there is an issue with, for example, typing \(
and then hitting backspace \
[edited to correct bug reproduction method], which will show the error:
Error detected while processing function autopairs#AutoPairsInsert[85] .. autopairs#Insert#checkClose:
line 34:
E54: Unmatched (
This error can be avoided by overriding the new multibyte pair handling with the below, which works as expected:
vim.g.AutoPairs = vim.fn["autopairs#AutoPairsDefine"]({
{ open = [[\\(]], close = "\\)", filetype = "tex" },
{ open = [[\\[]], close = "\\]", filetype = "tex" },
})
Move characters, when enabled, currently use C-<some character representing the pair>
, as defined by g:AutoPairsMoveCharacter(s? don't remember)
- gvim doesn't actually recognize that either.
The meta mappings appear to be universally detected, but the ctrl binds aren't recognized - at least not with my keyboard layout.
It's probably better to switch back to the meta bindings, or properly figuring out what do do about the feature - it's in a bit of a limbo atm. It's always an option to use <C-p>[pair]
.
This would essentially get rid of g:AutoPairsStringHandlingMode = 2
, and make it generic. This should add a variable that defines syntax regions to ignore. If someone decides to include string
and comment
, auto-pairs shouldn't auto-complete in string or comments. This would also solve parts of #23
A minor caveat here, though, is that it's still beneficial if jumping in strings in particular still works. I.e. "some text|"
, " at | results in "some text"|
, and not "some text"|"
. Of course, if no jump is available ("some |text", " at |), it should insert a single character (
"some "|text")
This may or may not require #41 to be doable; merging to develop
is preferred
OS: Arch Linux (rolling)
What vim? (+ version): Neovim 0.7.2
Reproduced in other variants of Vim? (Optional): Yes. VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jun 28 2022 16:22:51)
Autopairs config (if applicable):
set runtimepath^=~/.vim runtimepath+=~/.vim/after
let &packpath = &runtimepath
call plug#begin('~/.vim/plugged')
Plug 'neoclide/coc.nvim', { 'branch': 'release' }
Plug 'LunarWatcher/auto-pairs'
call plug#end()
set nocompatible
set updatetime=300
set cmdheight=2
" auto-pairs
let g:AutoPairsCenterLine = 0
" let g:AutoPairsMapCR = 0
inoremap <expr> <CR> coc#pum#visible() ? coc#_select_confirm() : "\<CR>"
Describe the bug
After inserting a new pair, if coc.nvim's popup menu is visible, <CR> inserts a line above current line instead of selecting highlighted item from coc.nvim popup.
Steps to reproduce
mini.vim
:CocInstall coc-tsserver
src.js
function foo(req) {
let {user} = req
let {user} = b
}
nvim -u mini.vim src.js
let {us<CR>
function foo(req) {
let {us}
let {user} = req
let {user} = b
}
sometimes
function foo(req) {
user
let {us}
let {user} = req
let {user} = b
}
neoclide/coc.nvim#3031 and neoclide/coc.nvim#2204 are probably the same issue.
(Btw thanks for maintaining this project!)
For now what support is:
input:
"""|""" (press <CR> at |)
output:
"""
|
"""
input:
"""py or words to make a sentence|""" (press <CR> at |)
output:
"""py or words to make a sentence
|"""
Could the second be:
input:
"""py or words to make a sentence|""" (press <CR> at |)
output:
"""py or words to make a sentence
|
"""
Thanks in advance!
Because I can't copy issues with little effort.
Because the issue tracker is a mess of duplicates, possibly handled issues, and issues unrelated to the plugin (such as people not understanding basic aspects of Vim), some issues are going to be filtered out of this list purely because I can.
OS : ArchLinux Kernel 5.10.11
What vim? (+ version) : Neovim 0.4.4
Reproduced in other variants of Vim?: No
Autopairs config (if applicable):
Plug 'LunarWatcher/auto-pairs', { 'tag' : '*' }
au FileType tex let b:AutoPairs = autopairs#AutoPairsDefine({'$' : '$'})
Describe the bug
The added pairs do not count when ShortcutJump is pressed.
Steps to reproduce
Example with provided configuration (I've tried with other pairs and the same behavior persists)
Before(Cursor at |
):
$|${
}
Result after <M-n>
$${
}|
What should happen
$$|{
}
OS (name + version; i.e. Linux Mint 20, Windows 10 2004, Macos Big Sur, etc.):
Archlinux
What vim? (+ version)
Vim 8.2.2380
Describe the bug
When you insert nested <> (e.g. Arc<Mutex<...>>), there's only one closing > instead of two.
Steps to reproduce
Edit any .rs file, enter insert mode and type "Arc<Mutex<", Vim inserts "Arc<Mutex<>" instead of "Arc<Mutex<>>".
OS (name + version; i.e. Linux Mint 20, Windows 10 2004, Macos Big Sur, etc.):
Arch Linux
What vim? (+ version) (i.e. vim, gvim, nvim, nvim-qt, mvim, ...):
NVIM 0.9.0
Reproduced in other variants of Vim? (Optional):
Autopairs config (if applicable):
I have just installed autopairs using packer, no other config
Describe the bug
I have set fillchars in my neovim config as follows:
Following error is thrown when I enter the command :vnew
:
After this error comes along, telescope find files also stops working.
Steps to reproduce
Install autopairs and then set fillchars.
OS (name + version; i.e. Linux Mint 20, Windows 10 2004, Macos Big Sur, etc.): Arch Linux
What vim? (+ version) Vim 8.2.2489
Autopairs config (if applicable):
let g:AutoPairsMultilineClose = 1
Describe the bug
Nested brackets detection is broken across newlines if you enable MultilineClose.
Steps to reproduce
|
is cursor position.
void f() {
if (true) {
} else |
}
Typing { under insert mode does not insert }.
Not sure if it's intentional, This does not appear in 51a6038.
I cannot find the exact commit that leads to this behavior.
void f() {
if (true) {
} else {|
}
If you type }
, the cursor jumps to the next }
without inserting anything.
git bisect
shows it was introduced in 64cf458 for those who enable MultilineClose.
Since 1ea8853 MultilineClose is enabled by default.
This bug also appears if you replace {}
with ()
.
This bug does not appear when all nesting pairs are in the same line.
OS Arch Linux
What vim? (+ version) Neovim 0.8 and 0.9.0-dev
Autopairs config (if applicable):
let g:AutoPairsCompatibleMaps = 0
let g:AutoPairsMapBS = 1 " This is required for some reason otherwise <BS> is not set; not sure why as it's apparently the default value and this and packer are the only plugins I'm loading
let g:AutoPairs = autopairs#AutoPairsDefine([
\ {'open': '\\left(', 'close': '\right)', 'filetype': 'tex'},
\ {'open': '\\(', 'close': '\)', 'filetype': 'tex'},
\ {'open': '\\[', 'close': '\]', 'filetype': 'tex'}])
Describe the bug
I'm using the above multibyte pairs for latex. \[
and \left(
work fine and are just here for comparison. \(
also works fine and creates the associated \)
pair, however if I then hit backspace I get the warning:
Error detected while processing function autopairs#AutoPairsDelete:
line 16:
E55: Unmatched \)
then
Error detected while processing function autopairs#AutoPairsDelete[41] .. autopairs#Strings#matchend:
line 1:
E55: Unmatched \)
However the deletion works (it just deletes one byte so I end up with \|\)
where |
is the cursor position). Deleting the other three bytes now also results in these same two errors being repeated three more times.
As another scenario, after creating the matched pairs \(|\)
if I hit <CR>
I get the error:
Error detected while processing function autopairs#Keybinds#IgnoreInsertEnter[3] .. autopairs#AutoPairsReturn:
line 18:
E55: Unmatched \)
and then the CR happens so I end up with:
\(
|\)
instead of
\(
|
\)
as happens with, e.g. ( and ).
Since this doesn't happen with the matched pairs \[|\]
or \left(|\right)
my assumption is it's some screwy regex related to #53. I've tested this on all three branches and an otherwise blank config (except for bootstrapping packer and loading auto-pairs with the above settings) and all have this issue.
OS (name + version; i.e. Linux Mint 20, Windows 10 2004, Macos Big Sur, etc.): OSX
What vim? (+ version) (i.e. vim, gvim, nvim, nvim-qt, mvim, ...): nvim
Reproduced in other variants of Vim? (Optional):
Autopairs config (if applicable): let g:AutoPairsMapBS=1
Describe the bug
I thought I was going crazy. Something was deleting more than it supposed to when pressing backspace
Upon investigating my recent change, I found out it was auto-pairs. This weird behavior gone after I disable auto-pairs.
You can see from the this asciinema. Each deletion is actually 1 keystroke of backspace
https://asciinema.org/a/ZkRJKhUrhXozSSwbxhPdgWqSB
Steps to reproduce
I think this have something todo with let g:AutoPairsMapBS=1
Jiangmiao's regex-based system is a mess, and certain parts of the logic just... aren't good, or are really flawed. Mixing regex with non-regex causes Fun Problems:tm: like #41, #52, and possibly more yet to be discovered bugs.
Replacing the rules with lexima-like rules should do the trick. The key takeaway from it is really that we separate regex from input and output, which should also simplify certain parts of the code. Admittedly, this is going to be completely breaking, so it'll have to be done for 4.0.0.
Hi, I found your plugin via an issue on the original plugin regarding this specific issue. After removing the old one and installing this one, I'm still having the same issue, eg:
Current functionality:
VariableN|ame
(insert open bracket) VariableN{|}ame
Desired result:
VariableN|ame
(insert open bracket) VariableN{|ame
I wanted to note that I found a plugin called Delimitmate that DOES have this functionality, however I don't like to use it because it doesn't automatically indent the next line after a bracket when pressing return.
Would basically allow a simulated open == close. That would give some drop-in replacements for the explicit '
checks, which is just a glorified open == close for a regex edge-case
#54 introduced a bug that breaks """
-> """|"""
-expansion. No idea how this isn't a part of the tests, but this needs to be fixed ASAP
Thanks for forking this and working on those issues! I tried this out but encountered some issues.
OS: NixOS
What vim? (+ version): nvim 0.4.4
Reproduced in other variants of Vim? (Optional): vim 8.2.1522
Describe the bug
When starting {n,}vim, I get the following error:
E117: Unknown function: ExpandMap
Steps to reproduce
Put the following in ~/.vimrc
:
Plug 'LunarWatcher/auto-pairs'
(with or without { 'tag': '*''}
argument)
:PlugInstall
.
Issue seems to be due to call ExpandMap(...)
, although ExpandMap
appears to have been defined as follows:
func! autopairs#ExpandMap(map)
Since you've added the meta templates for GitHub, and are now doing releases, How are you "numbering" them?
If not doing so already, perhaps using Semantic Versioning. Especially helpful as you are making breaking changes now.
Adding your choice to the README could help others who come along and try out the "new and improved" version.
OS : MacOS Catalina
What vim? (+ version) (i.e. vim, gvim, nvim, nvim-qt, mvim, ...): nvim HEAD
Reproduced in other variants of Vim? (Optional):
Autopairs config (if applicable):
Describe the bug
Hi, I'm new to your fork. Right away after installing I noticed some difference with jiangmiao default.
There's no configuration. Just default install with vim-plug
}])
it's not jumping to the closing tag instead those literal character was added.Backspace
after auto insert matching tag don't delete the matching tag eg left the with )}]
Is there any settings I have to set? This is on javascript file
Steps to reproduce
OS: Manjaro
What vim?: Neovim 0.5
Autopairs config:
let g:AutoPairsFiletypeBlacklist = ['TelescopePrompt']
Describe the bug
Adding 'TelescopePrompt' to the blacklist doesn't work. auto-pairs continues to close parentheses in Telescope.
Steps to reproduce
Telescope
let g:AutoPairsFiletypeBlacklist = ['TelescopePrompt']
:Telescope
, for example)(
in the prompt.auto-pairs will insert )
. I expect auto-pairs to be disabled with that setting.
Happy to do it and super confused right now about how to disable autopairs it says the command is which on a Mac Meta is mapped to the ESC key right so should be ESC-p, but this just bleeps at me
OS (name + version; i.e. Linux Mint 20, Windows 10 2004, Macos Big Sur, etc.):
Fedora 34
What vim? (+ version) (i.e. vim, gvim, nvim, nvim-qt, mvim, ...):
Vim 8.2 included patches 1-3391
Reproduced in other variants of Vim? (Optional):
Autopairs config (if applicable):
Describe the bug
Simply having the plugin installed and active with vim-plug results in the letter navigating in insert mode instead of being inserted.
Steps to reproduce
Change to a norwegian keyboard layout and hit the 'å' key, which you find just right of the letter 'P'.
OS MacOS Catalina (10.15.7):
What vim? (+ version) (i.e. vim, gvim, nvim, nvim-qt, mvim, ...): MacVim (8.2.2576 (170))
Reproduced in other variants of Vim? (Optional):
Describe the bug
Second single quote in a line is missing a corresponding pair
Steps to reproduce
func('
-- corresponding autoclosing pairs are inserted: func('')
func('').func('
and only closing bracket is inserted (apostrophe is missing): func('').func(')
See #192 -- I have no idea how to reproduce it (in fact, I can't repro with this fork or with the source repo), and much less how to fix it. Just messing with mkview
and loadview
isn't enough to trigger it, so I don't know when it's triggered either.
The fact that I can't reproduce it on either means that I have no idea whether it's fixed in this fork or not, as a happy side-effect of some other change.
It's not dependent on a specific version of Vim - someone in that issue reproduced it in a version compiled on 22.04.21, making it applicable to even new versions of Vim. It being reproduced in nvim as well as outside spf13/spf13-vim indicates that it's not just incompatibility with a vim distribution.
OS: Manjaro
What vim?: Neovim 0.5
Describe the bug
When you press <Ctrl-P>
in Telescope, Telescope moves up one row but only after a noticeable delay. The delay seems to be only present when auto-pairs is installed.
Steps to reproduce
Telescope
:Telescope
, for example)<C-P>
Telescope will move up one row but only after some time (~half a second). Without the auto-pairs plugin, <C-P>
is instantaneous.
OS Linux Garuda (arch clone), no version. Kernel Linux zen 5.18.3
What vim? (+ version) vim 8.2.5048
Reproduced in other variants of Vim? (Optional): have not
Autopairs config (if applicable): default
Describe the bug
My issue is with the "î" character (lower case only). Autopairs works fine for all other tricky characters I use (French), but this character just doesn't work. To add some strangeness: upper case works fine!
Steps to reproduce
uh… type "^", then "i". You should get the "î" character everywhere, but in vim with auto-pairs enabled, it fails, no letter is written. Also, if I deactivate the plugin and re-source my vimrc
file, I can write this character.
When I used auto-pair with skywind3000/vim-auto-popmenu, the 'Insert new indented line after Return' features of auto-pair were no longer available. I hope to see results:
input:
function{|} (press <CR> at |)
output:
function{
|
}
but I got this:
input:
function{|} (press <CR> at |)
output:
function{
|}
I use vim-plug to manage my plugin, If put the auto-pair in front of vim-auto-popmenu, like this:
Plug 'LunarWatcher/auto-pairs'
Plug 'skywind3000/vim-auto-popmenu'
let g:apc_enable_ft = {'*':1}
This feature will always be unavailable, but when reverse the order:
Plug 'skywind3000/vim-auto-popmenu'
let g:apc_enable_ft = {'*':1}
Plug 'LunarWatcher/auto-pairs'
This feature works fine when open vim, but if reload buffer with :e
, or switch branch with git co
, the feature fails again.
OS: Windows 10 2004
**What vim?: NVIM v0.4.4
Reproduced in other variants of Vim?: VIM - Vi IMproved 8.2
Autopairs config:
Although not applicable by I have the following config:
let g:AutoPairsDirectoryBlacklist = [$HOME . '\.config\vim']
<M-e>
on a matching pair such as ()
, []
, ''
()test_word
(|)
press <alt-e>
in insert modeAs stated in the feature pressing inside brackets places the second brace and the cursor conveniently:
input:
function{|} (press <CR> at |)
output:
function{
|
}
Some of us prefer the first brace to be separated from the function/function paramerters. Would it be possible to add a feature so that there is an option to obtain such behabiour:
input:
function{|} (press <CR> at |)
output:
function
{
|
}
Some concerns were raised regarding g:AutoPairsShortcutMultilineClose
and potentially the now separate multiline closure system.
For anyone out of the loop on the general subject, multiline close was moved out and into a separate keybind because it's substantially easier and less prone to false positives. In a way, it's fly mode light mode, but without the ability to revert. Internally, it joins empty lines into a space, and considers the first close character on the first non-empty line as a part of the "match". As outlined in #21, this creates balancing problems.
Just to cover all bases here, the options are:
These won't work:
So for the feedback bit:
For those of you using (or trying to use it), is it working out so far? And in general (open question to anyone who feels like it), any comments on the implementation? I'm not expecting a full code review of course, I largely mean in terms of usage (or potentially lack thereof).
What about the keybind? Alternatives are welcome as long as it doesn't conflict with terminal input processing and/or keyboard layouts.
Entirely alternate implementation ideas are also welcome - everything can be changed if needed, so if the feature isn't working out for most people in its current form, it can be changed.
<C-p>
has turned out to be a fairly problematic prefix, with several plugins (and a Vim built-in) using just <C-p>
.
However, I cannot keep switching the keybinds whenever there's a conflict. Instead, the prefix should be replaced with an easily configurable variable, to let people make their own decisions on what prefix makes sense (and let them make them with whatever limits their plugins place on free keys).
(In case someone else wants to pick this up before I get to it; contributions to this particular issue are on the develop-4.0.0 branch, not on the master branch)
(|)""
New line ""
Results in
(""
New line "|)"
Instead of
(""|)
New line ""
happens due to the double search. Only run a double search if there's a space between open and close
The docs have grown pretty fast, and gotten a bit messy; double-checking everything for accuracy, as well as shortening and re-writing for style, grammar, and clarity is needed.
It's primarily AutoPairs.txt in the doc
directory that needs to be updated; it contains a lot of old text that I haven't focused on when doing other stuff. The things that need to be done are;
AutoPairs.txt
, wrt. updates making certain parts obsoleteAutoPairs.txt
, if necessary to improve readabilityAutoPairs.txt
Also note that this is a lot for a single PR, so anything fixing or working on parts of this are fine; there's a lot of text to go through, and a lot of stuff to improve, so partial pull pull requests are obviously fine.
OS: Windows 11 22H2
**What vim?: gvim, vim 9.0 patch 1-1071
Autopairs config (if applicable):
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
" Plugin: AutoPairs "
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
vim9script
g:rust_kep_autopairs_default = 1
g:AutoPairsMapBS = 1
g:AutoPairsShortcutFastWrap = "<C-f>"
Describe the bug
When install julia.vim, editting the code for the first time returns <SNR>122_AutoPairsOldCRWrapper73<SNR>122_AutoPairsReturn
. If open other event for example like NerdTree or other file, then comeback to old file, now you can edit the file normally by magic. I opened the issue in julia.vim for 6 month but there is no new response about this behavior. I suppose there is a bug with one of 2 plugins.
Without julia.vim:
With julia.vim:
Steps to reproduce
Tell me if you can reproduce the bug. Thanks you.
Single keybind to auto-skip past the first closing pair
The only explanation I have for this problem is that i'm running SpaceVim and that this somehow conflicts with the functionality of Autopairs, but that would be weird since this is the only plugin I haven't been able to configure.
I was looking to add custom pairs to autopairs, and adding let g:AutoPairs = AutoPairsDefine(...)
in my config with the original autopairs plugin wasn't having any effect. That's when I found this fork and I am noticing the same issues.
Setting g:AutoPairsMapBS=1
wouldn't change the backspace keybind, although echoing it's value showed that it is indeed set to 1 and changing the keybind myself as shown in the documentation worked perfectly. The same thing is happening with setting my own custom g:AutoPairs
. I even tried setting it to only be g:AutoPairs = {'<':'>'}
, and while echoing it showed that it has been set properly, all of the standard pairs were active and < was never paired with >.
I also noticed that changing the default pairings in the original autopairs.vim directly worked while setting the variables later didn't. I apologize if my setup is causing this (or if the syntax I wrote here isn't too exact, but I did make sure everything was written correctly) but it would still be interesting to figure out what exactly is causing this. Changing variables for other plugins has always worked fine (e.g with UltiSnips), which is why I am even more confused as to what is happening.
Adding '\{': {'close': '\}', 'mapclose': 0}
to Variables.vim directly in the InitVariables function works perfectly, but I'm not comfortable with this since this wouldn't be a direct part of my config but rather a direct modification of the plugin
https://old.reddit.com/r/neovim/comments/ldakrk/completion_with_auto_pairs/
indentexpr is mentioned; the rust plugin has misbehaved in the past. An investigation is still in order
They're dumb and need to die in a fire kthxinadvance.
Seriously though, there has to be some untapped ctrl keybind for the various parts that can be used. Can't really touch <leader>
either, which largely leaves ctrl.
The second problem here is backwards compatibility; there's a few people who use this fork, and I doubt suddenly changing it is gonna sit well. Might be a good idea to add a transitional switch variable or something. iDunno, and this isn't a job for 1:08 me, but rather future me
substitute
on-demand -- not viable: balancing checks would have to be multiline to prevent spamming out new close characters for sufficiently complex patterns, there would have to be separate regexes for jumping, and just a whole lot of extra data opening for a lot more bugsechoerr
deprecation notice, and complete removal when 3.0.0 is actually, properly released) [Medium]<C-p>}
for multiline } closure maybe?). This also re-fixes #19 without retriggering #21 [Easy when modularized]{|} {
(press } at |)Backlog (AKA stuff added during digging that isn't as important, or required to be ordered):
Notes:
1 (in general): Doing 4 before 2 and 3 due to the implications; the object rewamp forces a redesign in the core system, while at the same time being able to yeet out piles of trash like this
1.3: Part of this rewrite bit is making objects an option; aside just {"open": "close"}
, something like {"open": "close", "map": "n", "delete": 1}
- basically, more fine-grained control over internals. map
and delete
can be auto-resolved (and delete can only be allowed if close != ""
). Supporting objects cannot break current pairs. Replacing bits to also support substitute()
for extending functionality and the definition of allowed pairs would also make auto-pairs more powerful, though I'm not entirely sure if it's worth it.
2: Started out seeming easy, not so much. It's heavily connected with complex jump logic (AKA a black box at this point), as well as a key jiangmiao obsoleted several years ago: g:AutoPairsWildClose. Appears to be "jump out of the last pair", was moved to some bullshit mapping that would be resolved with a fucking object rather than appending some garbage to the end of the string. Substantial cleanup is required before this can be done
5.1: At least one option should be to override quote checking for single letters. Maybe make the option a map?
5.2: Should be fairly easy to extend the current options, though it might have to be made available in certain modes only.
5.3: checking highlight groups shouldn't cause too big performance problems; there's other plugins doing substantially more synchronously. Might be worth profiling to check whether it's viable or not though. Should be fine as long as it doesn't start competing with plasticboy/vim-markdown in time consumed.
There's also no due date on this, but it'll be done relatively soon. To put it like this, it'll be done before 2022, but I can't promise it'll be done in a month, because I have no idea how long it'll take to implement all the changes. My weekly workload fluctuates a lot. It's currently semi-high at the time of writing. Bugs also take priority, so if anything breaks (or has been broken all the way from the upstream repo), that will be prioritized over adding more places for there to be bugs.
Thanks for forking this and working on those issues! I tried this out but encountered some issues.
OS: NixOS
What vim? (+ version): nvim 0.4.4
Reproduced in other variants of Vim? (Optional): N/A
(I actually tried this on vim 8.2.1522 and could not reproduce there, interestingly.)
Describe the bug
When starting nvim, I get the following error:
Error detected while processing function autopairs#AutoPairsTryInit[70]..autopairs#AutoPairsInit[33]..<SN
R>154_GetFirstUnicodeChar:
line 1:
E5070: Character number must not be less than zero
Steps to reproduce
Install and start.
Suggested fix
Something like this appears to have fixed the issue, but I haven't gotten around to testing this on any actual unicode characters... once I get around to that I'm happy to make a PR, if you're accepting any (:
diff --git i/autoload/autopairs.vim w/autoload/autopairs.vim
index c528092..9b077d5 100644
--- i/autoload/autopairs.vim
+++ w/autoload/autopairs.vim
@@ -98,11 +98,21 @@ endf
" Idea by https://github.com/fenuks: https://github.com/jiangmiao/auto-pairs/issues/251#issuecomment-573901691
fun! s:GetFirstUnicodeChar(string)
- return nr2char(strgetchar(a:string, 0))
+ let l:nr = strgetchar(a:string, 0)
+ if l:nr == -1
+ return ""
+ else
+ return nr2char(l:nr)
+ endif
endfun
fun! s:GetLastUnicodeChar(string)
- return nr2char(strgetchar(a:string, strchars(a:string) - 1))
+ let l:nr = strgetchar(a:string, strchars(a:string) - 1)
+ if l:nr == -1
+ return ""
+ else
+ return nr2char(l:nr)
+ endif
endfun
Hi there. I recently changed g:AutoPairsCompleteOnlyOnSpace
to 1 so that I wouldn't have auto-pairs before alphanumeric characters. This worked however since then I do not get auto-pairs just before quotation marks. For example:
"Hello world! ("
'Shake your groove thang! {'
would not introduce a closing parenthesis.
OS (name + version; ): win10 wsl2
What vim? (+ version) : vim 8.2.2539
Reproduced in other variants of Vim? (Optional):
Autopairs config (if applicable):
Describe the bug
Steps to reproduce
before:
{
|
}
Now I want to delete pairs, use backspace three times
after:
|
}
except:
|
I used your plugin for 6 months but after update I can't delete in pairs anymore. I changed to jiangmiao/auto-pairs
and it's ok. I think perhaps your recent PR break this feature.
With your auto-pairs version:
https://user-images.githubusercontent.com/75968004/170621491-a9d2a6da-1114-4aa9-aac9-8ef23c2e9a2d.mp4
With jiangmiao/auto-pairs:
OS: MacOS 13
What vim? (+ version) nvim v0.9.0-dev-2417
Reproduced in other variants of Vim? (Optional): Reproduced on nvim 0.8
Autopairs config (if applicable): happens with an empty config as well as with vim.g.AutoPairsMultiLineClose = 1
Describe the bug
Not sure if this is a bug or expected behavior, I think I'm mostly confused about how MultiLineClose is supposed to work -- my use-case may not be a close, per se? I've reproduced this in Fennel as well as TreeSitter query files, so it may just be a lisp-y thing.
Given this expression, where |
is the cursor:
(
|)
If I insert (
, I get this:
(
()
which is now unbalanced. The same is true if there's whitespace between the cursor and the closing )
. Is there a way to configure auto-pairs to correctly generate a full pair instead of treating the final )
as already unbalanced? BackInsert
doesn't insert the correct )
either, fwiw.
The breaking move to the autopairs#
prefix has broken vim-visual-multi. Not entirely sure what the best approach is.
The easiest option is probably to add backwards compat and introduce a forwarding function to work with this incompatibility.
And of course, because GitHub refuses to embed:
\'AutoPairs': { \ 'test': { -> exists('b:autopairs_enabled') && b:autopairs_enabled }, \ 'enable': 'unlet b:autopairs_loaded | call AutoPairsTryInit() | let b:autopairs_enabled = 1', \ 'disable': 'let b:autopairs_enabled = 0', \},
AutoPairsTryInit
is now invalid, and therefore causes the entire cleanup function to fail. vim-visual-multi's settings therefore introduces a bunch of unwanted variables that (I don't want tw = 78
for anything that isn't vim help docs).
Submitting a PR to vim-visual-multi isn't an option in the near future. Gonna be hard to defend compat for a little used fork anyway.
Originally posted by pooriar September 21, 2021
Sorry if this is a dumb question, but I've been struggling with this constantly. Here's the situation:
The cursor is in front of a pair, separated by a space:
| "foo"
I want to press "
to open a new pair of quotes like so:
"|" "foo"
But instead, if I press "
I get this:
"|foo"
Is there a way to disable this behavior? Thank you for maintaining this great plugin
OS (name + version; i.e. Linux Mint 20, Windows 10 2004, Macos Big Sur, etc.): Arch Linux
What vim? (+ version) (i.e. vim, gvim, nvim, nvim-qt, mvim, ...): nvim 0.4.4
Reproduced in other variants of Vim? (Optional): vim 8.2.2653
Autopairs config (if applicable): Clean config, just
call plug#begin('~/.config/nvim/plugged')
Plug 'LunarWatcher/auto-pairs'
call plug#end()
Describe the bug
<BS>
compared to without plugin, The original jiangmiao plugin doesn't have this issue.<CR>
inside pair adds newline but it is not indented. The jiangmiao has this problem.Steps to reproduce
[
+<BS>
produces ]
, expected to delete pair completely[
+<CR>
+ k
produces[
k
]
expected output:
[
k
]
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.