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

Re: q for quit in plot windows

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

On Friday 01 June 2007 10:23, Daniel J Sebald wrote:
> > But the "raise console" mechanism doesn't operate via key bindings.
> > That's the whole point of this discussion.
> 
> I thought you were proposing to make close and raise part of key bindings, not 
> get rid of the actions.

I want to get rid of them altogether. 
Petr wants to keep the "raise" action, but it is not clear what 
it would be triggered by.
 
> > Switching it to use key bindings would be a major change,
> 
> Why?  I thought the difficult part was handling all events from all terminals at 
> the same time.  (And it is, I looked at the code and saw some global term-> 
> pointer and that's as far as I want to look.)

I have tried to explain this about 4 times now.
I give up.

-- 
Ethan A Merritt

Re: q for quit in plot windows

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

Ethan Merritt wrote:
> On Friday 01 June 2007 09:54, you wrote:
> 
>>This is why I asked how to re-assign the bindings of internal built-ins.  If 
>>that possible, then Petr (or anyone) can simply put the redifinition in his 
>>gnuplot initialization file.
> 
> 
> But the "raise console" mechanism doesn't operate via key bindings.
> That's the whole point of this discussion.

I thought you were proposing to make close and raise part of key bindings, not 
get rid of the actions.


> Switching it to use key bindings would be a major change,

Why?  I thought the difficult part was handling all events from all terminals at 
the same time.  (And it is, I looked at the code and saw some global term-> 
pointer and that's as far as I want to look.)


> and I
> suspect would not be acceptable to Petr for all the reasons we've
> already gone over with regard to "current terminal".

That would be the current limitation to deal with.  But that might not be all 
that bad.  If one has switched away from x11, s/he is at the gnuplot prompt 
already.  They type the commands to send the plot to a file, then type "set term 
x11" to get back to x11 mode.

Dan

Re: q for quit in plot windows

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

On Friday 01 June 2007 10:04, Timoth=E9e Lecomte wrote:
> Why not 'ctrl-i' ? Sounds like 'interactive' or 'interface', and if I
> recall correctly it's the key to be pressed to edit in vim.

ctrl-i is the <tab> key, and is a normal thing to type in a text
string.  Remember that ctrl-a through ctrl-z are all normal ASCII
single-byte characters, and have a long history of specific use.

We should not re-invent key mappings, since so many people are
used to a particular set of mappings.  I think it safer to have
no default at all, and require the user to explicitly choose a
hotkey if he wants one.


=2D-=20
Ethan A Merritt

Re: q for quit in plot windows

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

> On Friday 01 June 2007 09:18, Timothée Lecomte wrote:
>> >
>> > But why the <space> character?????
>> > Can't this function, if it's necessary at all, be bound to something
>> that
>> > you don't need for typing ordinary commands or labels?
>>
>> Hey, interesting point here: the default bindings could all be
>> 'ctrl'+'key' instead of just 'key'. That's easy to do and we could at
>> least get rid of this "ctrlq" option.
>
> ctrl+space is the default hotkey to switch between input modes
> on a multi-language desktop using uim/scim/skim etc.
> On my machines it toggles between English and Japanese character
> input. I think it would be unexpected to find yourself typing in a
> different language as a result of trying to raise the gnuplot
> console :-)
>
> So in principle I am OK with simply choosing a different
> "raise console" key sequence. But ctrl-<space> is not an option.

g (gnuplot), r (raise), c (console) cannot be chosen (grid, ruler,
clipboard).

I was going to suggest ctrl-w, but it would actually be more appropriate
as an equivalent for ctrl-q since it usually closes the tab in a browser
or the file (just tried and lost my message in firefox ;).

Why not 'ctrl-i' ? Sounds like 'interactive' or 'interface', and if I
recall correctly it's the key to be pressed to edit in vim.

Timothée

Re: q for quit in plot windows

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

Ethan Merritt wrote:
> On Friday 01 June 2007 09:18, Timothée Lecomte wrote:
> 
>>>But why the <space> character?????
>>>Can't this function, if it's necessary at all, be bound to something that
>>>you don't need for typing ordinary commands or labels?
>>
>> 
>>Hey, interesting point here: the default bindings could all be
>>'ctrl'+'key' instead of just 'key'. That's easy to do and we could at
>>least get rid of this "ctrlq" option.
> 
> 
> ctrl+space is the default hotkey to switch between input modes
> on a multi-language desktop using uim/scim/skim etc.
> On my machines it toggles between English and Japanese character
> input. I think it would be unexpected to find yourself typing in a
> different language as a result of trying to raise the gnuplot
> console :-)
> 
> So in principle I am OK with simply choosing a different 
> "raise console" key sequence. But ctrl-<space> is not an option.

