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

Re: wxt and "persist", n-th iteration !

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

> On Wednesday 06 June 2007 11:26, Timothée Lecomte wrote:
>> Ethan Merritt wrote
>> > I guess I'm dense today.  I don't understand.
>> > I thought that this whole parent/child split was because the parent
>> > process had to be the one managing the plot window.
>
> Ah, I missed the subtlety that you had shifted from threads to
> separate processes.  So the deal is that a child process can manage
> the plot window so long as it is done in the "parent thread of the
> child process".
>

Well, the child is still multithreaded with the current code, but
eventually it should be monothreaded to work reliably on wxMac.

>
>> The persist behaviour is the following:"plot windows survive after main
>> gnuplot program exits"
>
>> In the wxt case:
>> -gnuplot handles the windows without the help of another program. To
>> satisfy the caller program, it *has* to exit when the commands have all
>> been issued
>
> I don't think this is true.  Why can't gnuplot simply close the pipe
> back to the calling program, but continue running with no further
> input?  That is essentially what gnuplot_x11 does.
>
> When the calling program sees that the pipe has closed, it continues
> on with whatever it wants to do next.  It shouldn't be necessary that
> the gnuplot process itself has terminated.
>

My concern is backward-compatibility with current users of the persist
behaviour. I know one user, Maxima, and it's waiting for gnuplot ot finish
before continuing. Using google codesearch I can see that there are a
couple of other users of 'gnuplot -persist'. For Maxima and maybe some of
those, just closing the pipe is not enough.

Until now I have envisioned another possible use case, which is closing
the interactive shell to do something else without closing the windows.
However it is easily achievable with ctrl-z and 'bg' so it's not really
interesting.

>
>> *but* the windows must remain open. The only known solution is
>> to fork(), exit the parent (so that the calling program will be able to
>> continue) and let the child handle the windows.
>
> I can think of several other solutions that do not involve fork().
> If you don't like the pclose() solution, explain why and I'll suggest
> some other synchronization method.
>
Well, as said above, I'm thinking of programs that explicitly wait for
gnuplot to exit.

But I'm open to suggestions !

Timothée

Re: wxt and "persist", n-th iteration !

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

On Wednesday 06 June 2007 11:26, Timoth=E9e Lecomte wrote:
> Ethan Merritt wrote
> > I guess I'm dense today.  I don't understand.
> > I thought that this whole parent/child split was because the parent
> > process had to be the one managing the plot window.

Ah, I missed the subtlety that you had shifted from threads to=20
separate processes.  So the deal is that a child process can manage
the plot window so long as it is done in the "parent thread of the
child process".=20

> The persist behaviour is the following:"plot windows survive after main
> gnuplot program exits"

> In the wxt case:
> -gnuplot handles the windows without the help of another program. To
> satisfy the caller program, it *has* to exit when the commands have all
> been issued

I don't think this is true.  Why can't gnuplot simply close the pipe
back to the calling program, but continue running with no further
input?  That is essentially what gnuplot_x11 does.

When the calling program sees that the pipe has closed, it continues
on with whatever it wants to do next.  It shouldn't be necessary that
the gnuplot process itself has terminated.

> *but* the windows must remain open. The only known solution is=20
> to fork(), exit the parent (so that the calling program will be able to
> continue) and let the child handle the windows.

I can think of several other solutions that do not involve fork().
If you don't like the pclose() solution, explain why and I'll suggest=20
some other synchronization method.

	Ethan


> The next question is: when to fork() ?
> At exit-time ? The problem is that the windows are already created, so
> they somehow have to be "transfered" to the child process. It's possible
> on X (but tricky), however I think it's impossible on MacOS (or much
> trickier).
> So we have to fork() at startup, and let the child do *everything*, from
> readline to drawing, including command-line parsing.
> The parent becomes a dummy program which is just there to simulate what
> would be gnuplot itself in the x11 case.
>=20
> For example, with this scheme, if you do on the shell:
> 'gnuplot -persist'
> -> immediately, a child is forked, where everything is done. The parent
> sits there so that the shell doesn't return, and only for that.
>=20
> I hope it's clearer ;) If not, don't hesitate to ask again and I'll try to
> rephrase it.
>=20
> Best regards,
>=20
> Timoth=E9e
>=20
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>=20

