gnuplot-beta — Developers and beta testers of new gnuplot code

Re: q for quit in plot windows

[Ethan M. <merritt@u.washington.edu>]

On Thursday 31 May 2007 14:06, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> 
> > I may have mis-counted, but I only see that one built-in ('r') that can
> > possibly work for anything but the current window.  And I'm not even sure
> > about that one.  Try hard-wiring it to allwindows=TRUE, and tell me what
> > happens :-)
> 
> I'm guessing it will change/activate something in the wrong window because we 
> aren't keeping track of the X11 window number or some similar identifier.

Yes we are.  That's how the "allwindows" option works.
It passes the window identifier along with the event.


-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: q for quit in plot windows

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

> I may have mis-counted, but I only see that one built-in ('r') that can
> possibly work for anything but the current window.  And I'm not even sure
> about that one.  Try hard-wiring it to allwindows=TRUE, and tell me what
> happens :-)

I'm guessing it will change/activate something in the wrong window because we 
aren't keeping track of the X11 window number or some similar identifier.

Dan

Re: q for quit in plot windows

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Thursday 31 May 2007 13:39, Petr Mikulik wrote:
> 
>>>I'll repeat myself, maybe you lost it in the noise of my message: The easy
>>>fix means a big regression; 'q' and ' ' would not always work anymore, but
>>>only when the terminal is the active one.
>>
>>'q' and ' ' should work as they are. It is sufficient and a very clean way 
>>to switch them on/off by a term->xxxx() command I proposed earlier.
> 
> 
> Petr:
> 
> It is not as simple as you make it sound.
> Consider the example Timothée already mentioned.
> You have an old x11 plot window open, but the current terminal
> is something else.  Maybe wxt, maybe postscript, ... whatever.
> 
> In this state, keystroke events in the old x11 plot window will not be 
> delivered to the core gnuplot routines, and so they cannot be handled
> by the normal "bind" mechanism.

Isn't that what the "allwindows" setting is for?

   We work around this by
> having gnuplot_x11 handle 'q' locally, but this requires treating it
> as a special case.  If we move the 'q' response into the normal
> event_keypress() code in mouse.c, it will no longer be possible to
> close plot windows opened by a previous terminal type.

You're saying that because the terminal was changed, the term->xxxx mechanism 
will point to the terminal the window is not part of.  Can the terminal pointer 
be saved somewhere, or would that require a new system of linked lists?

Dan

Re: q for quit in plot windows

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Thursday 31 May 2007 12:55, Daniel J Sebald wrote:
> 
>>As you explained, the mouse-in-only-one-window limitation came back to me, so 
>>that is why the asterisk.  Yet, some would consider the mouse-in-only-one-window 
>>a bug in itself.
> 
> 
> It's not a bug. It's an intrinsic limitation of the way gnuplot operates.

Ah, ILOTWIO.  I'll have remember that one.  :-)


> Most of the hot-keys, like e=replot l=log-scale, etc, require redrawing the
> plot from scratch.  But that is only possible for the currently active
> plot window.  We have long since lost the context and information needed
> to redraw old plot windows, so we cannot respond to those hot-keys.
> 
> Possibly the r=ruler key could default to all windows. I'm not sure.

The allwindows is already in the binding structure, and the code says

     new->allwindows = FALSE;	/* Can be explicitly set later */

but I don't see where any function making it easy to do so for the builtins and 
the binding pointer is tossed.  A little change would be needed there.  (Maybe 
as easy as simply returning the binding pointer from the bind_append routine.)

Dan

Re: q for quit in plot windows

[Ethan M. <merritt@u.washington.edu>]

On Thursday 31 May 2007 13:39, Petr Mikulik wrote:
> > I'll repeat myself, maybe you lost it in the noise of my message: The e=
asy
> > fix means a big regression; 'q' and ' ' would not always work anymore, =
but
> > only when the terminal is the active one.
>=20
> 'q' and ' ' should work as they are. It is sufficient and a very clean wa=
y=20
> to switch them on/off by a term->xxxx() command I proposed earlier.

Petr:

It is not as simple as you make it sound.
Consider the example Timoth=E9e already mentioned.
You have an old x11 plot window open, but the current terminal
is something else.  Maybe wxt, maybe postscript, ... whatever.

In this state, keystroke events in the old x11 plot window will not be=20
delivered to the core gnuplot routines, and so they cannot be handled
by the normal "bind" mechanism.  We work around this by
having gnuplot_x11 handle 'q' locally, but this requires treating it
as a special case.  If we move the 'q' response into the normal
event_keypress() code in mouse.c, it will no longer be possible to
close plot windows opened by a previous terminal type.

In other words, the problem is not lack of a term->xxxx() mechanism.
The problem is in receiving the keystroke event notification.

=2D-=20
Ethan A Merritt

Re: q for quit in plot windows

[Petr M. <mi...@ph...>]

> I'll repeat myself, maybe you lost it in the noise of my message: The easy
> fix means a big regression; 'q' and ' ' would not always work anymore, but
> only when the terminal is the active one.

'q' and ' ' should work as they are. It is sufficient and a very clean way 
to switch them on/off by a term->xxxx() command I proposed earlier.

---
PM

Re: q for quit in plot windows

[Ethan M. <merritt@u.washington.edu>]

On Thursday 31 May 2007 12:55, Daniel J Sebald wrote:
> As you explained, the mouse-in-only-one-window limitation came back to me, so 
> that is why the asterisk.  Yet, some would consider the mouse-in-only-one-window 
> a bug in itself.

It's not a bug. It's an intrinsic limitation of the way gnuplot operates.
Most of the hot-keys, like e=replot l=log-scale, etc, require redrawing the
plot from scratch.  But that is only possible for the currently active
plot window.  We have long since lost the context and information needed
to redraw old plot windows, so we cannot respond to those hot-keys.

Possibly the r=ruler key could default to all windows. I'm not sure.

-- 
Ethan A Merritt

Re: q for quit in plot windows

[Daniel J S. <dan...@ie...>]

Timothée Lecomte wrote:

> They are. Quote:
>  "By default, the <space> hotkey raises gnuplot's command window. On some
>  terminals (e.g. x11, wx, pm), 'q' closes the graph window. These defaults
> can
>  be changed to ctrl-space and ctrl-q by starting gnuplot as 'gnuplot -ctrlq',
>  see `x11 command-line-options`, or by the X Resource 'gnuplot*ctrlq'.
>  Note: if <space> (or ctrl-space) does not raise the gnuplot window under
> X11,
>  see discussion in `raise`."

Right, but I'm saying that the following documenation is equally as good/bad:

  <Shift-B2-Motion>  vertical motion -- change xyplane

  Space          `builtin-raise-window` raise gnuplot console window
  a              `builtin-autoscale` (set autoscale keepfix; replot)
  b              `builtin-toggle-border`
  e              `builtin-replot`
  g              `builtin-toggle-grid`
  h              `builtin-help`
  l              `builtin-toggle-log` y logscale for plots, z and cb logscale 
for splots
  L              `builtin-nearest-log` toggle logscale of axis nearest cursor
  m              `builtin-toggle-mouse`
  r              `builtin-toggle-ruler`
  1              `builtin-decrement-mousemode`
  2              `builtin-increment-mousemode`
  3              `builtin-decrement-clipboardmode`
  4              `builtin-increment-clipboardmode`
  5              `builtin-toggle-polardistance`
  6              `builtin-toggle-verbose`
  7              `builtin-toggle-ratio`
  n              `builtin-zoom-next` go to next zoom in the zoom stack
  p              `builtin-zoom-previous` go to previous zoom in the zoom stack
  q            	`builtin-close-window` close this plot window
  u              `builtin-unzoom`
  Right          `builtin-rotate-right` only for splots; <shift> increases amount
  Up             `builtin-rotate-up` only for splots; <shift> increases amount
  Left           `builtin-rotate-left` only for splots; <shift> increases amount
  Down           `builtin-rotate-down` only for splots; <shift> increases amount
  Escape         `builtin-cancel-zoom` cancel zoom region

*IF* we say that

> I'll repeat myself, maybe you lost it in the noise of my message: The easy
> fix means a big regression; 'q' and ' ' would not always work anymore, but
> only when the terminal is the active one.

is a bug.  And then fix it sooner than later. :-)  Besides, that's another thing 
we could easily change.  'q' and ' ' have nothing to do with redrawing, so there 
is no need to disable those.

Dan

Re: q for quit in plot windows

[<tim...@en...>]

> Timothée Lecomte wrote:
>>>The ctrl-c copy was easy enough.  Just replace "c" with "ctrl-c"...
>>>
>>>Anyway, I see when typing 'h' for a plot to get the key bindings there
>>> are
>>>these
>>>two at the very top (i.e., follow the button description):
>>>
>>>
>>>  Space          raise gnuplot console window
>>>  q            * close this X11 plot window
>>>
>>>[snip]
>>>
>>>               * indicates this key is active from all plot windows
>>>
>>>I'm assuming that by the use of term->(function) the mouse/keyboard
>>>interface is
>>>meant to be very general and not restricted to X11.
>>
>>
>>
>> I will try not to repeat what was said by Ethan and Petr, but here are
>> my
>> thoughts on this:
>>
>> "raise console" and "quit plot window" do not go through the event
>> system
>> (because they predate it), they are handled directly by the terminal.
>> That's why ' ' and 'q' are keys that you cannot bind to something else,
>> with the exception of the 'ctrl-q' option in x11 and wxt.
>
> Right, but the question is why must the documentation for 'q' and ' ' be
> special, sitting out on its own?  Why can't the 'q' and ' ' simply be
> placed in
> the bindings documentation?

They are. Quote:
 "By default, the <space> hotkey raises gnuplot's command window. On some
 terminals (e.g. x11, wx, pm), 'q' closes the graph window. These defaults