This is why I asked how to re-assign the bindings of internal built-ins.  If 
that possible, then Petr (or anyone) can simply put the redifinition in his 
gnuplot initialization file.

Dan

Re: q for quit in plot windows

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

On Friday 01 June 2007 09:18, Timoth=E9e Lecomte wrote:
> >
> > But why the <space> character?????
> > Can't this function, if it's necessary at all, be bound to something th=
at
> > you don't need for typing ordinary commands or labels?
> =20
> Hey, interesting point here: the default bindings could all be
> 'ctrl'+'key' instead of just 'key'. That's easy to do and we could at
> least get rid of this "ctrlq" option.

ctrl+space is the default hotkey to switch between input modes
on a multi-language desktop using uim/scim/skim etc.
On my machines it toggles between English and Japanese character
input. I think it would be unexpected to find yourself typing in a
different language as a result of trying to raise the gnuplot
console :-)

So in principle I am OK with simply choosing a different=20
"raise console" key sequence. But ctrl-<space> is not an option.

=2D-=20
Ethan A Merritt

Re: q for quit in plot windows

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

>> > I have a much simpler proposal.
>> > Let's get rid of the 'q' and ' ' built-ins altogether.
>> >
>> > Any usable window manager provides at least one button and/or hotkey
>> > to kill windows, and the local user is familiar with the conventions
>> > of his own desktop.  Why should we duplicate, badly, what is already
>> > present?
>>
>> Windows can be closed by Alt-F4.
>
> Exactly.  So there is no need for a badly-implemented 'q'.
>
>> I'm strictly against smashing ' '. It's the most useful hotkey! It does
>> much
>> more than a window manager can offer (it finds the parent terminal,
>> which
>> may be a gnuplot session, octave session, etc.!).
>
> But why the <space> character?????
> Can't this function, if it's necessary at all, be bound to something that
> you don't need for typing ordinary commands or labels?


Hey, interesting point here: the default bindings could all be
'ctrl'+'key' instead of just 'key'. That's easy to do and we could at
least get rid of this "ctrlq" option.

Timothée

Re: q for quit in plot windows

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

> > No, my proposal allows to (re)bind 'q' during gnuplot running.
> 
> So does the existing ctrlq mechanism.

> > Windows can be closed by Alt-F4.
> Exactly.  So there is no need for a badly-implemented 'q'.

Oh, I see it even works as "set term x11 ctrlq". Sorry I haven't discovered 
this earlier.

Anyway, 'q' is x11-specific, not available on other terminals (win, pm), 
just wxt is copying this behaiour. I would agree to remove this default 
binding.

> > > Let's get rid of the 'q' and ' ' built-ins altogether.
> > > 
> > I'm strictly against smashing ' '. It's the most useful hotkey! It does much 
> > more than a window manager can offer (it finds the parent terminal, which 
> > may be a gnuplot session, octave session, etc.!).
> 
> But why the <space> character?????
> Can't this function, if it's necessary at all, be bound to something that
> you don't need for typing ordinary commands or labels?

It is the most natural & easy thing to hit the space bar ... it seemed to me 
in 1998 when I implemented it, and still it seems.

I never needed to use <space> for anything else.

I would agree to allow rebinding <space>.


BTW, would something like
	A=bind a
	bind a plot x
	bind a @A	# restore previous binding
be possible? (But I wonder whether it has some sense.)

---
PM

Re: q for quit in plot windows

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

