Cannot write specific diacritic character (ý) after adding auto pairs

[Sacek073]

Hi, I just find out, that when i have auto-pairs in vim, I'm not able to write "ý". Other diacritic character works fine (tried only Czech). Is it possible to fix it? When i removed auto-pairs.vim from /.vim/plugin it started working again.

[LunarWatcher]

There's several keybinds that use meta characters:

https://github.com/jiangmiao/auto-pairs/blob/master/plugin/auto-pairs.vim#L66-L97

Those some times get remapped to other characters. :verbose imap ý to check which one is problematic, and you can use logic to figure out the exact keybind from there.

[Sacek073]

When I run :verbose imap ý i get "No mapping found"

[LunarWatcher]

Possibly a dumb question, but did you reenable auto-pairs before checking? If you did, try opening insert mode and <C-v><keybind here> (i.e. <C-v><M-e>) and see if any of them yield ý. :verbose imap ý should work though

[Sacek073]

Yes, i have reenabled it. I'm not sure if I got you correctly, bit when I'm in INSERT mode and do ý it types ý. And then if i do the command, it still writes No mapping found.

[Sacek073]

-> after <C-v>ý (key 7 above keyboard, in czech keyboard it is ý), before I was able to write "ý" without pressing <C-v> before.

[LunarWatcher]

What did you mean when you said you couldn't write it then? If it works in insert mode, I don't see what's broken. There's only two normal mode keybinds, and both those are also defined for insert mode. Your description feels extremely self-contradictive.

And so we're clear, when I mentioned enter keybind here, I meant an autopairs keybind. These types of issues normally happen because a meta keybind happens to yield the character in question. https://vi.stackexchange.com/q/20995/21251

[LunarWatcher]

... that being said, if your Vim config repo is indicative of anything, you're running an 8 year old version. Try updating (and/or using a maintained fork) and see if that helps. The version in this repo is still contained in a single file, so you can just copy-paste it over to update.

[Sacek073]

As I mentioned in comment with pictures, I can write it only after <C-v> which is not normal behaviour. If i remove auto pairs from vim it types "ý" when i press key 7 on keyboard see picture. Same as other keys. But when there is auto pairs, pressing this key won't insert nothing, unless you press <C-v>before it. It worked same as normal key, lets say key "a". You don't need to press <C-v> in insert mode before typing "a", you just press "a", so I would like to get same behaviour. For all other (czech) diacritics it works.

[LunarWatcher]

Can't repro on the latest version (Linux, switched to a Czech keyboard layout for testing). Please consider updating the script

[Sacek073]

I have latest verison of if from https://github.com/jiangmiao/auto-pairs, vim version is VIM - Vi IMproved 8.1 (2018 May 18, compiled Apr 15 2020 06:40:31). I have tried your fork and the same problem occurs.

And back to what you suggested me, I probably didn't get it right, if i run verbose imap <M-e> it produces this (picture). Don't know it is helpful.

[Sacek073]

I have find out that if i run imap <buffer> ý ý it works, but if I add it to .vimrc, it is probably overwritten by auto-pairs (as suggested from link you sent me). But I tried the change from the same link (https://vi.stackexchange.com/questions/20995/how-do-i-remap-%c3%a5-to-type-%c3%a5) for all functions in auto-pairs and it doesn't work.

But still running this: :verbose imap ý or :verbose map! ý produces "No mapping found".

[LunarWatcher]

Ah, I see. reproduced in terminal vim. Not sure why, might be input processing artifacts, but reasonably certain there's a bug here.

[LunarWatcher]

A forced meta keybind (https://github.com/jiangmiao/auto-pairs/blob/master/plugin/auto-pairs.vim#L537-L540) and terminal handling weirdness triggers AutoPairsMoveCharacter. Works as expected in gVim.

[Sacek073]

So is there any solution to this? I use terminal vim. Like I commented these lines and it works now, but maybe it is missing some functionality.

[LunarWatcher]

Added a variable (defaults to 0) to my fork that outright disables this feature. Removing the affected block works too, though. You can add manual mappings either way if you want the feature.

[eirnym]

@LunarWatcher could you create a PR for this workaround? I think if it will be enabled by default, but documentation will state about this character, it'll be fine to have this workaround and give ability for some users to type this letter

@Sacek073 could you accept it? I can type this char on Polish keyboard, but I have no use for it, so I see this as a good compromise for now before the problem will go away (could require intervention in Vim core)

Also how a user can rebind this function to another key? If both of this would be documented, no user will have a struggle between have ability to type this character and to use this function.

Ideas?

[LunarWatcher]

@eirnym I could, but it'd be pretty pointless. Jiangmiao has been gone for quite some time (see also the issue count and PR count, as well as #309 and #289). Even if I made a PR, it most likely wouldn't get merged ever as a consequence of the plugin OP being gone.

As for rebinding, there's a manual approach atm, relying on explicit keybinds: https://github.com/LunarWatcher/auto-pairs/blob/master/doc/AutoPairs.txt#L998-L1005 (note that the map is only compatible with my fork because of some massive early refactoring; inoremap <silent> <buffer> <Whatever keybind> <C-R>=AutoPairsMoveCharacter(')')<CR> should work for the original plugin). I've also realized the move feature is one of the less documented features of auto-pairs, at least without the README examples.

Due to how terminal input processing works, I don't feel comfortable aiming at an arbitrary C/M/S-mapping of pairs to the move feature. Meta is out of the question; ref. this issue for one. Someone who uses gVim or another GUI shouldn't run into the same problem, but this plugin isn't designed purely for gVim. Neovim also being a target means has("gui_running") isn't an option for testing compatibility, as neovim doesn't actually know if a gui is running at the time auto-pairs is sourced.

I can't get CTRL-( to work on my (Norwegian) keyboard, where ( isn't a dedicated key, and I have no idea how I'll type shift-( when ( is on shift-8 already - that's before accounting for terminal vim processing artifacts, that probably won't support shift-( because it sends the same terminal signal as ( (same reason S-CR doesn't work in terminal vim, but works fine in gvim).