can
 be changed to ctrl-space and ctrl-q by starting gnuplot as 'gnuplot -ctrlq',
 see `x11 command-line-options`, or by the X Resource 'gnuplot*ctrlq'.
 Note: if <space> (or ctrl-space) does not raise the gnuplot window under
X11,
 see discussion in `raise`."

>
> As you explained, the mouse-in-only-one-window limitation came back to me,
> so
> that is why the asterisk.  Yet, some would consider the
> mouse-in-only-one-window
> a bug in itself.
>

Admittedly. This is another topic though.

>
>> There's no term->close right now, nor is there a term->raiseconsole (and
>> that's fortunate, since raising _gnuplot console_ is not the _plot
>> window_
>> business).
>
> Petr would think otherwise, I'm guessing from his past posts.  There is
> the
>
>      set term x11 close
>
> which could be bound to a key.
>
>
>> Wow, what a long message... Don't hesitate to comment.
>
> No comment on specific terminal implementations, only that it seems easy
> to fix this.

I'll repeat myself, maybe you lost it in the noise of my message: The easy
fix means a big regression; 'q' and ' ' would not always work anymore, but
only when the terminal is the active one.

>
> Dan

Re: q for quit in plot windows

[Daniel J S. <dan...@ie...>]

Timothée Lecomte wrote:
>>The ctrl-c copy was easy enough.  Just replace "c" with "ctrl-c"...
>>
>>Anyway, I see when typing 'h' for a plot to get the key bindings there are
>>these
>>two at the very top (i.e., follow the button description):
>>
>>
>>  Space          raise gnuplot console window
>>  q            * close this X11 plot window
>>
>>[snip]
>>
>>               * indicates this key is active from all plot windows
>>
>>I'm assuming that by the use of term->(function) the mouse/keyboard
>>interface is
>>meant to be very general and not restricted to X11.
> 
> 
> 
> I will try not to repeat what was said by Ethan and Petr, but here are my
> thoughts on this:
> 
> "raise console" and "quit plot window" do not go through the event system
> (because they predate it), they are handled directly by the terminal.
> That's why ' ' and 'q' are keys that you cannot bind to something else,
> with the exception of the 'ctrl-q' option in x11 and wxt.

Right, but the question is why must the documentation for 'q' and ' ' be 
special, sitting out on its own?  Why can't the 'q' and ' ' simply be placed in 
the bindings documentation?

As you explained, the mouse-in-only-one-window limitation came back to me, so 
that is why the asterisk.  Yet, some would consider the mouse-in-only-one-window 
a bug in itself.


> There's no term->close right now, nor is there a term->raiseconsole (and
> that's fortunate, since raising _gnuplot console_ is not the _plot window_
> business).

Petr would think otherwise, I'm guessing from his past posts.  There is the

     set term x11 close

which could be bound to a key.


> Wow, what a long message... Don't hesitate to comment.

No comment on specific terminal implementations, only that it seems easy to fix 
this.

Dan

Re: q for quit in plot windows

[<tim...@en...>]

> The ctrl-c copy was easy enough.  Just replace "c" with "ctrl-c"...
>
> Anyway, I see when typing 'h' for a plot to get the key bindings there are
> these
> two at the very top (i.e., follow the button description):
>
>
>   Space          raise gnuplot console window
>   q            * close this X11 plot window
>
> [snip]
>
>                * indicates this key is active from all plot windows
>
> I'm assuming that by the use of term->(function) the mouse/keyboard
> interface is
> meant to be very general and not restricted to X11.


I will try not to repeat what was said by Ethan and Petr, but here are my
thoughts on this:

"raise console" and "quit plot window" do not go through the event system
(because they predate it), they are handled directly by the terminal.
That's why ' ' and 'q' are keys that you cannot bind to something else,
with the exception of the 'ctrl-q' option in x11 and wxt.

There's no term->close right now, nor is there a term->raiseconsole (and
that's fortunate, since raising _gnuplot console_ is not the _plot window_
business).


> Is that right, i.e., maybe
> it can be used on a different window environment and all the bindings
> behave the
> same.
>
> So, I'm wondering
>
> 1) Why use the word X11 in the documentation?  (Would the user care?)

True, that should be fixed.

>
> 2) Why the footnote that this key is active for all plot windows?  (Aren't
> all
> keys active for all the plot windows?  Or does this mean for all
> window-based
> terminals?)
>

Most keys, like the one for 'replot' only work in the active (i.e. current
terminal) window.

> 3) Why not simply put the 'q' in the regular list of bindings?

You need a term->close to do that. That's not difficult to write, most of
the code is already in place (for 'set term ... close' in particular).

_However_, that way 'q' would not work anymore if wxt (or x11, or any
screen terminal that is concerned by this) is not the current active
terminal.

For example, see the following:
set term wxt
plot x
'q' -> the window is closed
plot x -> the window appears again
set term png
'q' -> nothing happens, because events from wxt are no longer processed

Read further for ideas to workaround this situation.


