Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cursor position bug in Aggregate Completer #208

Closed
tkruse opened this issue Aug 20, 2015 · 6 comments
Closed

cursor position bug in Aggregate Completer #208

tkruse opened this issue Aug 20, 2015 · 6 comments

Comments

@tkruse
Copy link
Contributor

tkruse commented Aug 20, 2015

Hi,
I notice a regression in JLine2.13 for AggregateCompleter, when the cursor is in the middle of an argument. It is a bit difficult to reproduce right now:

List<Completer> completors = new LinkedList<Completer>();
completors.add(
  new ArgumentCompleter(
    new StringsCompleter("foo11", "foo12", "foo13"),
    new StringsCompleter("foo21", "foo22", "foo23")));

Then, type these keys exactly, | indicates cursor position:

Type: f, o, o, 1, <left>
Result: foo|1
Type: <tab>
Result: foo11|1
Type: <right>, <backspace>, <backspace>, <left>
Result: foo|1
Type <tab>
Result: foo1o|o
# should be: foo11|1

At the end, the cursor cannot go back to delete the first 'f'.

In JLine 2.12.0 and 2.12.1, the behavior is different, with a harmless glitch (additional virtual '1' appears behind the last valid char of the buffer), but else consistent.

Using git bisect, I believe the regression appears with 3b0c474 : Support for infocmp capabilities.

@tkruse
Copy link
Contributor Author

tkruse commented Aug 20, 2015

I found this using Ubuntu Trusty and Java 1.7.0_80

@retronym
Copy link

retronym commented Sep 2, 2015

+1

We're seeing this in the Scala REPL with both JLine 2.12.1 and 2.13.

I've spent some time trying to diagnose the problem but didn't make any headway.

@gnodet
Copy link
Member

gnodet commented Sep 2, 2015

Fixed by 8beae1a

@gnodet gnodet closed this as completed Sep 2, 2015
@retronym
Copy link

retronym commented Sep 2, 2015

Wow, thanks! I've just tested with master and things look good.

Looking forward to 2.13.1. Any idea of likely timeframe for the next release?

@PascalSchumacher
Copy link

I agree, a jline2 release containing this fix would be very nice to have.

@PascalSchumacher
Copy link

Can provide a release with this fix, pretty please?

We would really like to update to JLine 2.13

retronym added a commit to retronym/scala that referenced this issue Apr 27, 2016
Now that we use a release of JLine that includes the fix for:

  jline/jline2#208

We no longer need to the workaround introduced in 7719a3c.

Screencast of the still-fixed behaviour:

  http://recordit.co/5pzh9OhlQv.gif
retronym added a commit to retronym/scala that referenced this issue Apr 27, 2016
Now that we use a release of JLine that includes the fix for:

  jline/jline2#208

We no longer need to the workaround introduced in 7719a3c.

Screencast of the still-fixed behaviour:

  http://recordit.co/5pzh9OhlQv.gif
retronym added a commit to retronym/scala that referenced this issue Apr 27, 2016
Now that we use a release of JLine that includes the fix for:

  jline/jline2#208

We no longer need to the workaround introduced in 7719a3c.

Screencast of the still-fixed behaviour:

  http://recordit.co/5pzh9OhlQv.gif
adriaanm pushed a commit to adriaanm/scala that referenced this issue Jan 10, 2017
Now that we use a release of JLine that includes the fix for:

  jline/jline2#208

We no longer need to the workaround introduced in 7719a3c.

Screencast of the still-fixed behaviour:

  http://recordit.co/5pzh9OhlQv.gif

(cherry picked from commit 6871bcc)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants