Extra space being output after tab completion

[bdw429s]

After updating to JLine 2.14.1, I am getting an extra space output that never used to be there in JLine 2.12 when hitting tab and getting completion results. This is pretty problematic as the completion item might be a folder name and then I can't just keep typing the next folder or file name because there is a space I need to delete first. I haven't dug into the code to see what change has caused this but I did search the other issues quickly and didn't see this reported anywhere else.

[rkrell]

I can confirm this and this is weird for me, too.
For this reason I'm still using version 2.12.1, where the auto-completion works intuitively like in the Bash shell, for example, which means the cursor stops right after the last non-space character of the completion string.
This has been introduced in 2.13.

[bdw429s]

This looks like the offending commit. 2580b04 That change looks like it will always place a space after every completion so long as the cursor is at the end of the line which is not good at all if the string being completed is something like a path, which adds each token as the user hits tab. Throwing a space in there completely messed it up.

[drosenbauer]

Maybe make this optional, because for my purposes, this is actually kind of nice.

[bdw429s]

@gnodet Any update on this? It continues to be an issue for CommandBox CLI.

[bdw429s]

@gnodet Any feedback on this? The space isn't always desired since some tab completions are partial matches. Here is an example from CommandBox CLI. JLine is used to complete parameter names for CLI commands (we allow both positional and named parameters). So a user can type something like this:

> start cfengine=adobe

So if they type only start cfen and then hit tab, there is only one parameter that can match cfen which is cfengine so it is the only match. Jline now appends an additional space to the end of the buffer because it assumes that the user wants a space, but this is not the case. The user then needs to delete the unwelcome space in order to continue typing the adobe part of the name/value pair. Otherwise, they end up with this, which has an extra space after the =.

> start cfengine= adobe

Basically, just because there is only one match in the completor, it is not safe to assume that the use wants a space. It could simply be that the completor is giving a partial match and the user needs to finish typing the rest of the token. Previously before this regression, I would decide myself if a completion option needed to have a space after it.

[gnodet]

I suppose the behavior could be made configurable...

[bdw429s]

That would be nice, though I'd recommend doing it at the completor level. The built-in completers may expect one thing, but in this case I have a custom completer that comes with different expectations. If memory serves, I believe you allow more than one completer and they may have their own desired default.

[bdw429s]

Here's another quick of example of where this behavior is unsavory that I just happened to run across again. My custom completer handles file system completion too, but one directory deep at a time. Consider the following directories

/
/foo
/foo/bar

It used to be in previous versions of JLine, the user could hit

fo<tab>ba<tab>

and get

/foo/bar

But now there's an extra space after /foo will screw up the line and the second tab doesn't work. The user must manually delete the space because they have this instead.

/foo/ ba

Since foo is the only directory JLine assumes the user wants a space after the string, but that is not the case as it is just a partial match and user wants to keep typing.

[gnodet]

Yeah, fwiw, the problem is also fixed in 3.0 because the completers return a Candidate object which includes a boolean to tell if the completion is complete (and the reader should append a separator) or not.
What is doable for jline 2 is to make this behavior configurable so that both can be supported. I need to investigate the original issue where the behavior has been changed though...

[bdw429s]

FWIW, I just noticed today that it appears this was fixed a while back but as part of a different ticket:
Ticket: #90
Commit: a27f3bd

I noticed while looking at the code to try and put in a fix of my own until I made it to JLine3. For anyone reading this after the fact, this is how I got the old behavior back.

// Turn off option to add space to end of completion that messes up stuff like path completion.
reader.getCompletionHandler().setPrintSpaceAfterFullCompletion( false );

I'm closing this ticket since it turns out there is a fix for it.