Because I can't copy issues with little effort. Because the issue tr

Issue tracker about auto-pairs HOT 9 CLOSED

lunarwatcher commented on September 23, 2024

Issue tracker

from auto-pairs.

Comments (9)

chindraba-work commented on September 23, 2024 1

Reference to #205: Unix Philosophy seems quite proper here. I'd call it declined, closed, or done.

In concept (closing what's been opened) it looks the same. It isn't really the same thing though. AutoPairs matches "pairs" of characters, not arbitrary strings of unbounded length and complexity.

In addition to the Tim Pope reference in the Non-goals section of the README, I'd recommend a pointer to vim-closetag.

from auto-pairs.

LunarWatcher commented on September 23, 2024

Feature request:

Upstream ID Comment Status

#313 Gonna add a variable for this. This is actually not flymode; it appears to be just normal jumping. < isn't defined in the default flymode jump list.

Fixed: g:AutoPairsJumpBlacklist Done

#310 g:AutoPairsDirectoryBlacklist added Complete

#281 Done

205 Declined (alternatives exist, UNIX philosophy in application)

#308 Unclear Requires clarification - declined in the meanwhile. From what I understand, it just asks about expanding brackets, which should already work. If it doesn't, that's a bug (but one I can't repro)

#264 If this asks what #281 is, this feature has been implemented. Otherwise, I'm not actually sure what it asks, and it's closed for a lack of details Done or closed

283 Just, no. Likely to produce more false positives than good. Declined

#140 Keybinds are rejected; the plugin isn't a LaTeX utility. Adding ``:'' to b:Autopairs for tex filetypes will be investigated. Update: autocmd FileType tex let b:AutoPairs = autopairs#AutoPairsDefine({'``': "''"}). Valid since multibyte support was introduced. Support for per-filetype pairs have been added. Note, however, that at least vimtex has (recently?) defined a bunch of things starting with a backtick. Premature insertion of a second backtick as a result of not waiting for Vim to complete keybind matching will result in autopairs not being able to do its job. Complete

124 Unclear, involves flymode, and I don't like flymode, so Declined

#156, #276

replaced \s* with .* in

auto-pairs/plugin/auto-pairs.vim

Line 454 in 5e01ea9

if before =~ '\V'.open.'\v.*$' && afterline =~ '^\s*\V'.close

Complete

from auto-pairs.

LunarWatcher commented on September 23, 2024

Bugs:

Upstream ID	Comment	Status
#312	Probably a [wontfix] `<CR>` map issue. Can't do anything if other plugins map it after autopairs. Or, rather, it's not something autopairs can fix, but that other plugins have to fix. Autopairs should compensate for conflicts.	Other plugin's fault; handled in an completion-nvim issue
#296	Should be fixed now.	Complete
302, 270, 112	Fixed by Krasjet's changes when `g:AutoPairsCompleteOnSpace` is set to 1.	Done
#299	Missing jump character. Change since this: generalized to include all pairs defined in `g:AutoPairs` (well, specifically `b:AutoPairs`), so patched and then some	Complete
297	No repro in Vim 8.2; if this is a neovim issue, it'll be placed in the backlog (see 171's comment)	Declined
#198, #295	Vim determines how stuff is indented, and as a result, the exact behavior is slightly out of the plugin's control. To make a long story short, you'll have to tweak various cino settings to get where you want. #295 needs `set cino+=m1`	Vim's fault; see comment. ("complete"; documentation extension)
132, #190, #202, #206, #290	See the conflicts bit in the plugin documentation	By design; unavoidable
#277	Added `g:AutoPairsCarefulStringExpansion` (default: 0) as an initial option for handling this. It's far from optimal; see the documentation for an extended explanation, and a discussion	"Done"
#268	No repro; works as expected both in and out of insert mode. Remapping leader for a keybind that's used in insert mode as well, though, isn't the best idea. I.e. typing \a (i.e. related to TeX in any form) would, instead of typing \a, toggle auto-pairs.	Closed
263	No repro. Possibly fixed by Krasjet	Done
#251, #260, #280	Completed by implementing the patch in a comment on #251. #260 reported bugs both types of assignment not working: this is caused by incorrect documentation. The documentation was corrected due to a different issue earlier today. #260 itself starts off as a bug related to documentation, but escalates to unicode. Documentation fixes + implementing the patch from 251 should fix this.	Complete (thanks to jiangmiao/auto-pairs#251 (comment))
257	As per comment: add `"<<", ""`. Worked since arbitrary length multibyte pairs were added by jiangmiao. There's no way in hell, however, that this is going to be generalized for nested templates. If you legitimately need `<<>>` in any other context in C++, there's no way to do so without going full language parser, which isn't the purpose of this plugin. You have a lot of config options, but if you need it to be context-smart, that isn't something this or probably any other non-LSP plugin can do for you.	(Partially) covered by existing functionality
#211	Introduced `g:AutoPairsSingleQuoteMode` (default: 2, see help) as well as `g:AutoPairsSingleQuoteExpandFor` (for SingleQuoteMode = 1) for handling when it's okay to expand. The fill details are in the help documentation, but TL;DR: `fbr` strings now expand. The string types and single quote mode can be set with an `autocmd FileType` for whatever types you prefer, to better prevent annoying expansions.	Done
111, 208	Nuke the shit out of AutoPairsMapCh	Done
207	Not enough details	Declined (unless a neovim user picks up this issue and decides to investigate)
182	No repro; in part because that's not valid (anymore?). Noticed the documentation was horribly incorrect, however, so I've made a few changes to it to reflect the current situation.	Complete (ish, see comment)
180	Plugin conflicts; possibly fixed by #2. Not fixed by #2, but #2 still acts as a workaround. vimwiki specifically works fine locally, as the other keybinds are injected. Not entirely sure why this works the way it does, but it looks like auto-pairs expands previous maps to `<cr>` and prepends them. Consequentially, both work concurrently. OP also admitted to there being something else, so this may have been fixed prior to the creation of this fork.	Done; see comment
177	Flymode being dumb; see the wiki for the force insert keybind, or disable flymode	Declined
175	Ctrl-w is "delete word" by default. CTRL-h is mapped to the backspace action, and is therefore expected to delete both brackets.	Closed: User error
170	No repro; issue possibly caused by bad documentation. Documentation corrected in #3	Closed
169	User error	Closed
168	Probably along the lines of 190, 202, 206, 290: requires OP to confirm, but with the post made 3 years ago, they might never reply	Closed: missing details and solution verification
164	No repro; might be a flymode issue, but the issue lacks details.	Declined
#158	Should be possible with b:AutoPairs and an autocmd; going to require a vimrc change either way, rather than adding to the plugin	Complete: `'<<': '>>'` added to erlang files. (not sure what the `&ft` is, and I assumed erlang -- correct me if I'm wrong)
151	Investigating, but might be put in the backlog and require a neocomplete user to fix it. The issue already has a fix, though	Delayed; need a neocomplete user to fix it or help with the fix
139	See README	Planned
138	Seems to be handled by rust.vim	Complete (external factor)
131	~~Somewhat sus this is no longer a problem.~~ No repro. Works as expected.	Closed
104	This is what you get if you use flymode. Disable flymode or use the force insert keybind	Declined
#101	Fixed possibly by multibyte - it works now, anyway	Done
91, 98	`<CR>` has been fixed by #2; `<BS>` hasn't. Remap it yourself and set `g:AutoPairsMapBS = 0`	Declined
91	Plugin conflict. Remap	Closed
79	Might make flymode less trash	Open for discussion
76	No repro	Closed

(Note: investigating may refer to issues that aren't currently being worked on. Just means it's planned)

from auto-pairs.

LunarWatcher commented on September 23, 2024

Backlog:

Upstream ID	Comment
171	I don't use neovim, and I can't reliably test it. If anyone wants to fix this, PRs are welcome - I won't be doing it
192, 197,	Neovim weirdness; see 171's comment
199	No repro, might be neovim weirdness; see 171, 192, 167
181	Might be specific to mvim (mac vim?) -- need to look at a later time
154	Plugin conflict; would be best if someone experiencing it handled this
142	Cannot confirm -- need someone else to get on this
118	Possibly no repro or fixed since; check later

from auto-pairs.

LunarWatcher commented on September 23, 2024

Completed or otherwise handled, but never closed:

Upstream ID	Comment
196	`<M-p>` toggles autopairs, and therefore solves the issue. Equivalent to any other keybind
167	Vim generates tags for help automatically it seems, so this was fixed when help files were added.
137	Fixed by #147
130	Conflict with some view thingy; basically resolved
126	OP made a PR
122	Remapping options exist, as mentioned in the comment
82	seems to be completed now that there's a toggle. Might also have been introduced by Krasjet - I lose track :')

from auto-pairs.

LunarWatcher commented on September 23, 2024

Other weirdness to investigate: [Complete!]

from auto-pairs.

LunarWatcher commented on September 23, 2024

Complete!

Pull requests:

Upstream ID	Comment	status
#201	Conflict	Closed
#284	Conflict, substantial performance issues	Closed
#303		Merged: #3
#304, #249		Conflict with the same fix at fork creation
#274		Merged (#10)
#273	~~Somewhat sus this might negatively affect double quote use in vimscript~~ Made a minor change for echo, echoerr, Plug, and Plugin to insert double quotes. They're not valid as inline comments on these lines anyway.	Merged (#7)
#298		Merged (#9)
#153	Niche? There's also a way to remap `<cr>` if there's a conflict, which I'm guessing was the intent? Admittedly in a substantially less portable way.	Closed
#286	I don't really like this. Also, `f"` autocompletes fine, so there might be a deeper issue. Even then, this would be more suited for a language-specific addition than a global addition. Update: see the comment to 211 (bug comment, for those without search)	Closed
#150	Conflict resolution hell; see failed #6. Only an issue due to 4 years of changes while the PR was ignored. Reimplementing from scratch	Closed
#146	The lack of buffer variable use makes this obsolete.	Closed
#144		Merged: #2
#127	Too likely to cause false positives; use an `autocmd FileType` instead	Closed
#120		Conflict with Krasjet
#291	Initialization is on a per-buffer basis. Initializing that early does nothing in the long run. I understand there's an issue here, but this probably isn't the solution.	Closed, issue if the problem exists in a reproducible way appreciated.
#266	Might be useful.	Merged: #8
315	Actually done yesterday in response to a bug, though with a slightly different way. Basically the same thing though	Conflict

Obsolete PRs as a consequence of changes made to this fork that make these issues completely incompatible: 218, 145

Other issues:

ID	Comment
58	Source repo is gone, can't merge it. Also extremely confused wrt. context
56	Same situation as 58

from auto-pairs.

LunarWatcher commented on September 23, 2024

HTML also went a bit out the window when I discarded endwise rules (too complex, ends up being a bad drop-in "replacement" for snippets or other better suited plugins). Forgot updating it here though -- too much to keep track of :')

from auto-pairs.

LunarWatcher commented on September 23, 2024

Gonna close this for the time being. Reasonably certain I've gotten through what I can. The backlog is still a bit of a problem, but not much I can do about it atm. Can rather revisit those issues later if they're reopened

from auto-pairs.

Issue tracker about auto-pairs HOT 9 CLOSED

Comments (9)

Complete!

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent