vi keymap bindings in inputrc broken

[dylex]

I'm okay with the fact that vi mode is generally broken, but unfortunately having vi-mode mappings interferes with normal insert mode. I have the following in my ~/.inputrc:

set editing-mode vi
set keymap vi
u: undo

This works as expected with GNU readline (in bash, etc) but breaks 'u' in insert mode (rather than vi mode) with jline. Build tests fail as follows:

Failed tests:   testAbortingSearchRetainsCurrentBufferAndPrintsDetails(jline.console.HistorySearchTest): expected:<[ff]> but was:<[]>
  testAbortingAfterSearchingPreviousLinesGivesBlank(jline.console.HistorySearchTest): expected:<[]> but was:<[foo]>
  testMoveRight(jline.console.ViMoveModeTest): expected:<[c]h of words> but was:<[]h of words>
  testCtrlU(jline.console.ViMoveModeTest): expected:<donkey p[u]nch> but was:<donkey p[]nch>
  testCtrlW(jline.console.ViMoveModeTest): expected:<pasty b[u]limic !> but was:<pasty b[]limic !>
  testInsertComment(jline.console.ViMoveModeTest): expected:<#p[u]trified whales> but was:<#p[]trified whales>
  testC(jline.console.ViMoveModeTest): expected:<y[o]yo> but was:<y[]yo>
  testEndOfLine(jline.console.ViMoveModeTest): expected:<chicken s[u]shimi is tasty!> but was:<chicken s[]shimi is tasty!>
  testWordRight(jline.console.ViMoveModeTest): expected:<b[u]ttery frog    > but was:<b[]ttery frog    >
  testWordLeft(jline.console.ViMoveModeTest): expected:<l[uciou]s > but was:<l[cio]s >
  testEndWord(jline.console.ViMoveModeTest): expected:<p[u]tri> but was:<p[]tri>
  testRubout(jline.console.ViMoveModeTest): expected:<gross animal[ ]ff> but was:<gross animal[]ff>
  test_cc(jline.console.ViMoveModeTest): expected:<s[u]ck> but was:<s[]ck>

I don't need undo or vi mode to work in jline by any means, but if it cannot parse inputrc correctly, perhaps it should not try, or use a different config file. (I'd rather not break all my other programs just to be able to type in the play console, so any other workarounds would be great, too.)

[gnodet]

What is this inputrc supposed to do exactly ?
The ViMoveModeTest actually test vi mode and jline reads ~/.inputrc by default, so that looks like an expected result.
We could of course modify the test to isolate them and not take ~/.inputrc into account, but I'm not sure that's what you're actually looking for...

[dylex]

This inputrc (for readline anyway, which is what inputrc is for) maps "u" to "undo" in vi command mode only (not in vi insert mode), so that you can type "u" fine normally, but "u" does an undo (often a no-op). With jline it instead binds u to "undo" in vi insert mode, which makes in impossible to type "u". jline doesn't seem to understand what "set keymap vi" means (i.e., the following bindings don't apply in insert mode).

I haven't actually looked at this in a year or so, and worked around it by setting jline.inputrc in ~/.jline.rc, but it does still seem to be a problem.

[retronym]

I'm upgrading Scala to JLine 2.14.1. During testing, we noticed that when a user has set keymap vi-insert in .inputrc, JLine starts with the vi-command keymap. I find this somewhat unintuitive: when one runs bash -o vi, the shell starts in insert mode.

Was that an intended consequence of this change?