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

open
nobody
None
5
2014-08-18
2013-08-13
Shigeharu TAKENO
No

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.

1 Attachments

Discussion

  • Ethan Merritt
    Ethan Merritt
    2013-08-17

    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
    Ethan Merritt
    2013-08-17

    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'
    
     
    Last edit: Ethan Merritt 2013-08-17
  • 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}".