Giter Club home page Giter Club logo

auto-pairs's Introduction

Auto Pairs

Tests Minimum Vim version 8.1 patch 1114

Insert or delete brackets, parens, and quotes in pair: a maintained fork of jiangmiao/auto-pairs

Nvim warning

Note that this is not (yet) a statement saying nvim is unsupported. It continues having support - as long as it doesn't break built-in vimscript features. If this breaking continues, nvim will lose support when enough core features break.


This plugin is first and foremost a Vim plugin. Nvim support is only maintained by nvim being compatible with vim in the ways that matter - that being in the well-established vimscript functions powering the plugin.

At the time of writing of this warning, there are two major bugs introduced by nvim incompatibility with elementary and well-established Vimscript functions. One of these bugs were fixed and later regressed. The other was reported over a year ago at the time of writing,, which builds on a doc bug report written 1.5 years ago, and remains untouched in spite of being significant for plugin support.

The timeline on the regression is still unclear, but it isn't important. This is a symptom of nvim no longer maintaining compatibility with core vim features.

If you want to use this plugin with nvim, note that there can and will be bugs caused by Nvim introducing incompatibilities into well-established functions - both intentionally and accidentally. If these are breaking for your use, you can:

  1. Upgrade to Vim
  2. Switch to an nvim-specific plugin

Nvim is no longer a drop-in replacement for Vim, and hasn't been for quite some time. This forces a split in the Nvim and Vim plugin ecosystems as well. This is purely Nvim's fault - not for adding new features on top of Vim, but for breaking long-standing, built-in vimscript functions that have been around longer than nvim has existed.

Installation

NOTE: Auto-pairs currently requires at least vim 8.1 with patch 1114. See #37

There's several installation methods, and you're free to use whatever you want, but I personally cannot recommend vim-plug enough, in part because of the previous line of text. Installation, if you expect a more or less working variant, should be done with:

Plug 'LunarWatcher/auto-pairs'

You can also specify a tag, but this is no longer needed as of the release of 3.0.0.

To use experimental changes before they're deployed, use:

Plug 'LunarWatcher/auto-pairs', {'branch': 'develop'}

Note: As of 4.0.0, let g:AutoPairsCompatibleMaps = 0 is the default. Set the variable to 1 to use jiangmiao-compatible keybinds.

Note to migrating users

If you're migrating from jiangmiao's version, it's highly recommended that you read :h autopairs-migrating after installing. There have been a number of breaking changes made in this fork, as well as changes to default behavior. See the migration guide for important differences that are may affect your workflow.

Running tests (not required)

Auto-pairs comes with a few tests aimed at making sure nothing accidentally regresses without manually testing everything. Tests are in the test folder, and are in the vimspec format (using themis.vim); follow its instructions to run the tests.

Some plugins may interfere with the tests and cause erroneous failures, but the CI is generally indicative of the general state of auto-pairs. If it fails locally, that may be an indication of a plugin incompatibility (though these are often possible to fix)

Versioning system (meta)

This project roughly uses semantic versioning, with the minor exception that major version bumps may not be breaking in the sense that everything breaks, but introduces a set of features that significantly changes auto-pairs' functionality.

Breaking API changes that affect code compatibility will never happen outside major version bumps (looking aside bugs). Additionally, the master branch is the main development branch and may therefore periodically break. While I do as many tests as I can before I push, there may still be bugs introduced on the main branch. If you want a stable (ish) experience, stick to tags. If you want updates when they're released, stick to the master branch.

Differences from jiangmiao

At this point, there's far too many differences to list all of them. Aside removing some variables (such as remapping <C-h>), and tweaking defaults, many additional variables have been added. Including changes by Krasjet, here's a short list of some of the things this fork does that upstream doesn't:

  • Option for inserting pairs only if there's whitespace
  • Option for automatic linebreaks for some openers
  • Built-in support for language-specific pairs
  • Option for searching for closers after space (jiangmiao always did this, Krasjet never did this)
  • Option for entirely disabling jump
  • Option for a pre-init hook
  • Option for disabling in some directories
  • Options for single-quote handling around text
  • QOL improvements for matching
  • Balance checks with advanced modes (See :h g:AutoPairsStringHandlingMode)
  • ... Lots of bugfixes and general improvements
  • Better standards
  • Support and continued development :)

The entire list is too long to place in its entirety here -- the documentation should cover all the variables, so reading it should give you a complete idea of the changes.

Compatibility