> If the user applies the -ctrlq option
> the 'q' binding no longer makes sense, but that is still the case the way
> it
> currently is in the documentation. Also, gnuplot shouldn't allow the user
> to
> bind 'q' and 'space'.  If I type
>
>   bind "q" 'print "great"'
>
> the list of bindings shows
>
>   q            * close this X11 plot window
> [snip]
>   q              `print "great"'

Those problems are a result of 'q' not being really handled by the event
system in the first place.

Please note that we already have some of the code to change that situation
right now:

First, there's patch #1474309 to make ' ' be a normal hotkey (writing a
similar patch for 'q' would be even smaller). The only issue before
committing is precisely the one illustrated above: the key doesn't work
anymore if the screen terminal is no longer the active one in the gnuplot
session, because events are only processed from the active terminal.

We understood the issue, and Ethan even wrote a patch for it : it's
#1500654... (read the patch summary, it's exactly the discussion here!)
and he closed the patch himself too...

I have thought about this for quite a long time, here is my conclusion:
We cannot call several term->waitforinput() at the same time, or even
sequentially, because they are all blocking calls, so the approach taken
by Ethan would not work if we want to use _both_ X11 and wxt in the same
session for example. Making term->waitforinput non-blocking means using a
poll with a timeout, and I think it's quite bad to do so (i.e. it means
regular wakeups, which implies among other things high battery usage on a
laptop, see www.linuxpowertop.org).

I see two alternatives to this:
1) Choose one (and only one) so-called 'screen terminal' that would be
privileged and see its events being processed even if it is not the
current one. If wxt is the 'screen terminal', x11 could still be chosen,
but it wouldn't get any interactive behaviour (well, actually it would
partially, since gnuplot_x11 is able to give mouse coordinated without the
core having to say anything)

2) Have a more general event loop system where a terminal could "install"
event sources... for example it is easy to watch for *several*
file-descriptors on unix-like systems _at the same time_, without polling
regularly. In a wxWidgets-on-GTK event loop, these file descriptors would
be:
-stdin, for gnuplot command-line,
-the file descriptor that wxt is using for its connection to the X server,
-the file descriptor for the pipe that the x11 terminal uses to talk to
gnuplot_x11

That way, the event loop could handle the events from both wxt and x11,
and we could make 'q' and ' ' always working, even for an inactive plot
window.

The only drawback of this approach is that it's slightly
platform-specific. On Windows, the loop would most likely wait for
so-called 'messages' instead of file descriptors... and note that this is
already how it works on Windows ! There's no term->waitforinput() there,
only a getc wrapper that actually processes the "messages" and we could
write a patch right now that does #2.

On Unix, we would have to do something like what is done in
x11->waitforinput, where select() is used to wait for stdin _and_ the pipe
at the same time...

Wow, what a long message... Don't hesitate to comment.

Timothée

Re: can not change line of ylabel in "Gnuplot terminal latex"

[Ethan M. <merritt@u.washington.edu>]

On Thursday 31 May 2007 01:50, =E5=AD=99=E5=B4=87=E6=B3=A2 wrote:
>  Hello,
>=20
> When I used  Gnuplot          *set terminal latex*,
> the code         *set ylabel "This is\\the\\$y$ axis"*
> produced a code in the output .tex file   *
> \put(445,21){\makebox(0,0){This
> is\\the\\$y$ axis}}.*
> **
> However, when I pdflatexed the .tex file including the plot file.
> The ylabel was still in the same line, rather than changing lines.
> Could you please tell me the reason?

The text in your \makebox{}  command is processed by LaTeX,
and is formatted according to the current LaTeX environment.
Unless you have created some custom environment, it will
ignore newlines.  Possibly it would accept a \linebreak command,
but I doubt it.

If you want gnuplot to format the text for you, then don't
use the latex terminal.  Instead use the postscript/eps or
the pdf terminal, and include the whole figure (plot + labels)
in the LaTeX document.


=2D-=20
Ethan A Merritt

Re: q for quit in plot windows

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
[snip]
> Except that you can't bypass 'q' or ' ' this way.
> IMHO this is a serious bug or design flaw.

I was feeling the same way when reading the documentation.  Of course, if there 
is no mouse, one would still like x11 term to have its 'q' and ' ', but it 
doesn't seem like it should be difficult to override those or turn them off 
somehow with a simple chararacter string command to gnuplot_x11.

Dan

Re: q for quit in plot windows

[Ethan A M. <merritt@u.washington.edu>]

On Thursday 31 May 2007 00:55, Daniel J Sebald wrote:
> 
> Anyway, I see when typing 'h' for a plot to get the key bindings there are these 
> two at the very top (i.e., follow the button description):
> 
> 
>   Space          raise gnuplot console window
>   q            * close this X11 plot window
> 
> [snip]
> 
>                * indicates this key is active from all plot windows
> 
> 
> 2) Why the footnote that this key is active for all plot windows?  
> (Aren't all keys active for all the plot windows?

No. Only the keys with an asterisk next to the binding.
This is the difference between
     bind <key> "action"
and
     bind allwindows <key> "action"

-- 
Ethan A Merritt

Re: q for quit in plot windows

[Ethan A M. <merritt@u.washington.edu>]

On Thursday 31 May 2007 09:00, Petr Mikulik wrote:
> Well -- is there any possibility to get back the built-in command?
> E.g.
> 	bind a 'plot x'
> 	bind a  builtin-autoscale
> does not work.

You can reset using an empty string:
    bind a ''

You can reset all bindings at once using
    bind!

Neither of these options is well documented.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: q for quit in plot windows

[Petr M. <mi...@ph...>]

> I think it was a design mistake to treat 'q' and ' ' as special-case keys,
> because it seriously interferes with implementing a general hot-key/bind
> interface.

These keys were functioning ages before the bind.

> You can disable 'q' in x11 by shifting the magic key to 'ctrl-q' instead:
>    gnuplot*ctrlq:  on
> 
> But this is awkward, since it needs to be done externally.
> Also it doesn't work for the wxt terminal.
> 
> I would favor getting rid of the 'q' and ' ' hard-wired hotkeys, or
> at least make them default bindings that can be turned off by a script.

Yes, to be changed via 'bind'.
And there could be
	term->set_interactive('hotkey', 'q', 'disable')
	term->set_interactive('hotkey', 'q', 'enable')

Well -- is there any possibility to get back the built-in command?
E.g.
	bind a 'plot x'
	bind a  builtin-autoscale
does not work.

---
PM

Re: q for quit in plot windows

[Ethan A M. <merritt@u.washington.edu>]

On Thursday 31 May 2007 02:24, Petr Mikulik wrote:
> >   q            * close this X11 plot window
> > 
> > I'm assuming that by the use of term->(function) the mouse/keyboard interface is
> > meant to be very general and not restricted to X11.  Is that right, i.e., maybe
> > it can be used on a different window environment and all the bindings behave the
> > 
> > 1) Why use the word X11 in the documentation?  (Would the user care?)
> 
> q hotkey does not work on OS/2 and Windows (= not implemented)
> It works on x11 and wxt.

For some value of "works".
I think it was a design mistake to treat 'q' and ' ' as special-case keys,
because it seriously interferes with implementing a general hot-key/bind
interface.  For instance, suppose you want to allow the user to type in plot
titles interactively (e.g. 'mouselabels.dem').  How do you explain to 
the user that his labels can contain any character except 'q' or ' '?

You can disable 'q' in x11 by shifting the magic key to 'ctrl-q' instead:
   gnuplot*ctrlq:  on

But this is awkward, since it needs to be done externally.
Also it doesn't work for the wxt terminal.

I would favor getting rid of the 'q' and ' ' hard-wired hotkeys, or
at least make them default bindings that can be turned off by a script.

> > 4) How does one change bindings for the current builtin-xxxxxx?
> 
> By the usual bind command.

Except that you can't bypass 'q' or ' ' this way.
IMHO this is a serious bug or design flaw.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: q for quit in plot windows

[Petr M. <mi...@ph...>]

>   q            * close this X11 plot window
> 
> I'm assuming that by the use of term->(function) the mouse/keyboard interface is
> meant to be very general and not restricted to X11.  Is that right, i.e., maybe
> it can be used on a different window environment and all the bindings behave the
> 
> 1) Why use the word X11 in the documentation?  (Would the user care?)

q hotkey does not work on OS/2 and Windows (= not implemented)
It works on x11 and wxt.
On Mac?

Should the message be changed? E.g.
	close this plot window (x11, wxt only)

> 4) How does one change bindings for the current builtin-xxxxxx?

By the usual bind command.

---
PM

can not change line of ylabel in "Gnuplot terminal latex"

[<hi...@gm...>]

 Hello,

When I used  Gnuplot          *set terminal latex*,
the code         *set ylabel "This is\\the\\$y$ axis"*
produced a code in the output .tex file   *
\put(445,21){\makebox(0,0){This
is\\the\\$y$ axis}}.*
**
However, when I pdflatexed the .tex file including the plot file.
The ylabel was still in the same line, rather than changing lines.
Could you please tell me the reason?
Is it a bug?


Thank you!
Todd Sun

q for quit in plot windows

[Daniel J S. <dan...@ie...>]

The ctrl-c copy was easy enough.  Just replace "c" with "ctrl-c"...

Anyway, I see when typing 'h' for a plot to get the key bindings there are these 
two at the very top (i.e., follow the button description):


  Space          raise gnuplot console window
  q            * close this X11 plot window

[snip]

               * indicates this key is active from all plot windows

I'm assuming that by the use of term->(function) the mouse/keyboard interface is
meant to be very general and not restricted to X11.  Is that right, i.e., maybe
it can be used on a different window environment and all the bindings behave the
same.

So, I'm wondering

1) Why use the word X11 in the documentation?  (Would the user care?)

2) Why the footnote that this key is active for all plot windows?  (Aren't all
keys active for all the plot windows?  Or does this mean for all window-based 
terminals?)

3) Why not simply put the 'q' in the regular list of bindings?  It may be that
higher level code doesn't send a GE_keypress code to the mouse do_event() but
instead a GE_reset.  However, if one simply binds the 'q' to a function that all
it does is return 'close plot window' for the documentation, it still makes
sense so long as the higher level code.  If the user applies the -ctrlq option 
the 'q' binding no longer makes sense, but that is still the case the way it 
currently is in the documentation.  Also, gnuplot shouldn't allow the user to 
bind 'q' and 'space'.  If I type

  bind "q" 'print "great"'

the list of bindings shows

  q            * close this X11 plot window
[snip]
  q              `print "great"'