On Friday 01 June 2007 08:41, you wrote:
> > > > 1) It already exists in the form of the ctrl-q option in x11 and wxt
> > > > 2) This is doomed to be completely opaque to the user, as is the cu=
rrent
> > > > ctrl-q solution in my opinion
> > >=20
> > > My proposal is different from ctrl-q. It describes the inner way of=20
> > > gnuplot code, not a user interface/option. This must be hidden from t=
he=20
> > > user; user does not care about the implementation of built-in binding=
s.
> >=20
> > Timoth=C3=A9e's point is that the ctrl-q mechanism already implements y=
our
> > on/off proposal. So far as I understand what you are proposing, there
> > would be no difference between your "off" state and the current=20
> > "ctrlq" state (except, of course, what happens if you type ctrl-q :-)
>=20
> No, my proposal allows to (re)bind 'q' during gnuplot running.

So does the existing ctrlq mechanism.

> > I have a much simpler proposal.
> > Let's get rid of the 'q' and ' ' built-ins altogether.
> >=20
> > Any usable window manager provides at least one button and/or hotkey
> > to kill windows, and the local user is familiar with the conventions
> > of his own desktop.  Why should we duplicate, badly, what is already
> > present?=20
>=20
> Windows can be closed by Alt-F4.

Exactly.  So there is no need for a badly-implemented 'q'.

> I'm strictly against smashing ' '. It's the most useful hotkey! It does m=
uch=20
> more than a window manager can offer (it finds the parent terminal, which=
=20
> may be a gnuplot session, octave session, etc.!).

But why the <space> character?????
Can't this function, if it's necessary at all, be bound to something that
you don't need for typing ordinary commands or labels?


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: q for quit in plot windows

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

> > > 1) It already exists in the form of the ctrl-q option in x11 and wxt
> > > 2) This is doomed to be completely opaque to the user, as is the curr=
ent
> > > ctrl-q solution in my opinion
> >=20
> > My proposal is different from ctrl-q. It describes the inner way of=20
> > gnuplot code, not a user interface/option. This must be hidden from the=
=20
> > user; user does not care about the implementation of built-in bindings.
>=20
> Timoth=C3=A9e's point is that the ctrl-q mechanism already implements you=
r
> on/off proposal. So far as I understand what you are proposing, there
> would be no difference between your "off" state and the current=20
> "ctrlq" state (except, of course, what happens if you type ctrl-q :-)

No, my proposal allows to (re)bind 'q' during gnuplot running.


> I have a much simpler proposal.
> Let's get rid of the 'q' and ' ' built-ins altogether.
>=20
> Any usable window manager provides at least one button and/or hotkey
> to kill windows, and the local user is familiar with the conventions
> of his own desktop.  Why should we duplicate, badly, what is already
> present?=20

Windows can be closed by Alt-F4.

I'm strictly against smashing ' '. It's the most useful hotkey! It does muc=
h=20
more than a window manager can offer (it finds the parent terminal, which=
=20
may be a gnuplot session, octave session, etc.!).

---
PM

Re: q for quit in plot windows

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

On Friday 01 June 2007 07:15, Petr Mikulik wrote:
> >=20
> > 1) It already exists in the form of the ctrl-q option in x11 and wxt
> > 2) This is doomed to be completely opaque to the user, as is the current
> > ctrl-q solution in my opinion
>=20
> My proposal is different from ctrl-q. It describes the inner way of=20
> gnuplot code, not a user interface/option. This must be hidden from the=20
> user; user does not care about the implementation of built-in bindings.

Timoth=E9e's point is that the ctrl-q mechanism already implements your
on/off proposal.  So far as I understand what you are proposing, there
would be no difference between your "off" state and the current=20
"ctrlq" state (except, of course, what happens if you type ctrl-q :-)


I have a much simpler proposal.
Let's get rid of the 'q' and ' ' built-ins altogether.

Any usable window manager provides at least one button and/or hotkey
to kill windows, and the local user is familiar with the conventions
of his own desktop.  Why should we duplicate, badly, what is already
present?=20

If you want to bind 'q' to "set term x11 close MOUSE_KEY_WINDOW",
do that as a user binding.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: q for quit in plot windows

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

> >>> '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.
> >>
> >>> Then you mean that "bind" command should work always to all screen
> >>> terminals. Then it seems to be even more easily coded:
> >>
> >> There is a problem with moving ' ' or 'q' into the general "bind"
> >> mechanism, and the same problem applies to extending "bind all"
> >> to handle multiple active terminal types.
> >
> > I proposed this bind mechanism for the 2 hotkeys:
> > - on -- the current built-in: gnuplot_x11 or gnupmdrv.exe etc. execute the
> >   'q' and ' '
> > - off -- planned: these hotkeys will be passed from gnuplot_x11 etc into
> >   gnuplot as all the other keys
> >
> 
> I doubt it's the right fix:
> 
> 1) It already exists in the form of the ctrl-q option in x11 and wxt
> 2) This is doomed to be completely opaque to the user, as is the current
> ctrl-q solution in my opinion