I have a bit of a hack for multiline close that uses getchar() to just map one key, but even that is mildly suboptimal. There's simply not enough keys for "brute-force"-mapping quotes.

The point being, there's not really any easy ways to automatically map move keybinds without breaking something somewhere, based on either a keyboard layout and/or vim variant (graphical vs. terminal, as well as vim vs. nvim).

Creative ideas are welcome though - I'm relatively inexperienced with plugin development, so there's a semi-decent chance I'm missing something obvious as well.

[eirnym]

@jiangmiao Could you add a few active developers out there to continue the work in this repository? This will ease tension and this project won't be abandoned. The very common reason of OS project death is sole author just have no time for it and he don't want to add another as a maintainers

[LunarWatcher]

Jiangmiao dropped off the platform in 2019. Their website is also down and the DNS record seems to be scrubbed. One whois provider also listed the domain as being for sale. (Didn't verify it from there, might be some generic stuff)

Also found https://twitter.com/jiangmiao/status/965945194808885248 https://twitter.com/jiangmiao/status/982112848938647553 and https://twitter.com/jiangmiao/status/973045126783102979 (not in order), so I have to be pessimistic here - there's a chance there's something deeper IRL beyond just not having time and not wanting to add other maintainers.

Based on the amount of time and the relatively abrupt disappearance of jiangmiao, it's probably easier to just move on to a fork or other plugins for the time being. The odds they'll return after two years of complete silence is relatively low.

This is purely guesswork though; I have nothing concrete, and won't unless we suddenly get some . If jiangmiao suddenly returns, we can rather deal with the logistics of keeping the original project alive then, but if you'd rather wait for an answer before doing anything, you might be waiting for a long time for nothing to happen -- it's arguably better to move on at this point, in one way or another.

I still believe there's something deeper than just abandoning the project, though the exact scale is purely conjecture. I'll continue on my fork in the meanwhile anyway.

[eirnym]

it's really sad to read :'( With these news I'd say we should to move on. Could you create an org/repo and start merging those PRs?

[LunarWatcher]

The repo already exists, and I tanked as many of the issues and PRs as I could (see https://github.com/LunarWatcher/auto-pairs/issues/5) about 3 months ago. (I may have missed a few though -- page up and down of identical-looking rows makes it easy to lose track). I'm also staying on top of issues in this repo because this is the variant most people use and therefore direct their problems and PRs to - the few issues that have appeared (like this one) contained issues still present in the fork.

An unfortunate side-effect of an early, incompatible change also made PR merging of PRs submitted to this repo a bit of a pain. There's also several PRs that conflict with each other (as in implementing the same thing), and several of which conflict with another stale fork I merged in early on (https://github.com/Krasjet/auto.pairs), which meant I got the bulk of fork merging done early on. Much less work than the issues anyway ^^"

Also got a changelog for a more complete list of improvements, though some details are in the documentation (some older bits of the documentation lag behind though, because I don't know they exist): https://github.com/LunarWatcher/auto-pairs/blob/master/CHANGELOG.md

[eirnym]

It's awesome! I've switched already! Could you propagate your repo to awesome-vim?

[LunarWatcher]

I submitted it a while ago, but doesn't look like it's been included yet