I guess all I'm saying is there doesn't seem to be a need for special 
documenting for these so long as we expect in all GUI terminals that 'q' means 
'close window' and 'space' means 'raise window'.

4) How does one change bindings for the current builtin-xxxxxx?

Re: accumulated patches

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Wednesday 30 May 2007 11:38, Daniel J Sebald wrote:
> 
>>[ gnuplot-Bugs-1534367 ] too much expansion in FindHelp
>>[ gnuplot-Bugs-1525665 ] help has problems with
>>[ gnuplot-Patches-1531560 ] recursive history warning instead of error
> 
> 
> I agree these are relatively high priority.
> They almost went into 4.2, but were held out because bugs
> turned up at the last minute.  IOW they are not quite working yet.
> I would very much like to see them cleaned up, thoroughly tested,
> and added to CVS.
> 
> Please combine them into a single patch set against current source
> and let's give them a workout to shake out any remaining bugs.

Will do.


>>[ gnuplot-Patches-1566782 ] use tgamma for GAMMA() and lgamma for LNGAMMA()
>>
>>I think it is correct, others may not.  It appears to work on Linux and Mac and 
>>I'm fairly confident it won't cause any problems.
> 
> 
> It was never broken on linux, and I believe it is no longer needed
> on OSX either.  So the risk of breaking some minor platform seems larger
> than the benefit to any known system.  Please correct me if I'm wrong.