My proposal is different from ctrl-q. It describes the inner way of 
gnuplot code, not a user interface/option. This must be hidden from the 
user; user does not care about the implementation of built-in bindings.

> 3) It doesn't really fix the problem (again, this problem is that we
> cannot listen to events coming from different terminals at the same time
> in the current design), but only workaround it with a new option...

I comment only on how to enable / disable ' ' and 'q' for binding, not what 
happens after a 'set term'.

---
PM

Re: q for quit in plot windows

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

>>> '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.
>>
>>> Then you mean that "bind" command should work always to all screen
>>> terminals. Then it seems to be even more easily coded:
>>
>> There is a problem with moving ' ' or 'q' into the general "bind"
>> mechanism, and the same problem applies to extending "bind all"
>> to handle multiple active terminal types.
>
> I proposed this bind mechanism for the 2 hotkeys:
> - on -- the current built-in: gnuplot_x11 or gnupmdrv.exe etc. execute the
>   'q' and ' '
> - off -- planned: these hotkeys will be passed from gnuplot_x11 etc into
>   gnuplot as all the other keys
>

I doubt it's the right fix:

1) It already exists in the form of the ctrl-q option in x11 and wxt
2) This is doomed to be completely opaque to the user, as is the current
ctrl-q solution in my opinion
3) It doesn't really fix the problem (again, this problem is that we
cannot listen to events coming from different terminals at the same time
in the current design), but only workaround it with a new option...


>
>> How much would it take to make gnuplot look for events from all
>> terminals
>> it has accessed?  If gnuplot initializes a terminal, it can put that
>> pointer on a linked list (could use dynarray).  Then go through the list
>> looking for events.
>>  Or is there more to switching terminals in that regard?
>
> This "listen all the time" works on OS/2 (thread + shared memory is used,
> not waitforinput), but if pm is not the current terminal, then the
> commands
> like grid, log etc. are replotted for the other selected terminal.
>

Yes, we need to extend and unify _cleanly_ this "listen all the time"
behaviour between all platforms and several terminals at a time, and nuke
term->waitforinput

Timothée

Re: q for quit in plot windows

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

>> '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.
> 
>> Then you mean that "bind" command should work always to all screen 
>> terminals. Then it seems to be even more easily coded:
>
> There is a problem with moving ' ' or 'q' into the general "bind"
> mechanism, and the same problem applies to extending "bind all"
> to handle multiple active terminal types.

I proposed this bind mechanism for the 2 hotkeys:
- on -- the current built-in: gnuplot_x11 or gnupmdrv.exe etc. execute the 
  'q' and ' '
- off -- planned: these hotkeys will be passed from gnuplot_x11 etc into 
  gnuplot as all the other keys


> How much would it take to make gnuplot look for events from all terminals 
> it has accessed?  If gnuplot initializes a terminal, it can put that 
> pointer on a linked list (could use dynarray).  Then go through the list 
> looking for events.
>  Or is there more to switching terminals in that regard?

This "listen all the time" works on OS/2 (thread + shared memory is used, 
not waitforinput), but if pm is not the current terminal, then the commands 
like grid, log etc. are replotted for the other selected terminal.

---
PM

Version 4.0&4.2 ---terminal PDF, JPEG not be accessible in WinXP environment

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

Hello,

When I set that two terminals, it showed:

*gnuplot> set term jpeg
                  ^
         unknown or ambiguous terminal type; type just 'set terminal' for a
list*
**
*gnuplot> set term pdf
                  ^
         unknown or ambiguous terminal type; type just 'set terminal' for a
list*
**
and I typed *set term:*
there are no Jpeg and pdf in the*  Available terminal types.*
**
Is there something I need to install to access these two terminals?
I have tried both version 4.0 and 4.2, same problem.

Thanks!
Todd Sun
**
**

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

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

On Thursday 31 May 2007 18:03, Mojca Miklavec wrote:

