Line continuation support

[nvanwyen]

I ran into your library, which looks stunning (thank you), and was wondering if it supported line continuation. For example, my need requires that the user be able to "enter" and continue to the next line, with a numerical indicator of the line. Except for the builtin (help format, save, etc... ) commands are ended with a semi-colon ";" ... something like this ...

replxx> this
      2 is
      3 an
      4 example of 
      5 continuation lines;
replxx> this is an example of  continuation lines;

I haven't dug into the library yet, so I thought I'd ask before spending to much time. Any advice, example, or information you can provide would be greatly appreciated.

Thank you

[AmokHuginnsson]

Hello.

What you are talking right now is multiline editing.
Unfortunately replxx right now does not support this feature.
Though I am all for adding this feature to library.
The work required is substantial, I do not work on replxx full time ;)
so help would be appreciated.

The work would have to start with fixing #6, or maybe a new issue should be
opened for refactoring keybinding code in inputbuffer.cxx.

Only after that multiline editing (or continuation editing as you call it) should be added.

Hope that answers your question.

Regards.

[nvanwyen]

I've cloned the code and I'm looking at it. If I get anywhere with #6 (as that would also be useful for my project), I'll certainly share it

[loics2]

Any news about this feature?

[AmokHuginnsson]

Replxx code base has been cleaned up so work on new major feature like multiline editing could be started. I would gladly accept pull requests implementing this feature.

[loics2]

Great ! I could take a look, do you have an idea where to start? I don't really know the codebase yet.

[AmokHuginnsson]

replxx_impl.cxx is where most of the logic is implemented.
One suggestion would be to disable all fancy features (hints, highlighting),
when multi-line entry is detected.
Newlines could be bound to Shift-Enter (as this combination can be distinguished from plain Enter on terminals).

[PerBothner]

"Newlines could be bound to Shift-Enter (as this combination can be distinguished from plain Enter on terminals)."

Alternatively Alt-Enter, which is used by fish shell

[minfrin]

According to the README.md:

single-line and multi-line editing mode with the usual key bindings implemented

What is the "multi-line editing mode", and how is it different to "line continuation support"?

[AmokHuginnsson]

Hello.
Current master (e7646e7) is implementing true multiline editing.

[amosbird]

@AmokHuginnsson This is pure awesome! I've started using it for a couple of hours now. However, there is one tiny issue: when moving cursors fast enough (word movements), replxx seems rendering a bit slow. I can visibly experience text "jittering". Maybe we can improve the performance somehow?

[AmokHuginnsson]

I think we could partially skip virtual_render() calls if we detect that refresh_line() was called because of cursor movement. We could skip painting itself.

[AmokHuginnsson]

@amosbird
I have implemented cursor movement optimization in current master (5ee2234).

[amosbird]

Cool! It's indeed better. Though some movements are still glitchy.

Good: Word-Left, Home, End
Bad: Up, Down, Left, Right, Word-Right

Btw, it seems we don't handle multiple lines properly which cannot be filled in one screen. I guess it's ok for the moment)

[AmokHuginnsson]

In what ways are they glitchy?

[AmokHuginnsson]

Oh, I know how left and right can be glitchy. I will happen if you have a lot of parentheses in your input entry.

[amosbird]

In what ways are they glitchy?

I tried to make some screencast but it's not enough to capture the issue.... It's a visible text re-rendering when moving cursors right by word. It's interesting that moving left is perfectly fine.

[AmokHuginnsson]

Up and Down should work a little bit better on current master.

[AmokHuginnsson]

I tried to make some screencast but it's not enough to capture the issue.... It's a visible text re-rendering when moving cursors right by word. It's interesting that moving left is perfectly fine.

By any chance, when you are moving right by word, do you land on an opening bracket/parenthesis, e.g. input:

foo() bar() zoom()

?

[amosbird]

Sorry I missed your last reply. There isn't any opening bracket/parenthesis. I'll try to make clickhouse-client use the upstream version and have it test more widely.

[AmokHuginnsson]

Please open a new issue when you find mode information about performance problems you are experiencing.

Thank you.

[amosbird]

@AmokHuginnsson Do you think we should make Ctrl-U delete to the beginning of line instead of buffer? Same for Ctrl-k

[AmokHuginnsson]

@amosbird Yes, it would be consistent with how HOME/END keys behave now.
Having some shortcut to delete everything to beginig/end of buffer would be nice.
ALT-u and ALT-U are taken by your previous work on subwords though.
Lets think carefully about what default key bindings should be.

[amosbird]

it would be consistent with how HOME/END keys behave now.

We also need to tune the behavior of Ctrl-a and Ctrl-e to be consistent.

Lets think carefully about what default key bindings should be.

In fish-shell, when at the beginning of a line, pressing Ctrl-U will delete the carriage return and moves up a line. As a result, we can hold the key to kill all previous lines conveniently. Not sure if it's enough)

[AmokHuginnsson]

I implemented suggested change on current master.

Ctrl-u kills to beginning of line unless already at the beginning of line, when it kills to beginning of buffer as before.

Ctrl-k has analogous semantics.

Ctrl-a and Ctrl-e also have been updated.

[amosbird]

It's actually quite good (though it's not exactly the same as the suggestion :D )

Btw, what do you think of rendering multiple lines with prompt indentation. In fish shell, we have multiple lines like this:

It's a bit unpleasant to see multiple lines unaligned in replxx.

[AmokHuginnsson]

That sounds interesting, though implementing it correctly sounds cumbersome, considering taking proper care of line wrapping (for overlong lines).
I implemented POC that works for lines that fit the terminal, it does not work for overlong lines though yet.

[amosbird]

Line wrapping is indeed trouble some. Fish-shell doesn't indent the wrapping parts

[AmokHuginnsson]

I wonder if its better to indent wrapped parts or not from UX point of view...

[AmokHuginnsson]

I have implemented first draft of extra indent in miltiline inputs feature.
It is on current master now.

[amosbird]

I wonder if its better to indent wrapped parts or not from UX point of view...

I feel that indenting wrapped parts is not good because user cannot easily tell apart lines.

I have implemented first draft of extra indent in miltiline inputs feature.

I just tried it and it seems not so good. Moving cursors up and down will break the rendering. And I can move the cursor beyond the end of a given line.

[AmokHuginnsson]

Can you give me the "input" and set of key strokes where the rendering is broken?

[amosbird]

Here is the input. It's braketed pasted into the buffer. Pressing UP makes prompt go away, and all the lines are re-rendered from the top of the terminal.

This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line!
This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line!
This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line!
This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line!
This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line!
This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line! This is a super long line!

[AmokHuginnsson]

Oh, I thought you meant that rendering is broken for lines that fit in the terminal.
I agree what indentation of wrapped parts makes it harder to read and I will change the implementation.

[AmokHuginnsson]

Can you check current version?

[amosbird]

Can you check current version?

It's perfect!

[AmokHuginnsson]

@amosbird

Heads up!
Previous commit (master) was broken!
I pushed fixed version.
Look into commit message and diff on replxx_impl.cxx in refresh_line() method.

[amosbird]

Ok.. I've pushed the fix to the PR)

[amosbird]

@AmokHuginnsson Hi! I just found that when the multiple line content goes beyond the height of current terminal, going from bottom to top will not render the buffer from beginning but always shows the tail part.

[AmokHuginnsson]

This + other reported issue related to very long lines seems difficult to fix properly to me.