I'm struggling with the basics of getting a simple console application to work with JLine3.
I've initialized it like this:
terminal = TerminalBuilder.builder()
.streams(System.in, System.out)
.build();
lineReader = LineReaderBuilder.builder().terminal(terminal).build();
and I try to read a line like this:
String in = lineReader.readLine("/>").trim();
and if the user just types text correctly, I get the right input. Backspace works for correcting the input. But moving the cursor back using the left arrow key doesn't; instead of the cursor moving, I see ^[0D displayed on the screen.
I tried various other options but nothing changed. I want to move on in due course to exploit history and auto-completion, but I'm failing at the first baby steps.
I've obviously missed something basic (but the documentation isn't good...)
Using JLine 3.13.3 on MacOS 10.13.6
If you want to create a terminal for the real console the JVM is running in, you'd rather use:
terminal = TerminalBuilder
.builder()
.system(true)
.build();
That should work better...
Related
Xcode's auto-completion is often getting in my way by giving me argument placeholders when I already have them. Here's an example:
I want to change that second MoveToPoint to AddLineToPoint, so I delete part of the name, and hit control + space for the Show Completions command. I get something like:
You see the annoyance. I tab complete the name, but now I have to delete the 3 arguments, the commas, and the parentheses. This kind of thing annoys me and throws off my flow when writing code.
Ideally I'd like a way to delete these placeholders with one command, or have a separate auto-complete command, so along with Show Completions (control + space), I could bind something like Show Completions without Placeholders. Does anyone know how to do that?
XCode does support this actually. They call it "Select Previous Completion". Check it out here (under Code Sense).
You essentially just hit ⌃> (hold control and press >) for XCode to choose your previous completion. It think it only works well though if the new method you're calling takes the same number of arguments as the previous one.
Hope this helps
I've been trying to write a Java console program that can act upon arrow keys.
I came across JLine library that claims to be able to do this.
I've tried a few times to use the JLine library to accomplish my goal, but have been unsuccessful in doing so.
ConsoleReader reader = new ConsoleReader(System.in, new PrintWriter(System.out));
Despite using ConsoleReader.readVirtualKey(), it still waits for enter key press.
I have also tried using
UnixTerminal terminal = (UnixTerminal) Terminal.setupTerminal();
terminal.readVirtualKey(System.in);
But this doesn't work either. It always waits for Enter key and does not show the arrow keys that I pressed before pressing the Enter key.
Could someone help me with this?
A bit late perhaps, but I'm experimenting myself with jline.
This works for me:
ConsoleReader cr = new ConsoleReader();
String line = cr.readLine("type something: ")
It will probably not work if you run the program in an IDE though, e.g. it doesn't work in IntelliJ for me.
When using Mac OS X including iTerm, I can simply press
Shift+$ and the line in bash that I am currently tiping will get a # added to the beginning and the line returns. I like this very much as it prevents from actually executing that command while still editing it and I don't have to jump to the beginning of the line to insert that # character there.
However, when I log onto our cluster, this functionality is lost. I tried to search for this feature but only found posts about using sed etc. so suggestions which are not for the interactive kind of using bash that I am referring to.
Could somebody please point me to a resource where this functionality is explained (bash-guide?) so I could look up how to make it work when logging in to other machines? Or is this something Mac/iTerm-specific? But then, I would expect it to work also on our cluster, as long as I use my machine of course.
This might work for you
See insert-comment (M-#)
I love the code completion in Xcode, it saves me a lot of typing work. Also, it confirms my code is probably error-free in real time. However, to me, some code suggestions are disturbing. For example, when I type else after an if-statement, Xcode suggests this:
else {
statement
}
I'd like to change this to just:
else
statement
Because, I quite often just want to use one line of code there, and adding curled brackets goes much faster than removing them. The other annoying thing is the fact that using such a suggestion takes the return key, while a new line does as well. So, if I would want to use my preferred way as shown above, I would first have to press the escape key in order to stop Xcode suggesting it, and then press the return key. Not a real pain, but I think it's unnecessary.
There are some other code suggestions which I would like to change, but I think I have made my point already. Is there a way to change these code suggestions? I know Apple doesn't provide an easy way within Xcode itself, but I'm willing to dive into the finder for the file with suggestions and change it manually. Thanks!
in your example, it would work to add a space after typing else. Doing that removes the brace suggestion and you can just hit enter.
I've sort of got Fsi.exe working as expected on a Mac OS X (Snow Leopard) with Mono. I just noticed a little bit of odd behavior with cut and paste and I was wondering if anyone had seen this.
I've defined the following alias for fsi:
alias fsi='ledit mono ~/FSharp-1.9.7.8_2/bin/fsi.exe --gui-'
ledit is an Ocaml utility that seems to make the keyboard input work correctly--without it, fsi just never seems to read the input. To see what I mean, try Fsi.exe without ledit and enter
let square x = x * x;;
without ledit, it just never seems to parse the input. I mean it never comes back to the ">" prompt after you enter the string. With ledit, the ">" prompt comes back immediately.
Of course the --gui- keeps fsi from displaying all the messages about the lack of System.Drawing etc.
So this all seems to work. The oddity is when I copy and paste code into the FSI, certain characters seem to repeat over and over again. It seems to be conditioned by the size of the buffer I'm pasting in. When I paste small snippets there seems to be no problem. But if I paste in larger chunks, there's this oddity.
If I do the following:
open System.IO;;
then paste this code snippet in FSI:
let buildFileList basepath filespec =
seq {
yield! Directory.GetFiles(basepath, filespec, System.IO.SearchOption.AllDirectories)
}
That works fine. But if I copy and paste in a bigger chunk of code ending with that, it repeats the portion up to the yield! over and over again. It seems to be somehow related to fsi attempting to parse the code as it's being pasted in because the same code pasted in will cause parsing errors (like FS0010) when it's pasted at the end of a long chunk but won't cause an error when it's isolated.
If I #load the entire file, it parses correctly as well so I think my code is ok.
This oddity in copy/paste seems to happen both with and without ledit on the command line. I don't mind researching this issue myself but I'm kind of stumped about where I should proceed with this. I'm copying from GVim if that makes a difference but anyone have any idea where I might proceed in trying to isolate the cause of this odd behavior? I suppose I could take the extra step of copying into TextEdit first and then trying to copy into fsi but any ideas beyond that?
To bottom line this: has anyone else seen this odd behavior? If not, any suggestions about how I might proceed in trying to isolate the cause of this odd behavior?
When I encountered this behavior on my Mac, I went a different route. Instead of using ledit, I employed fsi's --readline option, seen below (where ${FSHARP} is my install path).
mono ${FSHARP}/fsi.exe --readline+ --gui-
You may also want to check your terminal settings. My terminal (for example) is declared as xterm-color, and I have unchecked delete sends CTRL-H. I think those are the only relevant settings, but don't hold me to it.