=2D-=20
Ethan A Merritt

Re: wxt and "persist", n-th iteration !

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

> On Wednesday 06 June 2007 08:59, Timothée Lecomte wrote:
>>
>> If the user asks for 'gnuplot -persist', it probably means that he's
>> going
>> to use the interactive screen terminal...
>> Anyway, there's no problem with GNUTERM=png or if the user don't use wxt
>> at all. The child process will handle it fine, because it's exactly the
>> same process as the parent would be if there were no "persist" option at
>> all. Meanwhile, the parent process does nothing but waits so that we
>> don't
>> return to the shell immediately.
>
> I guess I'm dense today.  I don't understand.
> I thought that this whole parent/child split was because the parent
> process had to be the one managing the plot window.
>
> If the parent is doing nothing but wait for the child, why do we need to
> split off a child at all?
>

Let me try to explain again, I admit it's not straightforward:

The persist behaviour is the following:"plot windows survive after main
gnuplot program exits"

So, the user (typically another program, maxima for example) starts
'gnuplot -persist'. It issues its commands, and then expects gnuplot to
exit but the windows to remain open. We need a process to handle these
windows, right ?

In the x11 case:
-gnuplot starts gnuplot_x11, the latter is the one that manages the windows
-when gnuplot exits, gnuplot_x11 is still there until the windows are closed

In the wxt case:
-gnuplot handles the windows without the help of another program. To
satisfy the caller program, it *has* to exit when the commands have all
been issued *but* the windows must remain open. The only known solution is
to fork(), exit the parent (so that the calling program will be able to
continue) and let the child handle the windows.
The next question is: when to fork() ?
At exit-time ? The problem is that the windows are already created, so
they somehow have to be "transfered" to the child process. It's possible
on X (but tricky), however I think it's impossible on MacOS (or much
trickier).
So we have to fork() at startup, and let the child do *everything*, from
readline to drawing, including command-line parsing.
The parent becomes a dummy program which is just there to simulate what
would be gnuplot itself in the x11 case.

For example, with this scheme, if you do on the shell:
'gnuplot -persist'
-> immediately, a child is forked, where everything is done. The parent
sits there so that the shell doesn't return, and only for that.

I hope it's clearer ;) If not, don't hesitate to ask again and I'll try to
rephrase it.

Best regards,

Timothée

Re: wxt and "persist", n-th iteration !

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

On Wednesday 06 June 2007 08:59, Timoth=E9e Lecomte wrote:
>=20
> If the user asks for 'gnuplot -persist', it probably means that he's going
> to use the interactive screen terminal...
> Anyway, there's no problem with GNUTERM=3Dpng or if the user don't use wxt
> at all. The child process will handle it fine, because it's exactly the
> same process as the parent would be if there were no "persist" option at
> all. Meanwhile, the parent process does nothing but waits so that we don't
> return to the shell immediately.

I guess I'm dense today.  I don't understand.
I thought that this whole parent/child split was because the parent
process had to be the one managing the plot window. =20

If the parent is doing nothing but wait for the child, why do we need to
split off a child at all? =20

Conversely, if the parent is needed to manage the plot window then how
can you allow it to exit when -persist is requested? =20


=2D-=20
Ethan A Merritt

Re: wxt and "persist", n-th iteration !

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

