Menu
▾
▴
gnuplot-beta
|
From: Tait <gnu...@t4...> - 2012-03-24 23:22:24
|
Something new as of gp 4.6.0 on Windows is that a tab character, entered into the interactive terminal, expands into a filename. Can this behavior be disabled via some configuration? I often develop files with \-continuations, e.g. plot '-' title "nzrgrdr" \ '-' title "ghlallaghp" \ '-' title "xyzpthrtk" Note the tab-indent on the line continuations. When I 'load' such a file into gnuplot, it works fine, but often in the course of development or helping others, I copy-and-paste these into the interactive terminal. This worked before, but now breaks because the leading tab expands to a filename, which is of course a syntax error. Vim works around issues like this by using paste detection, but the easier solution is probably just to disable filename-expansion. The current situation makes it impossible to interactively type anything containing a tab. For example, print "x y result" even fails because the tab cannot be inserted without turning into a filename. The usual character-escape or ctrl-v quote-literal terminal tricks that would work on *nix do not work on the Windows terminal. |
|
From: <pl...@pi...> - 2012-03-25 12:43:18
|
On 03/25/12 00:21, Tait wrote: > I often develop files with \-continuations, e.g. > plot '-' title "nzrgrdr" \ > '-' title "ghlallaghp" \ > '-' title "xyzpthrtk" > > N I agree that tab completion is probably unhelpful in a context where a tab is a possible input character. I generally find it more productive to think for myself that to have a program try to do it for me and keep breaking my concentration by second-guessing what I'm trying to do and jumping in to mess with what I'm typing. Perhaps the feature should be limited to a context were it could actually be a filename but that would probably be complicated and unreliable. My approach would be to bin it. BTW if you want to align multi-line plot commands like that I put all the plotted files including the first on the extended lines by assigning a throw-away variable just after plot. That makes all the lines have identical syntax and I can cut and paste to reorder or remove them at will. plot s=0 \ , file1 with lines \ , file2 with lines \ , file3 using 1:2 \ #, file4 tit "test version" \ that would work around your tab problem. This a valid bug though. regards. |
|
From: Tait <gnu...@t4...> - 2012-03-26 09:26:29
|
> BTW if you want to align multi-line plot commands like that I put all > the plotted files including the first on the extended lines by > assigning a throw-away variable just after plot. That makes all the > lines have identical syntax and I can cut and paste to reorder or remove > them at will. > > plot s=0 \ > , file1 with lines \ > , file2 with lines \ > , file3 using 1:2 \ > #, file4 tit "test version" \ That's a useful tip; I hadn't thought to put the commas first. Thanks. |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-03-25 17:44:25
|
On Saturday, 24 March 2012, Tait wrote:
>
> Something new as of gp 4.6.0 on Windows is that a tab character, entered
> into the interactive terminal, expands into a filename. Can this behavior
> be disabled via some configuration?
If you are talking about tab completion in the readline library,
it can be disabled by putting
set disable-completion on
in the file ~/.inputrc (or whatever the Windows equivalent is).
If you are talking about tab completion in the built-in readline code,
I don't see any way to disable it currently. That seems like a
reasonable feature to add.
> I often develop files with \-continuations, e.g.
> plot '-' title "nzrgrdr" \
> '-' title "ghlallaghp" \
> '-' title "xyzpthrtk"
>
> Note the tab-indent on the line continuations. When I 'load' such a file
> into gnuplot, it works fine, but often in the course of development or
> helping others, I copy-and-paste these into the interactive terminal.
> This worked before, but now breaks because the leading tab expands to a
> filename, which is of course a syntax error.
Hmm. This doesn't happen under linux because the cut-and-paste operation
itself replaces tabs with spaces. I have no idea whether Windows
can be configured to do the same thing, but that would be another
work-around you might investigate.
> Vim works around issues like this by using paste detection, but the
> easier solution is probably just to disable filename-expansion. The
> current situation makes it impossible to interactively type anything
> containing a tab. For example, print "x y result" even fails
> because the tab cannot be inserted without turning into a filename. The
> usual character-escape or ctrl-v quote-literal terminal tricks that would
> work on *nix do not work on the Windows terminal.
Forgive my Windows ignorance, but...
I can understand that ctrl-V doesn't work here because Windows thinks
that it means "paste" rather than "verbatim".
But isn't there some other control character that is equivalent
to *nix ctrl-V?
|
|
From: Tait <gnu...@t4...> - 2012-03-26 09:24:36
|
> > Something new as of gp 4.6.0 on Windows is that a tab character, entered > > into the interactive terminal, expands into a filename. Can this behavior > > be disabled via some configuration? > > If you are talking about tab completion in the readline library, > it can be disabled by putting > set disable-completion on > in the file ~/.inputrc (or whatever the Windows equivalent is). > > If you are talking about tab completion in the built-in readline code, > I don't see any way to disable it currently. That seems like a > reasonable feature to add. GPVAL_COMPILE_OPTIONS = "+READLINE -LIBREADLINE..." I think that means it's the built-in version > Hmm. This doesn't happen under linux because the cut-and-paste operation > itself replaces tabs with spaces. ... Is this a terminal thing? Or gnuplot-specific? I can't fathom that it's helpful to _always_ replace tabs when pasting. > > Vim works around issues like this by using paste detection... > > usual character-escape or ctrl-v quote-literal terminal tricks that would > > work on *nix do not work on the Windows terminal. > > Forgive my Windows ignorance, but... > I can understand that ctrl-V doesn't work here because Windows thinks > that it means "paste" rather than "verbatim". > But isn't there some other control character that is equivalent > to *nix ctrl-V? In general, no. For vim, when windows behaviors are enabled, the quote- next behavior of ctrl-v is re-mapped to ctrl-q. Other applications like PuTTY disable ctrl-v for paste and use it for quote-next (since shift- insert is still available for paste). The command prompt simply doesn't have any way to insert special characters (that I know). The filename completion characters used to be ctrl-d/ctrl-f, so it was rarely a conflict. Newer Windows versions use tab by default now, but still have no quote-next behavior. |
|
From: <pl...@pi...> - 2012-03-25 19:31:41
|
On 03/25/12 00:21, Tait wrote: > Something new as of gp 4.6.0 on Windows is that a tab character, entered > into the interactive terminal, expands into a filename. Can this behavior > be disabled via some configuration? Isn't this a bug anyway. I thought the idea of tab completion was that you had to hit return of something to accept the intervention. If you carry on typing it should just disappear. regards. |