> > The primary drawback is the difficulty of 
> > getting the escape sequences right for the LaTeX mark-up inside
> > double quotes.
> 
> That's not only difficult, but almost impossible for a general case.

I won't argue the point, at least if you're doing it by hand :-)

But perhaps it would be worth automating?

-- 
Ethan A Merritt

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

[Mojca M. <moj...@gm...>]

On 6/1/07, Ethan Merritt wrote:
> On Thursday 31 May 2007 17:43, Mojca Miklavec wrote:
> > On 6/1/07, Ethan Merritt wrote:
> > > But to show that it works in principle, try the following:
> > >
> > > set term latex
> > > set output 'test.tex'
> > > set title "One line\nTwo lines\nThree lines"
> > > plot x
> >
> > No, I didn't have that in mind. That's nonsense, since TeX ignores
> > newlines anyway (and considers them equal to spaces).
>
> Did you actually try it?

I'm sorry. I always thought that gnuplot was passing the contents
literally to LaTeX. Now I did - and I must admit that I never noticed
that trick.

> Gnuplot itself interprets the newlines, and splits the label up
> into three parts fed individually to the latex driver.
> It works reasonably well, actually. It's only the line spacing
> that is imperfect.  The primary drawback is the difficulty of
> getting the escape sequences right for the LaTeX mark-up inside
> double quotes.

That's not only difficult, but almost impossible for a general case.

Mojca

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

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

On Thursday 31 May 2007 17:43, Mojca Miklavec wrote:
> On 6/1/07, Ethan Merritt wrote:
> > But to show that it works in principle, try the following:
> >
> > set term latex
> > set output 'test.tex'
> > set title "One line\nTwo lines\nThree lines"
> > plot x
> 
> No, I didn't have that in mind. That's nonsense, since TeX ignores
> newlines anyway (and considers them equal to spaces).

Did you actually try it?
Gnuplot itself interprets the newlines, and splits the label up
into three parts fed individually to the latex driver.
It works reasonably well, actually. It's only the line spacing
that is imperfect.  The primary drawback is the difficulty of
getting the escape sequences right for the LaTeX mark-up inside
double quotes.


> It's obvious 
> that in LaTeX one is ready to put extra effort into labels by placing
> extra markup, so one might want to use '\\' for newlines, but that
> doesn't work inside \hbox (I assume that \makebox is only an hbox).

Yes.  \newline  doesn't work either.

> What gnuplot could do is to create such output that '\\' would work
> out of the box (by replacing \makebox with something that accepts and
> respects '\\' as a newline).
> 
> I would need to dig out the proper syntax though, since I abandoned
> LaTeX some years ago.
> 
> Mojca
> 

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

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

[Mojca M. <moj...@gm...>]

On 6/1/07, Ethan Merritt wrote:
> But to show that it works in principle, try the following:
>
> set term latex
> set output 'test.tex'
> set title "One line\nTwo lines\nThree lines"
> plot x

No, I didn't have that in mind. That's nonsense, since TeX ignores
newlines anyway (and considers them equal to spaces). It's obvious
that in LaTeX one is ready to put extra effort into labels by placing
extra markup, so one might want to use '\\' for newlines, but that
doesn't work inside \hbox (I assume that \makebox is only an hbox).

What gnuplot could do is to create such output that '\\' would work
out of the box (by replacing \makebox with something that accepts and
respects '\\' as a newline).

I would need to dig out the proper syntax though, since I abandoned
LaTeX some years ago.

Mojca

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

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

On Thursday 31 May 2007 17:22, Mojca Miklavec wrote:
> This is a possible ugly plain TeX solution which works:
> 
> set ylabel '\vbox{\hbox{This is}\hbox{the}\hbox{$y$ axis}}'
> 
> If you want a cleaner solution, try to figure out on some LaTeX
> mailing list how to convince \makebox to obey the newline character.
> It's a purely LaTeX problem, although if I'm honest, the LaTeX
> terminal in gnuplot could (should?) be modified in such a way that \\
> would be obeyed out of the box.


Well, gnuplot will break it into multiple lines for you if
you enclose it in double quotes rather than single quotes,
but that makes passing through the TeX syntactic elements
a difficult task.  Also the text layout is now an imperfect
blending of gnuplot's guess at what the font will look like
and LaTeX's rather better guess.

But to show that it works in principle, try the following:

set term latex
set output 'test.tex'
set title "One line\nTwo lines\nThree lines"
plot x 

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

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

[Mojca M. <moj...@gm...>]

T24gNS8zMS8wNywgy++z57KoIDxoaXRzY2JAZ21haWwuY29tPiB3cm90ZToKPgo+IEhlbGxvLAo+
Cj4gV2hlbiBJIHVzZWQgIEdudXBsb3QgICAgICAgICAgc2V0IHRlcm1pbmFsIGxhdGV4LAo+IHRo
ZSBjb2RlICAgICAgICAgc2V0IHlsYWJlbCAiVGhpcyBpc1xcdGhlXFwkeSQgYXhpcyIKPiBwcm9k
dWNlZCBhIGNvZGUgaW4gdGhlIG91dHB1dCAudGV4IGZpbGUKPiBccHV0KDQ0NSwyMSl7XG1ha2Vi
b3goMCwwKXtUaGlzIGlzXFx0aGVcXCR5JCBheGlzfX0uCgpUaGlzIGlzIGEgcG9zc2libGUgdWds
eSBwbGFpbiBUZVggc29sdXRpb24gd2hpY2ggd29ya3M6CgpzZXQgeWxhYmVsICdcdmJveHtcaGJv
eHtUaGlzIGlzfVxoYm94e3RoZX1caGJveHskeSQgYXhpc319JwoKSWYgeW91IHdhbnQgYSBjbGVh
bmVyIHNvbHV0aW9uLCB0cnkgdG8gZmlndXJlIG91dCBvbiBzb21lIExhVGVYCm1haWxpbmcgbGlz
dCBob3cgdG8gY29udmluY2UgXG1ha2Vib3ggdG8gb2JleSB0aGUgbmV3bGluZSBjaGFyYWN0ZXIu
Ckl0J3MgYSBwdXJlbHkgTGFUZVggcHJvYmxlbSwgYWx0aG91Z2ggaWYgSSdtIGhvbmVzdCwgdGhl
IExhVGVYCnRlcm1pbmFsIGluIGdudXBsb3QgY291bGQgKHNob3VsZD8pIGJlIG1vZGlmaWVkIGlu
IHN1Y2ggYSB3YXkgdGhhdCBcXAp3b3VsZCBiZSBvYmV5ZWQgb3V0IG9mIHRoZSBib3guCgo+IEhv
d2V2ZXIsIHdoZW4gSSBwZGZsYXRleGVkIHRoZSAudGV4IGZpbGUgaW5jbHVkaW5nIHRoZSBwbG90
IGZpbGUuCj4gVGhlIHlsYWJlbCB3YXMgc3RpbGwgaW4gdGhlIHNhbWUgbGluZSwgcmF0aGVyIHRo
YW4gY2hhbmdpbmcgbGluZXMuCj4gQ291bGQgeW91IHBsZWFzZSB0ZWxsIG1lIHRoZSByZWFzb24/
Cj4gSXMgaXQgYSBidWc/CgpJIGRvbid0IGNvbnNpZGVyIGl0IGJlaW5nIGEgYnVnIC0gaXQgaGFz
IHRvIGJlIGRvbmUgaW4gTGFUZVgsIG5vdCBpbgpnbnVwbG90LCBhbHRob3VnaCBpdCB3b3VsZCBi
ZSBuaWNlIGlmIGRvY3VtZW50YXRpb24gd291bGQgbWVudGlvbiBob3cKdG8gZG8gdGhhdCAtIGl0
J3MgcXVpdGUgcG9zc2libGUgdGhhdCBtb3JlIHBlb3BsZSByZXF1aXJlIGl0LgoKCgoKT24gNS8z
MS8wNywgRXRoYW4gTWVycml0dCB3cm90ZToKPgo+IElmIHlvdSB3YW50IGdudXBsb3QgdG8gZm9y
bWF0IHRoZSB0ZXh0IGZvciB5b3UsIHRoZW4gZG9uJ3QKPiB1c2UgdGhlIGxhdGV4IHRlcm1pbmFs
LiAgSW5zdGVhZCB1c2UgdGhlIHBvc3RzY3JpcHQvZXBzIG9yCj4gdGhlIHBkZiB0ZXJtaW5hbCwg
YW5kIGluY2x1ZGUgdGhlIHdob2xlIGZpZ3VyZSAocGxvdCArIGxhYmVscykKPiBpbiB0aGUgTGFU
ZVggZG9jdW1lbnQuCgpJIGRvbid0IHNheSB0aGF0IHRoZSBMYVRlWCB0ZXJtaW5hbCBpcyB0aGUg
YmVzdCBvbmUgZXhpc3RpbmcgKHRoZQpncmFwaGljcyBhcmUgcmVhbGx5IGhvcnJpYmxlIGluIGNv
bXBhcmlzb24gdG8gb3RoZXIgdGVybWluYWxzKSwgYnV0CkkndmUgYmVlbiB1c2luZyBpdCBmb3Ig
dHdvIHllYXJzIChhbmQgd3JvdGUgYSBuZXcgb25lIHdoZW4gSSBzdG9wcGVkCnVzaW5nIExhVGVY
KSwgYW5kIEkgbGlrZShkKSB0aGUgZmFjdCB0aGF0IGl0J3MgcmVhbGx5IGVhc3kgdG8ga2V5IGlu
CnNvbWUgbWF0aCBleHByZXNzaW9ucywgYW5kIHRvIHVzZSB0aGUgc2FtZSBmb250IGFzIGluIHRo
ZSB3aG9sZQpkb2N1bWVudC4gQW5kIEkga25vdyBtYW55IG1vcmUgcGVvcGxlIHdobyBmZWVsIHRo
ZSBzYW1lLiBUaGF0J3MKc29tZXRoaW5nIHRoYXQgcG9zdHNjcmlwdC9wZGYvZ2QgdGVybWluYWxz
IGFyZSBzaW1wbHkgbGFja2luZywgbm8KbWF0dGVyIGhvdyB5b3UgcHV0IGl0IC4uLgoKTW9qY2EK