I'm not familiar with OSX other than that user said it works correctly when it 
was needed at the time.  Have to ask the OSX user who had a problem on this one.


>>[ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conventions
>>
>>Full implementation of mouse/clipboard behavior consistent with the vast
>>majority of X applications.
> 
> 
> ???  Not as seen here.  I have had no problems with the current implementation.
> That doesn't make your fix wrong, but I don't understand what problem is fixing.

It's added features for the most part.  But still I think the existing 
implementation doesn't really place a plot in the X clipboard, and furthermore 
it doesn't properly handle Atom translation.  The existing "clipboard" was a 
hastily constructed version that was made to work for one app and assumed to be 
a full and proper implementation.  The documentation currently states that the 
plot automatically goes into the clipboard.  But try doing a cntrl-V inside 
something like oowriter or your favorite word processor.  Nothing happens. 
There are actually two different entities, clipboard and "selection".  Those 
both have to be handled in the proper X implementation.  There needs to be 
communication about what file formats gnuplot_x11 can provide to the application 
and then gnuplot_x11 has to respond with the proper file format when requested.

The only think is that I didn't know it was possible to interpret cntrl-? keys, 
so 'c' is what puts a plot into the clipboard.  I'll see if I can fix that up to 
the cntrl-c (copy)/cntrl-v (paste) convention.


>>[ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border
> 
> 
> I think this is a non-issue, and we should drop this one entirely.

It's still there.  This originated from Octave computing its axis limits with a 
bit of round off.  Try

set xrange [0:1.99805]
set grid
plot sin(x)
set xrange [0:2]
replot
set xrange [0:1.99805]
replot

and look to the right edge of the plot.  Basically, it addresses this FIXME in 
the code:

/* FIXME HBB 20010121: keeping adding 'step' to 'tic' is
* begging for rounding errors to strike us. */
/* HBB 20010410: ... and strike they did :-( */


>>[ gnuplot-Patches-1027032 ] Connect gnuplot_x11 to exterior application
>>window
>>
>>Works as far as I know.
> 
> 
> Doesn't work here.  I'd like it if it *did* work, but it doesn't.
> My recollection is that it tripped over some contradictory requirements
> for window management by Tk/Tcl, GTK, etc.

I'll have another look and see if there are any problems.


>>[ gnuplot-Patches-1725993 ] Alternate Hidden3d Edge Segmentation
>>[ 1727198 ] Hidden lines: Degenerate polygons creating problems
>>[ gnuplot-Bugs-1728063 ] hidden lines, scale assertion failure
> 
> 
> I'll leave these to Hans-Bernhard, since he's far more familiar
> with the code.  I will comment that gnuplat's hidden-line removal
> plots have very different properties than solid rendering.  When you
> render solids, omitting a facet is just about the worst thing you can do.
> The missing facet is far more jarring than a mis-aligned edge.
> But in the case of gnuplot, it is exactly the mis-aligned edges that
> are noticeable.  We don't care if a facet is dropped.  So although
> I have not delved into the code, I suspect that the most useful fix
> is simply to increase the slop margin, and deliberately omit any
> edges that are in the slop area.

Increasing the slop margin will probably make things worse.  There are two 
issues here that should be kept separate.  The alternate hidden3d issue (i.e., 
the bits and pieces) and the degenerate polygons.

The alternate hidden3d patch doesn't alter the EPSILON setting, and in fact, I 
avoid those EPSILON tests when they have no effect.  (I've noted in the code 
where they don't make a difference.)  Even the existing bug in the CVS code I 
doubt has anything to do with slop margin.  There appears to be a pattern 
whereby what bits and pieces (i.e., edge segments) that are left intersect 
precisely with one of the polygon vertices, but I'm not sure but I've offered a 
patch that works so I'm not inclined to figure it out.

The detailed explanation of the degenerate polygons is that sometimes the 4 
sided polygons turn out to be a triangle (or even share more similar vetices). 
In that case, some of the triangles making up that quadrangle are "degenerate", 
meaning that if v1, v2 and v3 are the triangles vertices, v1=v2 or v2=v3 or 
v3=v1.  But that is an infinitely thin slice and hence has no consequence if it 
is simply discarded.  However, if such a degenerate case is left, the existing 
code will try an create a plane equation describing the plane for such a 
degenerate triangle, but there is no unique, meaningful plane equation for two 
points.  Hence the orientation (probably random) incorrectly chooses the 
direction the plane faces and picks the wrong color for the line.  (The patches 
have some PNG examples attached.)


>>[ gnuplot-Patches-1508316 ] Allow multiple strings to signify "missing"
> 
> 
> Veto.
> There are more reasonable options.
> 1) Clean up your data files
> 2) Run it through general string handling:
>     filter(x) =   (x eq "?") ? NaN : (x eq "junk") ? NaN : x
>     plot "foo" using 1:(filter($2))
> 3) Clean up your data files
> 
> Consider the case where you have multiple data files,
> each with its own idea of what is or is not a missing data flag.
> You want the fix to be per-file, not global.

