Consider refactoring default binding system

[alerque]

I've been waiting for the repository rebase (#5) to happen before opening this, but that time has come.

In the process of integrating various peoples' contributions, I noticed in @Konfekt's fork that he had significantly changed the default bindings, and even the way the insert mode mapping worked to be an abbreviation instead.

While I'm not sure his binding choices are the best ones to go with, they certainly open up an interesting point that I think needs review and discussion.

For reference my own current bindings are as follows:

imap ^^ <Plug>AddVimFootnote
nmap <Leader>^ <Plug>AddVimFootnote
imap @@ <Plug>ReturnFromFootnote
nmap <Leader>@ <Plug>ReturnFromFootnote

What's here that we should consider using? Or at least documenting things users may want to do differently (i.e. abbreviations vs. mappings)?

Also see #15 for related discussion.

[Konfekt]

Instead of an imap of multiple printable characters, such as imap @@ ... an abbreviation iabb @@ ... is less invasive as it does not clobber the first character, here @.

[alerque]

@Konfekt I've been playing around with different binding methods and am unable to verify the results you describe. Perhaps this is because I am using Neovim instead of classic Vim and a lot of the key binding and terminal interfaces have been cleaned up, but I can distinguish no difference in using imap vs. inoreabbrev in practice. Neither clobber the first character and there doesn't seem to be any noticeable speed difference either in activating the command or in typing the first of the characters followed by something else.

What version of Vim are you using and can you really tell the difference?

Additionally using inoreabbrev has the disadvantage of moving the cursor around and in some cases the footnote marker gets placed after where I wanted it.

[Konfekt]

I am using 8.1.892, but this is clobbering is a necessity: By a mapping @@, on hitting @, Vim needs to know if the next character is @ as well or not before printing @; therefore, there must be a delay before deciding between printing @ or invoking <Plug>ReturnFromFootnote to which @@ is mapped.

Edit: it seems that it is the cursor movement that is delayed, not the printing of @. The printing of @ is undone on hitting @ again.

[alerque]

It's looking more and more to me like the imap is advantageous. There is slowdown in how fast I can input anything, except in the case of actually wanting a literal ^^ or @@, in which case with an insert mode map I can just pause for a second while typing, and with abbreviations there doesn't seem to be any way to inhibit the action, you can only cleanup the mess afterwards.

Is there something I'm missing?

[Konfekt]

Yes, pausing does not inhibit an abbreviation; one must, for example, move the cursor or use after having it written out. That is why the string mapped to should be rarely typed; but neither @@ or [] are common strings in isolation (= not surrounded by keyword characters) in a markdown document.

The problem with any imap is that it is difficult for the user to grasp why the cursor movement after the first typed character, here @, of the mapping is delayed; whereas an abbreviation only intervenes when the abbreviation, here @@ is written, which is documented.

[Konfekt]

using inoreabbrev has the disadvantage of moving the cursor around and in some cases the footnote marker gets placed after where I wanted it.

I think this could be fixed by modifiying the abbreviation if you could give an example where this happens and describe what you expect instead.

[alerque]

@Konfekt It just dawned on me one of the major reasons the abbreviation solution feels wrong to me. I can't type the command to create a footnote where I would actually place the footnote. I must create a space around the abbreviation, and the footnote marker ends up being separated from the word I would normally be footnoting. This could, of course, be countered with a single character delete as part of the routine, but that would surely be more "surprising" than the delay in cursor movement with the imap solution. Not being able to place a footnote in the natural order of typing the content kind of defeats the purpose of having anything in insert mode in the first place. Otherwise I could just escape to normal and use the nmap binding.

I suggest the best thing to do is document the behavior oddity of imap in the readme and help docs, and clearly document how a user would create their own trigger using abbreviations if so prefer.

[Konfekt]

Well, in this case I'd suggest

• only binding the normal maps,
• proposing the imap as preferred solution,
• then the iabb as a fallback, and
• documenting the shortcomings of both insert mode bindings.

By any means, there is no obvious choice of the insert mode mapping that suits every user.

On another note, the <Plug>ReturnFromFootnote achieves little, so when I forked it I saw no necessity in binding it, at least in the normal mode. But again, a shortcut to close the footnote window in insert mode, like

inoremap @@ <c-o>ZZ

could be suggested.

[Konfekt]

Is this good to go now?

[alerque]

I have no idea, the status is definitely not still in any current brain registers.