gnuplot-beta

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...>]

> > > 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 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...>]

> > 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

[<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

[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

[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

[<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

[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 10:04, Timothée 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.
>

Oh, ok. I now understand why so many apps use a key plus two modifiers for
their bindings.


> 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.
>

Agreed.

Re: q for quit in plot windows

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

> > 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.
> 
> 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.

No, let us keep the <space> hotkey, and if somebody does not find it 
convenient, he can rebind it. There was no complain or report on this issue 
from any user.

> Petr wants to keep the "raise" action, but it is not clear what
> it would be triggered by.

As it works currently.

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

I agree. Let it as is now.


***

I have noticed a recent release of octave 2.9.12. Could we get the "replot" 
for inlined files working? This feature will be very welcome.


---
PM

Re: q for quit in plot windows

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

On Friday 01 June 2007 10:39, Petr Mikulik wrote:
> 
> No, let us keep the <space> hotkey, and if somebody does not find it 
> convenient, he can rebind it. There was no complain or report on this issue 
> from any user.

This is just wrong. You cannot rebind it.

As I keep trying to point out, the current implementation of
'q' and ' ' bypasses the "bind" mechanism altogether, and cannot be
changed by the user.  This is bad. 

And people *do* complain. My work-around was to introduce the -ctrlq
option, which returns both ' ' and 'q' to being processed like any 
other key.  This is what you proposed with your "on/off" idea, right?
Let's make *that* the default.  No special treatment for the 'q' and
' ' keys unless the user specifically requests it.  There are several
patchsets on SourceForge exploring how the "raise console" operation
could be made a user option.


-- 
Ethan A Merritt

Re: q for quit in plot windows

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

Ethan Merritt wrote:
> On Friday 01 June 2007 10:39, Petr Mikulik wrote:
> 
>>No, let us keep the <space> hotkey, and if somebody does not find it 
>>convenient, he can rebind it. There was no complain or report on this issue 
>>from any user.
> 
> 
> This is just wrong. You cannot rebind it.
> 
> As I keep trying to point out, the current implementation of
> 'q' and ' ' bypasses the "bind" mechanism altogether, and cannot be
> changed by the user.  This is bad. 
> 
> And people *do* complain. My work-around was to introduce the -ctrlq
> option, which returns both ' ' and 'q' to being processed like any 
> other key.

This is what I have in mind.

   This is what you proposed with your "on/off" idea, right?
> Let's make *that* the default.  No special treatment for the 'q' and
> ' ' keys unless the user specifically requests it.

Not even user specified.  If gnuplot launches with a working mouse, simply send 
a code (as yet not implemented) to gnuplot_x11 to indicate it shouldn't handle 
any keys itself, but pass them all on.  It's a legacy thing; if there's no 
mouse, you'd still have the 'q' and ' ' to fall back on.  The on/off isn't for 
the user.

   There are several
> patchsets on SourceForge exploring how the "raise console" operation
> could be made a user option.

If one goes that route, then all that need be done is bind ' ' to the raise 
console command.  I'd even like it if the command line window didn't lose focus 
when a new plot comes up.  (That'd be a gnuplot_x11 thing I guess.)

Dan

Quick refresh [was: q for quit in plot windows]

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

On Friday 01 June 2007 10:39, Petr Mikulik wrote:
> I have noticed a recent release of octave 2.9.12. 
> Could we get the "replot" for inlined files working? 
> This feature will be very welcome. 

I continue to chip away at the pieces that are not working yet.
Known issues:

  - refresh of "with image" styles produces garbage
    So far I can't figure out why.
    Daniel, maybe you can see what I'm overlooking?

  - The default key bindings must be examined one by one and
    re-written to choose between "refresh" and "replot" as
    appropriate.

  - Doesn't yet handle splot. In particular, it doesn't
    handle zooming the 2D plots produced by "set view map; splot..."

  - General lack of testing.  It is highly likely that there
    are cases that are not handled properly; I just haven't noticed
    them yet.

More testers, and more eyes trying to debug the image code
would help speed things up.

-- 
Ethan A Merritt

Re: Quick refresh [was: q for quit in plot windows]

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

 >   - refresh of "with image" styles produces garbage
 >     So far I can't figure out why.
 >     Daniel, maybe you can see what I'm overlooking?

I'll look when I get the chance.  Will be gone this weekend.

Re: Quick refresh [was: q for quit in plot windows]

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

Daniel J Sebald wrote:
>  >   - refresh of "with image" styles produces garbage
>  >     So far I can't figure out why.
>  >     Daniel, maybe you can see what I'm overlooking?
> 
> I'll look when I get the chance.  Will be gone this weekend.

I'm going through the image.dem and image2.dem examples and data seems to be 
reloaded correctly.  The only thing I've seen so far is:

set title "Convex     November 1-7 1989    Circadian"
set key left box
set xrange[-1:24]
plot 'using.bin' binary format='%*int32%int8%*int16%int8%*int16%*int16' using 
1:2 title "Logged in" with impulses,\
      'using.bin' binary format='%*int32%int8%*int16%int8%*int16%*int16' using 
1:2 title "Logged in" with points

will "replot" looking exactly the same, but will "refresh" with the y scale as 
0,10,20,30,40,50 rather than 0,5,10,15,20,25,30,35,40,45,50.

Same is true of the example following it.


There is another example in image2 that acts funny, but I don't think it has 
anything to do with images.  Try the following

plot x
set xrange [10:-10]
replot
refresh

and I see that the range goes back to its original orientation.  (Perhaps this 
is the same issue as the previous noted problem.)


I've also seen a bug or ILOTWIO with multiplot.  Try the following

plot x; pause -1

And the plot appears, then there is a pause.  However, try the following

set multiplot layout 2,1
plot x; pause -1

and the plot doesn't appear until after the user breaks out of the pause.

Dan

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: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 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.

There are all these entries in the term table

#ifdef USE_MOUSE
     int (*waitforinput) __PROTO((void));     /* used for mouse input */
     void (*put_tmptext) __PROTO((int, const char []));   /* draws temporary 
text; int determines where: 0=statusline, 1,2: at corners of zoom box, with \r 
separating text above and below the point */
     void (*set_ruler) __PROTO((int, int));    /* set ruler location; x<0 
switches ruler off */
     void (*set_cursor) __PROTO((int, int, int));   /* set cursor style and 
corner of rubber band */
     void (*set_clipboard) __PROTO((const char[]));  /* write text into 
cut&paste buffer (clipboard) */
#endif

why would adding something like (*reposition_window) not work?

Dan