I'm fine with only one missing symbol.  However, there is still the issue of 
defining exactly how these behave in the code.  I included some demo plots in 
the patch to illustrate behavior for the two classes of points.  I think 
originally behavior was sort of left to the wind.

Dan

Re: accumulated patches

[Petr M. <mi...@ph...>]

> > [ gnuplot-Bugs-1488168 ] z_floor and z_ceiling based on xyplane.absolute 
> > This is an outright bug fix.  Should have gone in 4.2.
> 
> Do you want to take this one Petr?
> You had said earlier you would move it into CVS.

Yes, the patch works fine.

---
PM

Re: accumulated patches

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 30 May 2007 11:38, Daniel J Sebald wrote:
> 
> [ gnuplot-Bugs-1534367 ] too much expansion in FindHelp
> [ gnuplot-Bugs-1525665 ] help has problems with
> [ gnuplot-Patches-1531560 ] recursive history warning instead of error

I agree these are relatively high priority.
They almost went into 4.2, but were held out because bugs
turned up at the last minute.  IOW they are not quite working yet.
I would very much like to see them cleaned up, thoroughly tested,
and added to CVS.

Please combine them into a single patch set against current source
and let's give them a workout to shake out any remaining bugs.

> [ gnuplot-Patches-1566782 ] use tgamma for GAMMA() and lgamma for LNGAMMA()
> 
> I think it is correct, others may not.  It appears to work on Linux and Mac and 
> I'm fairly confident it won't cause any problems.

It was never broken on linux, and I believe it is no longer needed
on OSX either.  So the risk of breaking some minor platform seems larger
than the benefit to any known system.  Please correct me if I'm wrong.

> [ gnuplot-Bugs-1488168 ] z_floor and z_ceiling based on xyplane.absolute 
> This is an outright bug fix.  Should have gone in 4.2.

Do you want to take this one Petr?
You had said earlier you would move it into CVS.
 
> [ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conventions
> 
> Full implementation of mouse/clipboard behavior consistent with the vast
> majority of X applications.

???  Not as seen here.  I have had no problems with the current implementation.
That doesn't make your fix wrong, but I don't understand what problem is fixing.
 
> [ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border

I think this is a non-issue, and we should drop this one entirely.

> [ gnuplot-Patches-1027032 ] Connect gnuplot_x11 to exterior application
> window
> 
> Works as far as I know.

Doesn't work here.  I'd like it if it *did* work, but it doesn't.
My recollection is that it tripped over some contradictory requirements
for window management by Tk/Tcl, GTK, etc.

> [ gnuplot-Patches-1723798 ] Multiplot palette X11, bug [ 1447277 ]
> Allows multiple palettes on a multiplot X11 window, a long desired fix.

Sorry, I haven't had time to look at this one yet.

> [ gnuplot-Patches-1725993 ] Alternate Hidden3d Edge Segmentation
> [ 1727198 ] Hidden lines: Degenerate polygons creating problems
> [ gnuplot-Bugs-1728063 ] hidden lines, scale assertion failure

I'll leave these to Hans-Bernhard, since he's far more familiar
with the code.  I will comment that gnuplat's hidden-line removal
plots have very different properties than solid rendering.  When you
render solids, omitting a facet is just about the worst thing you can do.
The missing facet is far more jarring than a mis-aligned edge.
But in the case of gnuplot, it is exactly the mis-aligned edges that
are noticeable.  We don't care if a facet is dropped.  So although
I have not delved into the code, I suspect that the most useful fix
is simply to increase the slop margin, and deliberately omit any
edges that are in the slop area.  

> [ gnuplot-Patches-1508316 ] Allow multiple strings to signify "missing"

Veto.
There are more reasonable options.
1) Clean up your data files
2) Run it through general string handling:
    filter(x) =   (x eq "?") ? NaN : (x eq "junk") ? NaN : x
    plot "foo" using 1:(filter($2))