> On Wednesday 06 June 2007 08:06, Timothée Lecomte wrote:
>>
>> The only solution I can think of (apart from recreating the windows one
>> by
>> one in the child process, which would cause an obvious flickering) is to
>> fork before windows are created, i.e. *immediately* when gnuplot
>> *starts*.
>> Then have the parent process do nothing but wait for the child to tell
>> him
>> to exit.
>
> I have not been following this whole OSX debacle very closely,
> but if I understand what you are saying then it seems to me that this
> may introduce problems.  Suppose that you have GNUTERM set to png or
> pdf or something else on entry.  This would be fairly normal for a
> script.  If you run this script under OSX, are you going to fork
> off a child process even though it probably won't be needed?
> Or do you rule out doing a "set term wxt" or "set term aqua" later
> on?
>
> It might be better to simply accept that "persist" is not supported
> on OSX.  There are other ways to get the same behaviour now.
>
> 	Ethan

If the user asks for 'gnuplot -persist', it probably means that he's going
to use the interactive screen terminal...
Anyway, there's no problem with GNUTERM=png or if the user don't use wxt
at all. The child process will handle it fine, because it's exactly the
same process as the parent would be if there were no "persist" option at
all. Meanwhile, the parent process does nothing but waits so that we don't
return to the shell immediately.

And as a bonus note, even if the patch is restricted to wxt only, this
implementation would also work for aqua ! It would also work for x11, and
would have the advantage to give full mouse interaction instead of the
current behaviour (only coordinated).

Best regards,

Timothée

Re: wxt and "persist", n-th iteration !

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

On Wednesday 06 June 2007 08:06, Timoth=C3=A9e Lecomte wrote:
>=20
> The only solution I can think of (apart from recreating the windows one by
> one in the child process, which would cause an obvious flickering) is to
> fork before windows are created, i.e. *immediately* when gnuplot *starts*.
> Then have the parent process do nothing but wait for the child to tell him
> to exit.

I have not been following this whole OSX debacle very closely,
but if I understand what you are saying then it seems to me that this=20
may introduce problems.  Suppose that you have GNUTERM set to png or
pdf or something else on entry.  This would be fairly normal for a
script.  If you run this script under OSX, are you going to fork
off a child process even though it probably won't be needed?
Or do you rule out doing a "set term wxt" or "set term aqua" later
on?

It might be better to simply accept that "persist" is not supported
on OSX.  There are other ways to get the same behaviour now.

	Ethan

=20
> The only drawback I can think of is that gnuplot has to know it has to
> fork when it's launched, so the "persist" setting must be given on gnuplot
> command-line. Other places where it can be set currently, in 'set wxt
> persist' and in wxt configuration dialog, have to be removed.
>=20
> The corresponding patch is attached. I'd like those of you who use
> "persist"    (or understand what it was meant for) to comment.
>=20
> As for me, I only know one user, Maxima, and the proposed patch should
> satisfy it.
>=20
> Best regards,
>=20
> Timoth=C3=A9e
>=20

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

wxt and "persist", n-th iteration !

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

Hi!

I'm still thinking about wxt-on-Mac, and while there is one major issue
still in the works (the last one I mailed about, i.e. the single-threaded
vs. two-threaded), I've come to think about the "persist" behaviour. Let
me remind you that the purpose of "persist" is to keep plot windows open
when gnuplot exits.

Currently, I implemented this on Unix/wxGtk by forking at exit-time. The
connection to the X server is preserved, since it's a file descriptor, and
the child process keeps running the GUI loop in the background. With wxMac
(native wxWidgets on MacOS), this doesn't work: as soon as the parent
process exits, the windows disappear.

The only solution I can think of (apart from recreating the windows one by
one in the child process, which would cause an obvious flickering) is to
fork before windows are created, i.e. *immediately* when gnuplot *starts*.
Then have the parent process do nothing but wait for the child to tell him
to exit.

The only drawback I can think of is that gnuplot has to know it has to
fork when it's launched, so the "persist" setting must be given on gnuplot
command-line. Other places where it can be set currently, in 'set wxt
persist' and in wxt configuration dialog, have to be removed.

The corresponding patch is attached. I'd like those of you who use
"persist"    (or understand what it was meant for) to comment.

As for me, I only know one user, Maxima, and the proposed patch should
satisfy it.

Best regards,

Timothée

Re: default size of wxt terminal

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

