bug-readline
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-readline] multi-line input editing [enhancement suggestion]


From: Per Bothner
Subject: [Bug-readline] multi-line input editing [enhancement suggestion]
Date: Mon, 2 Apr 2018 11:06:11 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

By "multi-line editing" I mean that the readline input area can be
more than one line, and you can move the cursor between the lines,
and make changes to previous lines in the same command (input area).
Readline already seems to have basic support, used when pasting a
multi-line text and enable-bracketed-paste is on.

Some readline alternatives can handle multi-line editing in a more integrated 
way:
Ones I know about are jline3 (used for Java programs) and the Python "prompt 
toolkit"
http://python-prompt-toolkit.readthedocs.io/en/stable/

So what changes would be needed for better multi-line editing?  Here are my
suggestions, written in the context of bash+readline, but can apply to
other readline-using applications.

* When a continuation line is requested (i.e. when PS2 is printed),
enter multi-line mode: The previous incomplete command becomes the
start of a new multi-line input area, with the cursor at the start of
a new empty line (after the PS2 prompt, of course).  This requires a
new public readline function.

* When a newline is inserted inside paste-brackets, that should
enter multi-line mode - as it currently does.  However, PS2 should be
printed at the start of each continuation line.  That requires an addition
to the readline API so the application (e.g. bash) can specify a continuation 
prompt
to use when needed. (Jline supports a continuation prompt *pattern*, with 
optional
padding and line numbers, but that is a lower-priority frill.)

* The history should preserve newlines, rather than "normalize" the lines.
I.e. currently the input "(echo foo\necho bar)" is "normalized to
"(echo foo; echo bar)" in the history.  It would be better to preserve it
as the former - though I guess there may be some compatibility concerns
for saved history files.)

* The default binding for up/down-arrow should (I think) be to move up/down
within the current multi-line input area.  Move to the previous (next) history 
item
only if the cursor is at the top (bottom) line of the input area.

* Maybe a key-binding for "literal newline". This should have the same effect
as pasting a single newline (surrounded by paste-brackets).  Maybe Escape-Enter
and/or Alt-Enter (which at least the Konsole terminal emulator maps to 
Esc-Enter).
--
        --Per Bothner
address@hidden   http://per.bothner.com/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]