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

Setting an inputrc mapping for Ctrl-j kills the enter key #48

Closed
trptcolin opened this issue Jun 21, 2012 · 2 comments
Closed

Setting an inputrc mapping for Ctrl-j kills the enter key #48

trptcolin opened this issue Jun 21, 2012 · 2 comments

Comments

@trptcolin
Copy link
Member

Having a line like these in ~/.inputrc prevents line input:

Control-j: next-history
Control-k: previous-history

Control-j is the problem one.

From the small bit of research I did, I see that Control-j is really the same as the Enter key, but in the only shell where I could get that setting to be used (bash), Control-j and Enter were treated differently. So maybe there's a way we can distinguish them in jline as well?

@hickst
Copy link

hickst commented Jun 21, 2012

According to the readline documents, one can infer that Ctrl-j should NOT be the same as RETURN. For example:

"isearch-terminators - The string of characters that should terminate an incremental search without subsequently executing the character as a command. If this variable has not been given a value, the characters ESC and C-J will terminate an incremental search."

Note that C-J terminates incremental search WITHOUT executing the character as a command, whereas RETURN
is bound by default to the 'accept-line' function:

"accept-line (Newline or Return) - Accept the line regardless of where the cursor is."

@trptcolin
Copy link
Member Author

OK, maybe this is obvious to others, but new to me: Ctrl-j is ASCII code 10 (newline), and Ctrl-m is ASCII code 13 (carriage return). In jline, all of Control-j, Control-m, and Enter end up coming through as 10. I traced this as far back as the underlying InputStream reads (it's 10 whether it comes from System.in or from the default FileInputStream wrapping FileDescriptor.in).

I'm assuming this makes sense to others just out of OS-specificness, but readline still must have some way of distinguishing - directly capturing the keys or something? git://git.savannah.gnu.org/readline.git

You can use Ctrl-v Ctrl-m, or Ctrl-v Enter, to actually get the code 13 to come through, but I'm stumped as far as getting it with plain old Ctrl-m or Enter.

Any ideas? Either I'm missing something, or there's no way to distinguish Ctrl-m from Ctrl-j on my setup (OSX, zsh and/or bash), given that we're going through a stream. Hoping I'm just missing something.

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

2 participants