> How do I change the defaults of wxt terminal window?
>
> gnuplot -geometry 1024x768
>
> works for x11 terminal, but not for wxt
>
> Sincerely,
>
> Dmitri.

Hi Dmitri,

There's no mechanism for this currently with wxt, but I'd be happy to
provide one.

I can think of several different ways to implement it:

- with 'set term wxt size 1024,768'
- with an option in the configuration dialog to explicitly choose the size
- with a button in the configuration dialog to remember the current size
(no size to enter explicitly !)
- with an option to toggle in the configuration dialog to always use the
size of the previous window (from current or last session) when opening a
new one

Which one(s) do you prefer ? Or do you have any other idea ?

I personally wouldn't go the 'gnuplot -geometry 1024x768' way, I don't
like command-line options ;)

Best regards,

Timothée

Re: Patches item #1729825 ready to go.

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

Juergen Wieferink wrote:
> man bash:
> 
>        operate-and-get-next (C-o)
>               Accept the current line for execution and fetch  the  
> next  line
>               relative  to the current line from the history for 
> editing.  Any
>               argument is ignored.
> 
> 
> Seems to be implemented specially for the bash.  I don't know how
> much effort this would be.  I just like it very much.

OK, I get it now.  Seems easy given what I just did with bindings.  But let's 
wait for the dust to settle on the new patch and basic history recall.  Remind 
me in the future if I forget.

Dan

Re: Patches item #1729825 ready to go.

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

Petr Mikulik wrote:
>>I've programmed the condensed version during display rather than tossing out 
>>redundant commands and that was *so* much easier.  The only difference is that 
>>the up-arrow that you mention, Petr, will still have to go through the full 
>>list.  (I could probably reprogram that as well to skip redundancy.)
>>
>>I think it is easy enough to enable both with an option (full history stack, 
>>default).  In fact, I'd propose to deprecate
> 
> 
> So it seems everybody likes a different history: I like a "set" of commands, 
> some other "ordered list" with/out duplicates, ... Dan, please make options 
> to satisfy everybody -- it you think all this is worth to change.

OK, I think you will like this new patch (#1729825).  Type

   help history
   help set history

"set history" will set a few options that can be over-ridden locally.  E.g.,

   set history condensed

will generally display the history stack in condensed format; however,

   history full

will override that.

Here is something really neat, and nothing kludge-like about it from the 
perspective of readline.  When "set history condensed" is active, the up/down 
arrows will now also scan through only unique history entries, like you want 
Petr.  Here is the elegant way to do it.  Simply write a routine like

static int gp_get_condensed_next_history(int count, int key) {
     /* Look for the previous unique command */
     HIST_ENTRY **the_list = history_list();
     int i_hist = where_history() + 1;
     for (; i_hist < history_length; i_hist++) {
	if (the_list[i_hist]->data == NULL)
	    break;
     }
     /* Advance to found unique entry */
     if (i_hist < history_length)
	return rl_get_next_history(i_hist - where_history(), key);
     else
	return 0;
}

and then bind that function to the downarrow key sequence.  When not in 
condensed mode, bind the keys back to the original rl_get_next_history().

There is some flexibility with what we could do (e.g., bind the condensed 
up/down to other keys) but we'll see what feedback we get.

I've also made the non GNU-readline version behave similarly.

Could people please review this to see if everyone is happy, or at least mildly 
content?  I think it is close to ready.  I've tried most everything and see no 
bugs.  (I've updated to readline-5.2, as readline-4.3 seemed buggy.)

...

Juergen, now that I'm familiar with all this GNU readline bindings stuff, I 
think C-o may not be difficult.  But again, you'll have to explain what it does. 
  E.g., give an example command-line stack and the before and after of a C-o.

Dan

Re: Patches item #1729825 ready to go.

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

> The C-p, C-n, C-r appear to be standard GNU readline, not C-o. 
> Perhaps you need to setup this binding in an inputrc file?

I think so.

>
> http://tiswww.case.edu/php/chet/readline/readline.html#SEC9
>
> I'm still not sure what type of command this is.  Is there are
> listing of sorts in the above readline documentation of command
> types?  If so, does something match what you are speaking of?

man bash:

       operate-and-get-next (C-o)
              Accept the current line for execution and fetch  the  
next  line
              relative  to the current line from the history for 
editing.  Any
              argument is ignored.


Seems to be implemented specially for the bash.  I don't know how
much effort this would be.  I just like it very much.


Juergen

Re: X11 Focus [was: Re: Patches item #1729825 ready to go.]

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

> > > Fortunately, what you describe is simply not true here. 
> > > I see no such focus-stealing nonsense for the x11 terminal.
> > > So your system must be configured quite differently than mine.
> > 
> > I reproduce the same problem: Blackbox, WindowMaker, KDE.
> > 
> > Is there a workaround?
> 
> You must have set, somewhere, a window manager policy that
> gives focus to each new window.   Don't do that.
> 
> -> KDE
>     -> Appearance & Themes
> 	-> window behaviour
> 	    -> advanced
> 		-> focus stealing prevention level
> 		    -> 'high' [or 'extreme']

The 'high' makes some strange things, I prefer to have it 'None'.

---
PM

Re: Segfaults on exit - something has messed up recent CVS

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

>> For the last week or so I've been getting a double-free warning
>> message from glibc every time I exit gnuplot with the current driver
>> set to wxt.  This was non-fatal, although it did mean
>> that the history file was not updated.
>>
>> As of today this has gotten much worse. It no longer happens every
>> time I exit, but if it does happen then it causes a core dump:
>>
>> (<unknown>:1881): GLib-GObject-WARNING **: instance of invalid
>> non-instantiatable type `-g-type-private--GTypeFlags'
>>
>> (<unknown>:1881): GLib-GObject-CRITICAL **:
>> g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE
>> (instance)' failed
> (...)
>>
>>
>> The only recent patch I see is:
>> 2007-06-03  Petr Mikulik  <mi...@ph...>
>> * src/history.c (write_history_n): Cannot use int_error() when exiting
>> gnuplot.
>>
>> I don't understand how this would make things worse than before,
>> but I don't see any other candidate patches.
>>
>> Is anyone else seeing this?   Any ideas why?
>
> I see it, and I must be the one to blame, not Petr.
>
> 2007-05-23  Timothee Lecomte  <tim...@en...>
>
>         * src/wxterminal/wxt_gui.cpp:
>         * src/wxterminal/wxt_gui.h:
>         Add/rewrite a few debugging messages.
>         (wxt_atexit, wxt_cleanup): Simplify "persist" and exit code.
>
>
> I'll look at it tomorrow. Thanks for reporting.
>

Indeed I made a mistake, and I think it's now corrected. I cannot
reproduce it anymore with current CVS.

Best regards,

Timothée

Re: X11 Focus [was: Re: Patches item #1729825 ready to go.]

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

On Tuesday 05 June 2007 13:28, Petr Mikulik wrote:
> > > For example, I explained before that I don't like  
> > > the fact the first plot in X11 terminal always grabs focus so that I have to 
> > > take my hand off the keyboard and press the mouse button to get back to the 
> > > command line.
> > 
> > Fortunately, what you describe is simply not true here. 
> > I see no such focus-stealing nonsense for the x11 terminal.
> > So your system must be configured quite differently than mine.
> 
> I reproduce the same problem: Blackbox, WindowMaker, KDE.
> 
> Is there a workaround?

You must have set, somewhere, a window manager policy that
gives focus to each new window.   Don't do that.

I use policy "focus under mouse", which does exactly what its
name implies.  The focus stays with the window where the mouse
cursor is.  Focus is not affected by a new window popping up
somewhere else.

If you are using KDE but want a policy like "click to focus",
you may be able to mitigate the issue by also selecting

-> KDE
    -> Appearance & Themes
	-> window behaviour
	    -> advanced
		-> focus stealing prevention level
		    -> 'high' [or 'extreme']


In WindowMaker, select the "Window Focus Preference" icon
at the top right of the configuration panel.  In the box
marked "Input Focus Mode" de-select the option
"Automatically focus new windows"

-- 
Ethan A Merritt

Re: Patches item #1729825 ready to go.

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

Juergen Wieferink wrote:
>>>Would this even allow an implementation of the C-o sequence in
>>>bash (enter line + go to next history item)?  This command
>>>sequence is really nice because it saves you from counting
>>>up-arrows.  This would be *too* nice!
>>
>>You'll have to explain a bit more.  Is this command-line
>>completion you are talking about?
> 
> 
> No.  I'm talking about the emacs-like key bindings the bash
> provides.
> 
> Examples of key bindings also in gnuplots readline:
> C-p: previous history line
> C-n: next history line
> C-r: incremental backward search in history
> 
> C-o is missing in gnuplot.  First, it executes the current line.  If
> this is the line n in the history, line n+1 is loaded into the next
> command line.  Thus, you can search a distinct line using (for
> example) C-r <significant substring> and then execute the following
> lines in the history using subsequent C-o.  Once used to it, this a
> very convenient feature of the bash and it would be valuable to have
> it in gnuplot, too.

The C-p, C-n, C-r appear to be standard GNU readline, not C-o.  Perhaps you need 
to setup this binding in an inputrc file?

http://tiswww.case.edu/php/chet/readline/readline.html#SEC9

I'm still not sure what type of command this is.  Is there are listing of sorts 
in the above readline documentation of command types?  If so, does something 
match what you are speaking of?

Dan

Re: X11 Focus [was: Re: Patches item #1729825 ready to go.]

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

> > For example, I explained before that I don't like  
> > the fact the first plot in X11 terminal always grabs focus so that I have to 
> > take my hand off the keyboard and press the mouse button to get back to the 
> > command line.
> 
> Fortunately, what you describe is simply not true here. 
> I see no such focus-stealing nonsense for the x11 terminal.
> So your system must be configured quite differently than mine.

I reproduce the same problem: Blackbox, WindowMaker, KDE.

Is there a workaround?

---
PM

Re: Patches item #1729825 ready to go.

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

> I've programmed the condensed version during display rather than tossing out 
> redundant commands and that was *so* much easier.  The only difference is that 
> the up-arrow that you mention, Petr, will still have to go through the full 
> list.  (I could probably reprogram that as well to skip redundancy.)
> 
> I think it is easy enough to enable both with an option (full history stack, 
> default).  In fact, I'd propose to deprecate

So it seems everybody likes a different history: I like a "set" of commands, 
some other "ordered list" with/out duplicates, ... Dan, please make options 
to satisfy everybody -- it you think all this is worth to change.

> 1)  history clear

OK

---
PM

Re: Patches item #1729825 ready to go.

[<pl...@pi...>]

On Tue, 05 Jun 2007 17:52:00 +0200, Daniel J Sebald  
<dan...@ie...> wrote:

> Petr Mikulik wrote:
>>> I thought it was just an annoying bug that some of my commands seemed  
>>> to
>>> disappear. I never figured out any rhyme or reason to it.
>>>
>>> I strongly request that the default history behaviour is to leave
>>> all my commands in place.  I would consider this a bug-fix.
>>>
>>> I want it to behave like the csh [and tcsh and bash] history commands.
>>> Go with what the users expect.
>>
>>
>> I'm strongly against your proposal.
>>
>> Well, it was my first patch to gnuplot ages ago, to remove the repeated
>> commands from the stack. I was so upset in a long night experiment at  
>> the
>> ESRF having to hit dozen of times up-arrow before the actual plotting
>> command appeared, that I started hacking gnuplot...
>>
>> I never used history to report what exactly I was doing. I need it to
>> quickly go through the commands and have them available for editing, or  
>> with
>> the "history" command to paste them via mouse.
>
> I've programmed the condensed version during display rather than tossing  
> out
> redundant commands and that was *so* much easier.  The only difference  
> is that
> the up-arrow that you mention, Petr, will still have to go through the  
> full
> list.  (I could probably reprogram that as well to skip redundancy.)
>
> I think it is easy enough to enable both with an option (full history  
> stack,
> default).  In fact, I'd propose to deprecate
>
>    set historysize
>
> in exchange for
>
>    set history {#(size)} {condensed|full} {quiet|numbered}
>
> Picking syntax to reflect exactly the variables in gnuplot code  
> inherently
> limits future flexibility.
>
> Then, as part of the history command, one could override the settings  
> with
>
>    hi #
>    hi full num
>
> and such.
>
> Here are some other features I think worth having:
>
> 1)  history clear
>
> to clear out the history stack in case someone *does* want to use  
> history like a
> recording devise.
>
> 2) Some method of stepping through the history hunks at a time, say 10  
> or 20?  I
> don't know.  It's just that some people really like working solely from  
> the
> keyboard as much as possible.  For example, I explained before that I  
> don't like
> the fact the first plot in X11 terminal always grabs focus so that I  
> have to
> take my hand off the keyboard and press the mouse button to get back to  
> the
> command line.  (I know, figure out what the window manager key sequence  
> is to
> push focus one window back.)
>
> Dan
>

I'm not quite sure what circumstances Petr felt so annoying that inspired  
him to modify this but as a user I think this should be a true (bash like)  
history not a filtered one.

The history command should supply the history, a record of recent commands.

It would probably make more sense to provide some switch like  
history:nodulpes ( !:nd ) that does what Petr wants to see. This would  
follow the syntax of shell history functions like !:p

Hope that can satisify both needs.

;)

Re: X11 Focus [was: Re: Patches item #1729825 ready to go.]

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

pl...@pi... wrote:
> On Tue, 05 Jun 2007 18:16:23 +0200, Ethan Merritt  
> <merritt@u.washington.edu> wrote:
> 
> 
>>Fortunately, what you describe is simply not true here.
>>I see no such focus-stealing nonsense for the x11 terminal.
>>So your system must be configured quite differently than mine.
>>I wonder how?
> 
> 
> 
> This is likely a WM config. I have this annoyance as well but it's the way  
> I like my WM set up in general. Look for something like "new windows get  
> focus".

I think too that that was my original feeling.  I too generally like my WM to 
grab focus when launching a new application.  But in the case of a plot, I most 
commonly just want to look at it, not type anything in the plot window.

Dan

Re: X11 Focus [was: Re: Patches item #1729825 ready to go.]

[<pl...@pi...>]

On Tue, 05 Jun 2007 18:16:23 +0200, Ethan Merritt  
<merritt@u.washington.edu> wrote:

>
> Fortunately, what you describe is simply not true here.
> I see no such focus-stealing nonsense for the x11 terminal.
> So your system must be configured quite differently than mine.
> I wonder how?


This is likely a WM config. I have this annoyance as well but it's the way  
I like my WM set up in general. Look for something like "new windows get  
focus".

HTH

Re: Patches item #1729825 ready to go.

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

> > Would this even allow an implementation of the C-o sequence in
> > bash (enter line + go to next history item)?  This command
> > sequence is really nice because it saves you from counting
> > up-arrows.  This would be *too* nice!
>
> You'll have to explain a bit more.  Is this command-line
> completion you are talking about?

No.  I'm talking about the emacs-like key bindings the bash
provides.

Examples of key bindings also in gnuplots readline:
C-p: previous history line
C-n: next history line
C-r: incremental backward search in history

C-o is missing in gnuplot.  First, it executes the current line.  If
this is the line n in the history, line n+1 is loaded into the next
command line.  Thus, you can search a distinct line using (for
example) C-r <significant substring> and then execute the following
lines in the history using subsequent C-o.  Once used to it, this a
very convenient feature of the bash and it would be valuable to have
it in gnuplot, too.

Juergen

Re: X11 Focus [was: Re: Patches item #1729825 ready to go.]

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

Ethan Merritt wrote:
> On Tuesday 05 June 2007 08:52, Daniel J Sebald wrote:
> 
> 
>>For example, I explained before that I don't like  
>>the fact the first plot in X11 terminal always grabs focus so that I have to 
>>take my hand off the keyboard and press the mouse button to get back to the 
>>command line.
> 
> 
> ???
> That behaviour would be totally unacceptable to me.
> IMHO no program is entitled to the mouse focus on its own.

Even from the children it creates?  (Not that any parent has any control of 
their kids.)


> Fortunately, what you describe is simply not true here. 
> I see no such focus-stealing nonsense for the x11 terminal.
> So your system must be configured quite differently than mine.
> I wonder how?

You've got that fancy KDE stuff.

Dan

X11 Focus [was: Re: Patches item #1729825 ready to go.]

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

On Tuesday 05 June 2007 08:52, Daniel J Sebald wrote:

> For example, I explained before that I don't like  
> the fact the first plot in X11 terminal always grabs focus so that I have to 
> take my hand off the keyboard and press the mouse button to get back to the 
> command line.

???
That behaviour would be totally unacceptable to me.
IMHO no program is entitled to the mouse focus on its own.

Fortunately, what you describe is simply not true here. 
I see no such focus-stealing nonsense for the x11 terminal.
So your system must be configured quite differently than mine.
I wonder how?

-- 
Ethan A Merritt

Re: Patches item #1729825 ready to go.

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

Juergen Wieferink wrote:
>>Another reason for keeping the stack always in order as typed is so that
>>the up-arrow recall maintains an order.  (Often a lot of my patterns at the
>>linux command line are derived from how many times I hit up-arrow to recall
>>a command... easier to do than describe.)
> 
> 
> Would this even allow an implementation of the C-o sequence in bash
> (enter line + go to next history item)?  This command sequence is
> really nice because it saves you from counting up-arrows.  This
> would be *too* nice!

You'll have to explain a bit more.  Is this command-line completion you are 
talking about?

Dan

Re: Patches item #1729825 ready to go.

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

Petr Mikulik wrote:
>>I thought it was just an annoying bug that some of my commands seemed to 
>>disappear. I never figured out any rhyme or reason to it.
>>
>>I strongly request that the default history behaviour is to leave
>>all my commands in place.  I would consider this a bug-fix.
>>
>>I want it to behave like the csh [and tcsh and bash] history commands.
>>Go with what the users expect.
> 
> 
> I'm strongly against your proposal.
> 
> Well, it was my first patch to gnuplot ages ago, to remove the repeated 
> commands from the stack. I was so upset in a long night experiment at the 
> ESRF having to hit dozen of times up-arrow before the actual plotting 
> command appeared, that I started hacking gnuplot...
> 
> I never used history to report what exactly I was doing. I need it to 
> quickly go through the commands and have them available for editing, or with 
> the "history" command to paste them via mouse.

I've programmed the condensed version during display rather than tossing out 
redundant commands and that was *so* much easier.  The only difference is that 
the up-arrow that you mention, Petr, will still have to go through the full 
list.  (I could probably reprogram that as well to skip redundancy.)

I think it is easy enough to enable both with an option (full history stack, 
default).  In fact, I'd propose to deprecate

   set historysize

in exchange for

   set history {#(size)} {condensed|full} {quiet|numbered}

Picking syntax to reflect exactly the variables in gnuplot code inherently 
limits future flexibility.

Then, as part of the history command, one could override the settings with

   hi #
   hi full num

and such.

Here are some other features I think worth having:

1)  history clear

to clear out the history stack in case someone *does* want to use history like a 
recording devise.

2) Some method of stepping through the history hunks at a time, say 10 or 20?  I 
don't know.  It's just that some people really like working solely from the 
keyboard as much as possible.  For example, I explained before that I don't like 
the fact the first plot in X11 terminal always grabs focus so that I have to 
take my hand off the keyboard and press the mouse button to get back to the 
command line.  (I know, figure out what the window manager key sequence is to 
push focus one window back.)

Dan