#1444 copypaste inline data with tabs

[Karl Ratzsch]

If I copy&paste data with tab separator to define inline data, the parser does not detect the separator between columns (even with an additional space between columns). This happens for example when taking a table from a browser window.

The columns are read in (the table can be printed), but consists of string values. (if the pasted data contained space+tab separators, the table even looks ok if printed, but doesn´t work with plot.)

When entering the data by hand on the gp console, this does not happen, also if the the whole thing is read in from a file via "load".

I guess this problem could be very specific to the actual build+OS, i´m on win7, gp5 binary from Tatsuro Matsuoka, so compile options were +READLINE -LIBREADLINE

[Ethan Merritt]

Nothing to do with gnuplot - sorry.
The program doing the copy-paste is at fault for losing the tabs. They are not stored in the paste buffer and therefore cannot be passed to gnuplot.

The same problem exists on linux+X11 if you try to copy+paste from a terminal display. If, on the other hand, you do the same copy+paste from an editor then it works correctly.

[Karl Ratzsch]

So i thought, but why does it also fail if all numbers are separated by space+tab?

If i print the inline data

print $list

, i then get a nice table with spaces between numbers, but i cannot plot from it.

I understand that each line is just stored as one string internally, is that right?

[Ethan Merritt]

Perhaps your script still says "set datafile separator '\t'" even though the tabs are gone?

[Karl Ratzsch]

No, datafile separator was not changed.
However i now printed the inline dataset to a file and there are no tabs in it (0x09) but file separator FS characters (0x1c).
Pasting the same piece into my editor gives tabs (0x09).

[Ethan Merritt]

there are no tabs in it (0x09) but file separator FS characters (0x1c)

Huh. I have never seen that character used anywhere.
In gnuplot v5 you can specify more than one field-separation character, so you could tell it to accept either tab or 0x1c using

set datafile separator "^i^\"

where ^i is ctrl-i (tab) and ^\ is cntrl-backslash (0x1c)

[Karl Ratzsch]

Not possible to enter that on Win7. :-/
This however works:

set datafile separator sprintf("%c",0x1c)

But where do the 0x1c come from? All other programs i try get tab characters, and copied tab spaced numbers from there again become spaced by 0x1c in gnuplot. The problem seems to be somewhat gnuplot-specific.

[Karl Ratzsch]

Sorry to be so insisting on this subject, but i just noticed something very peculiar with copypasting tabs:

I copy a line starting with a tab (e.g. "<tab>test") and paste it into the gp console window (gp5 wgnuplot.exe, Tatsuro´s build), and i get this:

airfoil.demtest

This is reproducible over restarting gnuplot and cleaning out the history, and it´s surely months ago that i tried out the airfoil demo.
Homebrewed wgnuplot.exe from todays cvs gives

alloc.dtest

"test<tab>test" pastes as

test.cairo.pngtest

Something in gnuplot does really weird things when it stumbles upon a tab character.

[Hans-Bernhard Broeker]

That "something in gnuplot" is called TAB completion. If you typed a TAB in the command line yourself, you would get the exact same behaviour you see when you copy-paste one: it selects the first matching file name in the current directory.

There's not even anything new about this: wgnuplot has had this capability for about a decade.

[Karl Ratzsch]

Ok, i really should have come to that conclusion myself, with those file names turning up. ;-) Thanks.

It seems a bit strange that pasting text triggers the tab completion, though. Does that also happen on other OS? I cannot quite see what it´d be good for.

[Bastian Märkisch]

With today's CVS version, you can now paste tabs (again) using wgnuplot.
Btw. gnuplot's built-in readline only has tab-completion since about five years now.