Re: q for quit in plot windows

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

On Thursday 31 May 2007 15:32, Daniel J Sebald wrote:
> 
> How much would it take to make gnuplot look for events from all terminals it has 
> accessed?

A complete re-write of the input stream multiplexing.


-- 
Ethan A Merritt

Re: q for quit in plot windows

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

Ethan Merritt wrote:

> Yes. That's what it is intended to do, and it works fine.
> Now type
> 
>    set term png
> 
> and you will see that everything stops working.

How much would it take to make gnuplot look for events from all terminals it has 
accessed?  If gnuplot initializes a terminal, it can put that pointer on a 
linked list (could use dynarray).  Then go through the list looking for events. 
  Or is there more to switching terminals in that regard?

Dan

Re: q for quit in plot windows

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

On Thursday 31 May 2007 14:17, Petr Mikulik wrote:
> >=20
> > It is not as simple as you make it sound.
> > Consider the example Timoth=C3=A9e already mentioned.
> > You have an old x11 plot window open, but the current terminal
> > is something else.  Maybe wxt, maybe postscript, ... whatever.
>=20
> Then you mean that "bind" command should work always to all screen=20
> terminals. Then it seems to be even more easily coded:

I apologize for not explaining clearly enough.
I will try once more.

There is a problem with moving ' ' or 'q' into the general "bind"
mechanism, and the same problem applies to extending "bind all"
to handle multiple active terminal types.

The problem is not anything to do with handling the event once we see it.
The existing code, or trivial extensions, can handle that easily.

The problem is that _we do not see_ the keystroke or mouse events
from previously active terminals.  Only those from the current terminal.


=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.
> >=20
> > 'q' and ' ' should work as they are. It is sufficient and a very clean =
way=20
> > to switch them on/off by a term->xxxx() command I proposed earlier.
>=20
> It is not as simple as you make it sound.
> Consider the example Timoth=C3=A9e already mentioned.
> You have an old x11 plot window open, but the current terminal
> is something else.  Maybe wxt, maybe postscript, ... whatever.

Then you mean that "bind" command should work always to all screen=20
terminals. Then it seems to be even more easily coded:

for t in "all terminals"
  if t is interactive
=09t->xxxx()

of even the hardcoded way (like managing menus, pauses etc.) (but many won'=
t=20
like it):

#if X11
x11_change_hotkey('q', 0);
#if PM
pm_change_hotkey('q', 0);
#if _Windows
#if wxt

---
PM