#1747 misbehavior in linux console: cursor not moving line up in previous command, no tab-hints in '<' source

[Marcin L]

Gnuplot Version 5.0.3
Platform: Debian jessie (GNOME 3.14.4)

Two problems in working in the linux console:

1. If you arrow-up in command history to a long command, and then arrow-left in order to edit the command, cursor won't move up to previous line in case your command was folded. Explained visually in the image below:
   

2. Typically under TAB, you get filename-hints. Doesn't work if you start plotting from '<' source. For example, if you start typing:

plot '<

and press TAB, no filename-hints will be presented. Removing "<" character turns the functionality back.

Both issues happen on every terminal I tried:
gnome-terminal 3.14.1
konsole 2.14.2
xfce4-terminal 0.6.3

[Hans-Bernhard Broeker]

Your second issue is not a bug; you're expecting too much there.

Auto-completing file names in that situation would be wrong anyway. What you're to enter there is a full-blown command line, not just some file name.

[Marcin L]

I happen to disagree, it wouldn't be wrong, it's actually very useful. In full-blown command line you may will still want to use filenames in order to pipe some stream from a file. Personally I most often keep data in SQLite files and pipe queries into gnuplot, but you can also imagine running some scripts, or piping files into other data-manipulating tools like grep and only then into gnuplot. Also, it works after getting fixed and to me it's a great feature, saves a lot of typing.

[Bastian Märkisch]

As a workaround just add another space after <. Then you will get tab-completions again.
I guess adding < and | as allowed separators won't hurt, though.

[Bastian Märkisch]

The tab-completion issue is fixed in CVS since 2016-05-26 for version 5.1. Could be applied to 5.0, too.

[Ethan Merritt]

Please show the output of "show version long" so that we can determine what input library you are using. I think that the problem you describe is not present if you are using libreadline. The alternatives to libreadline (libedit or gnuplot's own fallback code) are not as capable in handling long input lines.

Solution: select "--with-readline=gnu" when building the program.

[Marcin L]

gnuplot> show version long

    G N U P L O T
    Version 5.0 patchlevel 3    last modified 2016-02-21 

    Copyright (C) 1986-1993, 1998, 2004, 2007-2016
    Thomas Williams, Colin Kelley and many others

    gnuplot home:     http://www.gnuplot.info
    faq, bugs, etc:   type "help FAQ"
    immediate help:   type "help"  (plot window: hit 'h')
Compile options:
+READLINE  -LIBREADLINE  +HISTORY  
-BACKWARDS_COMPATIBILITY  +BINARY_DATA  
-LIBGD  
-USE_CWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +X11_EXTERNAL +USE_MOUSE  +HIDDEN3D_QUADTREE  
+DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +THIN_SPLINES  +IMAGE  +USER_LINETYPES +STATS +EXTERNAL_FUNCTIONS 
MAX_PARALLEL_AXES=7

GNUPLOT_DRIVER_DIR = "/usr/local/libexec/gnuplot/5.0"
GNUPLOT_PS_DIR     = "/usr/local/share/gnuplot/5.0/PostScript"
HELPFILE           = "/usr/local/share/gnuplot/5.0/gnuplot.gih"

[Ethan Merritt]

Right. The "+READLINE -LIBREADLINE" flags tell us that gnuplot's own fallback input code is being used rather that gnu libreadline. The fallback code is actually pretty good, but handling long lines is one place where it could be improved. Your best solution is to link the program against libreadline.

[Marcin L]

Worked! Thanks chief!