#634 save multiline input to a single line in the history

[Shigeharu TAKENO]

In Japanese gnuplot BBS, someone noticed the following behaviour.
The multi-line inputs with a backslash at the end of lines are
saved as muti-lines in the history file. For example, when we
input

gnuplot> plot \

sin(x) \ with lp

these are saved as

plot \ sin(x) \ with lp

in the history file.

But, it is not usefull. It is more usefull to save such
multi-lines to a single line

plot sin(x) with lp

in the history file.

Attached patch is for such feature under the condition
HAVE_LIBREADLINE. But it may not be correct.

[Ethan Merritt]

I do not know why a user would cut a short command into even shorter lines.
The usual reason for using the \ continuation symbol is to make very long line more readable. Like this:

plot 'verylongfilename1' using (expression):(expression) complicated options, \ 'shortfilename' using 1:2 notitle, \ 'verylongfilename2' using (someotherexpression):(etc) complicated options, \ 'finalfile' using 1:2 title 'this title takes up a lot of room'

The reason for keeping the line breaks is the same reason that the user chose to use separate lines when typing. It makes the command easier to read and understand.

[Ethan Merritt]

Heh. And I see that the mark-down text processing here has mangled my input, making it very clear how much harder it is to read if you join the lines. The original was supposed to look like this:

plot 'verylongfilename1' using (expr):(expr) with complicated options, \
      'shortfilename' using 1:2 notitle, \
      'verylongfilename2' using (anotherexpression):(etc) with complicated options, \
      'finalfile' using 1:2 title 'this title takes up a lot of room'

[Shigeharu TAKENO]

The example I showed is only for explaining the feature. I
know the command line continuation is for very long command
line.

I think the editing of command line is not so difficult
even for the very long command line because the readline
library gave us useful features for the editing.

So, I think someone prefer

(A) to edit the very long single command line

than

(B) to edit multiple command line.

In the case (A), we must to move the cursor in the wide range,
but we can run the command line simply. In (B), it is easy
to edit each lines, but is not easier to run the command
than (A). Especially, when there are few points to edit, or
we want to run the command line again and again, it may be
easy to choose (A).

Moreover, after editing the 2nd line and putting enter key,
we can not modify the 2nd line in (B).

If possible, it may be able to choose (A) or (B) by a set
command, for example, "set history {single | default}".