multi-line reader support in jline3?

[p...@bothner.com]

Is there a way (current or planned) for a MultiLineReader (or whatever)?

I.e. something a LineReader (with prompts and history), but where each line can actually be multiple lines.

For an example of what I mean see http://jupyter.org/qtconsole/stable/ Note in the screenshot that command "In[2]" has multiple continuation lines.

I got the impression that JLine3 would support this model, but it looks like I mis-remembered.

JLine has low-level capability, in that it supports an actual multi-line editor (Nano), so what we're looking for a hybrid between LineReader and Nano.

Having multi-line input can be very nice for a programming-language REPL: You can edit a whole complex command or a function definition, and go back and forth between the different lines.

Multi-line mode means that a history entry can be multiple lines.   Moving between history would "swap in" multi-line commands, not single lines.  Up-arrow moves to the previous history entry if the cursor is at the top line of the current command; otherwise it moves up one line in the current command.  Likewise for down-arrow. (This is how the Jupyter qtconsole works, and that seems quite nice.)

Creating a multi-line command could happen multiple ways.  While plain Enter should default to being plain "submit" some other key-sequence would have the effect of breaking the current line into two.  Using Shift-Enter is "standard", though that requires tweaking the terminal emulator to send a unique key sequence for Shift-Enter.

A Paste command (marked by "bracketed-paste") would insert multiple lines.

A REPL may have a command to "load this string value into the line input buffer".

Finally (and most tricky): Smart continuation lines. Many REPLs recognize when a command in "incomplete"  For example sh will switch to a continuation prompt and request more input.  However, bash+readline won't let you move the cursor to the previous line to fix a mistake.  It would be really nice to be able to do that.  Especially if we have on-the-fly error checking.  The client would parse the line returned by readLine, notice it is incomplete, and call a special JLine method to extend the previous command.

Prompts are a slight complication.  The Jupyter qtconsole uses "---" for continuations prompts, but I would prefer to include line numbers (not command numbers).

Presumably JLine would call a user-supplied function to get the actual prompt, passing a sequence number to distinguish continuation lines.

 

I've prototyped part this design in DomTerm (http://domterm.org/), which does editing locally in a browser (using contenteditable), and using mutation listeners to update the prompts.

II've only checked in part of the prototype, because I'm not sure it's the right way to go - portability to most terminals would be nice. Also, JLine3 seems to have a lot of functionality that would be useful to build on.

(Though local editing in the browser has some advantages, such as mouse support.)

How difficult would it be to support this in JLine? Would it be desirable?  Are there any examples of similar functionality?  If not, I can take a look at what would be involved.

[Colin Jones]

Thanks for bringing this up! I've gotten this feature request before for my use case, and I haven't seen similar functionality with JLine at the bottom.

I have a vague suspicion (based on a cursory glance a couple years or so ago) that it would be difficult, but haven't spent much time finding out (or looking at JLine3 and how it changes the game).

--
You received this message because you are subscribed to the Google Groups "jline-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jline-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Colin Jones
@trptcolin

[Guillaume Nodet]

Jline 3 has full support for multi line reading.

It has a pluggable parser (https://github.com/jline/jline2/blob/jline3/src/main/java/org/jline/reader/Parser.java) which can be used to  trigger multiline editing.  If the parser throws a EOFError (https://github.com/jline/jline2/blob/jline3/src/main/java/org/jline/reader/EOFError.java), the LineReader will assume that the line is not finished and will add a secondary prompt to continue editing on the next line.

--

[p...@bothner.com]

Great.  Do you have any examples or sample code? I see no documentation or examples in the repository. I'd like to try to get this working for Kawa.

[Guillaume Nodet]

Use the following shell script to launch an example using jline3

   https://gist.github.com/gnodet/08b74734c447f9da9213c4a4d50ccccf

To see available commands, use

  > go<tab>

To see multiline, use

  > (echo "<return>

Cheers,

Guillaume

[p...@bothner.com]

Thanks!  That is close to what I'm looking for.  My preference is a different style of continuation prompt: For a programming language it is important that the primary prompt and the continuations prompts have the same width.

I found the gogo/jline source code, and I'm working on understanding how things work.

[Guillaume Nodet]

On Mon, May 9, 2016 at 7:58 AM, <p...@bothner.com> wrote:

Thanks!  That is close to what I'm looking for.  My preference is a different style of continuation prompt: For a programming language it is important that the primary prompt and the continuations prompts have the same width.

Agreed.

There's already an option for padding secondary prompts, but we could add one for padding the primary prompt too.

We should also make the secondary prompt configurable (which isn't the case yet).

Could you raise issues for those jline3 enhancements ?

 

I found the gogo/jline source code, and I'm working on understanding how things work.

--

[p...@bothner.com]

On Monday, May 9, 2016 at 8:31:34 AM UTC+2, Guillaume Nodet wrote:

On Mon, May 9, 2016 at 7:58 AM, <p...@bothner.com> wrote:

Thanks!  That is close to what I'm looking for.  My preference is a different style of continuation prompt: For a programming language it is important that the primary prompt and the continuations prompts have the same width.

Agreed.

There's already an option for padding secondary prompts, but we could add one for padding the primary prompt too.

We should also make the secondary prompt configurable (which isn't the case yet).

Could you raise issues for those jline3 enhancements ?

 Done. See https://github.com/jline/jline2/issues/246

[p...@bothner.com]

If people think the "specification" (see https://github.com/jline/jline2/issues/246) is reasonable, then I can implement it.

[Guillaume Nodet]

Cool, i'll have a closer look at it then ;-)

I'll comment asap.

On Fri, May 13, 2016 at 5:40 PM, <p...@bothner.com> wrote:

If people think the "specification" (see https://github.com/jline/jline2/issues/246) is reasonable, then I can implement it.

--