Quite a lot of code compatibility was thrown out the window with a massive change that moved the plugin to be partially autoloaded. This mainly leads to improvements in terms of making it easier to customize (i.e. autopairs#AutoPairsDefine is available without an autocmd now). Additionally, it makes sure to reduce the chance of a conflict between functions.

Functionally, however, it's meant to resemble upstream as much as possible, partly to make migration less annoying for people with lots of customization.

Goals

  • Improving on jiangmiao's original code
  • Updating the plugin with long-requested features
  • ... and with new ones.
  • Increased customizability

Non-goals

  • Being a drop-in snippet replacement -- use UltiSnips or lexima.vim instead.
  • Supporting very old versions of Vim
  • HTML support: hardcoding HTML tags works, but writing a tag autoinserter requires substantial rewrites to the core engine. Instead, may I introduce you to Tim Pope? Or alternatively alvan?

Features

  • Obviously, the insertion and deletion of pairs (note that deletion is disabled by default. See :h g:AutoPairsMapBS)
  • An enter mapping for pair expansion
  • Quote handling aimed at avoiding accidental expansions
  • The ability to ignore pair insertion unless there's a whitespace (:h autopairs-howto-whitespace-only)
  • Extended balance checks
  • Fast pair wrapping
  • Several customisable features for various personal preferences

For more features, as well as documentation, see doc/AutoPairs.txt

Contributors

See Contributors

License

The code is licensed under the MIT license. See LICENSE.md for the full license text.

auto-pairs's People

Contributors

anihm136 avatar bombela avatar camthompson avatar d10n avatar davepagurek avatar docwhat avatar felixoid avatar firgen avatar frederick888 avatar grodzik avatar halftan avatar jiangmiao avatar kborkows avatar krasjet avatar lemeb avatar lunarwatcher avatar mmrwoods avatar myitcv avatar philliptvo avatar pxeger avatar rkiyanchuk avatar scottmcginness avatar shirohana avatar tomtomjhj avatar vbauerster avatar ytang avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

auto-pairs's Issues

Delete and new indent are not working

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
]

Optimize balance checks for pair objects

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

<M-e> (Alt-e) is not working as expected

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)

Potential incompatibility with vim views

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.

How is `g:AutoPairsShortcutMultilineClose` and the new multiline close system working out?

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.

Issue tracker

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.

g:AutoPairsMapCR conflicts against coc.nvim

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
}
  1. nvim -u mini.vim src.js
  2. Start a new line right below the first line
  3. Type let {us<CR>
  4. 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!)

Clarification on version numbers

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.

Incompatibility with vim-visual-multi

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.

Error is thrown while trying to use vertical split when I use auto-pairs in neovim v0.9.0

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

Following error is thrown when I enter the command :vnew:
Screenshot_20230515_072626

After this error comes along, telescope find files also stops working.

Steps to reproduce

Install autopairs and then set fillchars.

Testing for dupe tags

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.

Nested brackets detection is broken across newlines

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.

Fix the meta mappings

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

Add support for automatically disabling in certain syntax regions

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

Can't auto-disable in TelescopePrompt

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.

Not getting auto completed parenthesis just before a quote

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.

Close brackets are added even when the next character is alphanumeric

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.

Wild jump

Single keybind to auto-skip past the first closing pair

Add a prefix variable to all the places that use `<C-p>` as a prefix

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

Auto-pairs introduces a delay when pressing Ctrl-P in Telescope

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.

Regex issue with new tex multibyte pairs

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

Inserting the character 'å' (norwegian qwerty keyboard) will not work while running the plugin

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

Multibyte pair \( and \) causing errors.

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.

'Insert new indented line after Return' failed when used with vim-auto-popmenu

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.

The plugin can't deal with nested <> when editing Rust files.

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

Changing variables has no effect on functionality of the plugin

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

[Feature] support Enter follow """ with characters

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!

Second single quote in a line is missing a corresponding pair

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

Option to Move Openinig Brace to the Next Line in "Insert new indented line after Return"

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

Unexpected behavior with julia.vim

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:

162108660-5255620a-0519-4c9b-9db9-8d1eb75f5f47.mp4

With julia.vim:

162109320-a5c4c1a1-8df3-4410-988b-0933403bde15.mp4

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.

Breaking some non-English characters

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.

Documentation cleanup

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.

Strategy for improving balancing and pair scope

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

Unkown function ExpandMap

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)

Move character round 2

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

GetFirstUnicodeChar does not handle case where strgetchar() returns -1

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

Bad balance checks for double quotes (and possibly all open == close-pairs)

Discussed in #40

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

ShortcutJump doesn't work for added pairs

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

$$|{

}

Clean up object logic

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.

Auto pairs delete random text on <backspace>

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

Auto delete pair & auto jump

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

Providing an option to skip setting up key maps in a file type?

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.

How to delete pairs when there is a blank newline?

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

Confused about MultiLineClose

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.