lunarwatcher / auto-pairs Goto Github PK

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.): 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

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

• Delete pair: There is no different when hitting <BS> compared to without plugin, The original jiangmiao plugin doesn't have this issue.
• New indented line: Hitting <CR> inside pair adds newline but it is not indented. The jiangmiao has this problem.

Steps to reproduce

• Delete pair: Type [+<BS> produces ], expected to delete pair completely
• Delete pair: Type [+<CR> + k produces

[
k
]

expected output:

[
     k
]

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

$$|{

}

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 (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): 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" },
})

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.

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

Single keybind to auto-skip past the first closing pair

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 (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: 
|

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.

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

1. Save above minimal vimrc as mini.vim
2. Install the plugins, then :CocInstall coc-tsserver
3. Save this snippet as src.js

function foo(req) {
    let {user} = req
    let {user} = b
}

4. nvim -u mini.vim src.js
5. Start a new line right below the first line
6. Type let {us<CR>
7. It sometimes becomes

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!)

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;

• Spell-check and verify the readability of both the documentation files
• Ensure technical accuracy in AutoPairs.txt, wrt. updates making certain parts obsolete
• Changing the style in AutoPairs.txt, if necessary to improve readability
• Making stuff easier to find in AutoPairs.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 (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.

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.

https://github.com/mg979/vim-visual-multi/blob/61855432df721f01e5b64fec07bf7a9077ff32b5/autoload/vm/comp.vim#L9-L13

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.

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

As 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
{
    |
}

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

1. Javascript filetype
2. Type: func(' -- corresponding autoclosing pairs are inserted: func('')
3. Continue typing: func('').func(' and only closing bracket is inserted (apostrophe is missing): func('').func(')

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

1. Install Telescope
2. Set up auto-pairs config with let g:AutoPairsFiletypeBlacklist = ['TelescopePrompt']
3. Open Neovim
4. Open Telescope (with :Telescope, for example)
5. Type ( in the prompt.

auto-pairs will insert ). I expect auto-pairs to be disabled with that setting.

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.

See:

jiangmiao/auto-pairs#338

ignoreevent might be applicable here

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

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 : 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

1. After typing closing tag }]) it's not jumping to the closing tag instead those literal character was added.
2. 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

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.

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.

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

Discussed in #40

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].

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.

#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

• 0. Testing (ongoing goal) [Potentially complex; shouldn't be hard]
• 1. Clean up and document
  • 1. more files (primarily for all the s: functions; they can be rescoped, and their current scope prevents backwards compatibility problems, and once again breaking people's config. One per major update is enough); [Easy] -- the easy bit is done - the rest is a part of modularizing the code, and comes later
  • 2. more comments - document the intricate parts of the code as much as possible to avoid wasting time on deciphering use. [Hard]
  • 3. Extend functionality for more complex rules [hard]
  • 4. Investigate extension of pair functionality by using 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 bugs
  • 5. Add functions for adding pairs instead of using the variable. This also lets us deprecate the init method (gonna do that quick and painfully with an echoerr deprecation notice, and complete removal when 3.0.0 is actually, properly released) [Medium]
• 2. Temporarily completely remove the feature triggering #21 (temporarily completes #21 and re-breaks #19) [Hard]
• 3. Modularity:
  • 1. Split up the code to make it more maintainable (i.e. avoid functions containing literally 177 lines of largely undocumented code doing who knows what to make the plugin work) [Complex]
  • 2. make the feature triggering #21 available through an explicit keybind of some sort. (<C-p>} for multiline } closure maybe?). This also re-fixes #19 without retriggering #21 [Easy when modularized]
• 4. Extend balancing rules by taking highlight groups into account
  • 1. Make an option for more fine-grained balancing control in comments (not sure how this is gonna work yet - finding comments is fine, no idea how we're doing balancing control though) [Easy when details are properly worked out]
  • 2. Make an option for extended ' ignore (current behavior: only abcd'; thought behavior: option that i.e. lets both abcd' and (1+2x)' not trigger expansion) [Easy]
  • 3. Make an option to ignore pairs in strings when outside strings, and vice versa [Complex]
  • 3a. Make an option that makes it possible to completely disable auto-pairs in strings, or just disable auto-balancing in strings. [Easy; requires other bits to be done first]
• 5. Bugs
  • 1. Bad balance check for {|} { (press } at |)

Backlog (AKA stuff added during digging that isn't as important, or required to be ordered):

• Figure out what b:autopairs_next_char_whitelist does, and document the hell outta it. See autopairs#AutoPairsInit for relevant initialization.

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.

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']

Actual Behaviour

• Press <M-e> on a matching pair such as (), [], ''
• No wrapping operation performed

Expected Behavior

• word should be wrapped up by the matching pair
• ()test_word
• cursor represented by |
• (|) press <alt-e> in insert mode
• (test_word)

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:

• Back insert - this would make the entire functionality resemble fly mode, except for fly mode including text when searching
• Outsourcing into an explicit function call (the option I went with; possibly not the best implementation): makes it periodically usable, doesn't obstruct general pair insertion. Essentially a weak opt-in flymode
• Nuke the entire feature (probable candidate if the general feedback is that it has no place in anyone's workflow)
• ... potentially something else?

These won't work:

• Add a modifier to the pair (keyboard layouts, terminal input processing, blah blah) for multiline
• File-wide balance checks to make multiline checks feasible - this option is not feasible due to the implementation. Language semantics and structures mean it's extremely complex to parse just any file and have it work. Doing this would be an entire project on its own

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.

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!

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

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.

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.

(|)"" 

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

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

<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)

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: 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

1. Install Telescope
2. Open Neovim in a directory with multiple files.
3. Open Telescope (with :Telescope, for example)
4. Press <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: 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

1. Install julia.vim and auto-pair
2. install coc.nvim with coc-snippets if you want to have snippets like above videos (optional)
3. type to see the result

Tell me if you can reproduce the bug. Thanks you.

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.

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)

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.