3) Clean up your data files

Consider the case where you have multiple data files,
each with its own idea of what is or is not a missing data flag.
You want the fix to be per-file, not global.

-- 
Ethan A Merritt 

accumulated patches

[Daniel J S. <dan...@ie...>]

There are a number of patches on SourceForge ready for consideration in CVS.  If
someone wants to review them they can.  Or, if you want me to move them in, give
me a password (or temporary password if S.F. has such a thing).


[ gnuplot-Bugs-1534367 ] too much expansion in FindHelp
[ gnuplot-Bugs-1525665 ] help has problems with

Fixes issues such as a help line longer than the space reserved in memory for a 
command line.


[ gnuplot-Patches-1566782 ] use tgamma for GAMMA() and lgamma for LNGAMMA()

I think it is correct, others may not.  It appears to work on Linux and Mac and 
I'm fairly confident it won't cause any problems.


[ gnuplot-Bugs-1488168 ] z_floor and z_ceiling based on xyplane.absolute

This is an outright bug fix.  Should have gone in 4.2.


[ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conventions

Full implementation of mouse/clipboard behavior consistent with the vast
majority of X applications.


[ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border

Do something like

if (i_tic == i_end) {
   if (last_tic < end_range)
     draw_tic;
}

instead of

while (first_tic + delta_tic + delta_tic + ... + delta_tic < end_range)
   draw_tic;

The second approach is susceptible to rounding, the first isn't.


[ gnuplot-Patches-1027032 ] Connect gnuplot_x11 to exterior application
window

Works as far as I know.  X11 has an issue whereby two resources both
controlling the mouse in a window will cause an error.  Will X ever change this? 
  I doubt it.  The most I could offer is to somehow check if the outside 
application has relenquished the mouse and if not issue an error.


[ gnuplot-Patches-1531560 ] recursive history warning instead of error

Issue a warning rather than an error so that the rest of the line may be 
executed, e.g.,

gnuplot> history !his; show style;
^
warning: ignoring recursive history command
Data are plotted with points...


[ gnuplot-Patches-1723798 ] Multiplot palette X11, bug [ 1447277 ]

Allows multiple palettes on a multiplot X11 window, a long desired fix.


[ gnuplot-Patches-1725993 ] Alternate Hidden3d Edge Segmentation

Fixes a bug reported on SourceForge.  Very big patch.  No noticable change in 
speed.  If someone wants to fix the bug another way, feel free.


[ 1727198 ] Hidden lines: Degenerate polygons creating problems

Fixes a bug reported on SourceForge.  User reported hidden lines appearing on a 
globe.  The lines were part of the north pole in which four sided polygons were 
degenerate as triangles.  Hence internally triangles with two sides the same 
were the problem spot.  The patch simply tosses out such polygons.


[ gnuplot-Bugs-1728063 ] hidden lines, scale assertion failure

Replace an assertion statement in the QUADTREE version with a simple range 
limit.  Hidden line removal slows down if user pushes surface out past the plot 
view, but that is a minor consequence.  (Better than your program quitting on you.)


[ gnuplot-Patches-1508316 ] Allow multiple strings to signify "missing"

This one isn't ready to go, but we should address this at some point.  An 
interesting side note is that Octave considered storing its stem plot data as a 
series of data for which a "missing" value is used to create a discontinuous 
space.  That is, there is three ways of doing this:

1) Use gnuplot's "stem".
2) Draw a bunch of individual lines with "plot" for each line.
3) Draw a series of data with every third entry "missing" thus leaving the third 
line blank.

Turns out that 3 sort of fits the way Octave stores data.


Dan

Re: Simple question

[Juergen W. <wie...@fr...>]

> gnuplot> system "date"; load 'mixture.gp'; system "date"
> Wed May 30 01:48:13 CDT 2007
>                                             ^
>           warning: ignoring rest of line
>
> Simple answer?

The load command discards the complete buffer of the current command
line to process the first line of the load file.  After the file has
been processed, the rest of the original line is not restored
because noone has bothered to implement this.

Juergen