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

Re: Patches item #1729825 ready to go.

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

On Fri, 08 Jun 2007 18:26:05 +0200, Daniel J Sebald  
<dan...@ie...> wrote:

> pl...@pi... wrote:
>
>> Not sure if you understood what I was meaning. I was refering to  
>> stripping  out spaces etc. not whether "history" appears. IMHO history  
>> command should  reproduce what was typed at the command line (unless  
>> some option like  condenced is activated).
>
> Got it.  I suppose removing spaces is analogous to removing redundant  
> lines.  So rather than toss out the spaces, in condensed mode I could do  
> comparison tests based upon spaces removed rather than actually removing  
> the spaces.
>
> Dan
>
Sounds good.
I think what you do in condensed mode is fairly open to choice, my concern  
is that history (default mode) remains a true reflection of what was typed.

Your suggestion above seems like a good solution.

best regards.

Re: Patches item #1729825 ready to go.

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

pl...@pi... wrote:

> Not sure if you understood what I was meaning. I was refering to stripping  
> out spaces etc. not whether "history" appears. IMHO history command should  
> reproduce what was typed at the command line (unless some option like  
> condenced is activated).

Got it.  I suppose removing spaces is analogous to removing redundant lines.  So 
rather than toss out the spaces, in condensed mode I could do comparison tests 
based upon spaces removed rather than actually removing the spaces.

Dan

Re: Patches item #1729825 ready to go.

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

On Fri, 08 Jun 2007 18:04:46 +0200, Daniel J Sebald  
<dan...@ie...> wrote:

> pl...@pi... wrote:
>> On Fri, 08 Jun 2007 00:25:05 +0200, Daniel J Sebald   
>> <dan...@ie...> wrote:
>>
>>> Also, I should point out that the patch removes all duplicate spaces   
>>> from input
>>> lines before placing them in the history buffer.  This makes things  
>>> more  tidy
>>> and also makes things like "plot x" and "plot            x" eqivalent.
>>> Dan
>>   I'd be careful about "tidying" things up. History should show what  
>> was  done , not some arbitary sanitised version. If ppls want "clean"  
>> they  should tap clean commands. I see no justification for this  
>> feature.
>>  Without searching for a specific example, I may want to see why  
>> something  happened differently to I expect (bug of finger trouble).  I  
>> NEED to see  exactly what I typed. Please dont mess with.
>>  Appreciate your efforts on this I think the clean up and new ideas  
>> look  very good in general.
>>  ;)
>
> "history" is a very particular item, I see.  I can leave it out; its  
> effect probably isn't that significant in reducing redundancy when in  
> condensed mode.
>
> Dan
>
Not sure if you understood what I was meaning. I was refering to stripping  
out spaces etc. not whether "history" appears. IMHO history command should  
reproduce what was typed at the command line (unless some option like  
condenced is activated).

As for the question of "history" itself appearing at the last command , I  
would suggest it's probably non-std behaviour of ksh you quoted and  
gnuplot should probably follow bash/csh/zsh etc. and display the current  
command, ie history, in the list.

The latter is minor detail not worth further discussion. I consider the  
first point to be important. Dont try to rewrite history ;)

Re: Patches item #1729825 ready to go.

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

pl...@pi... wrote:
> On Fri, 08 Jun 2007 00:25:05 +0200, Daniel J Sebald  
> <dan...@ie...> wrote:
> 
>> Also, I should point out that the patch removes all duplicate spaces  
>> from input
>> lines before placing them in the history buffer.  This makes things 
>> more  tidy
>> and also makes things like "plot x" and "plot            x" eqivalent.
>> Dan
> 
> 
> I'd be careful about "tidying" things up. History should show what was  
> done , not some arbitary sanitised version. If ppls want "clean" they  
> should tap clean commands. I see no justification for this feature.
> 
> Without searching for a specific example, I may want to see why 
> something  happened differently to I expect (bug of finger trouble).  I 
> NEED to see  exactly what I typed. Please dont mess with.
> 
> Appreciate your efforts on this I think the clean up and new ideas look  
> very good in general.
> 
> ;)

"history" is a very particular item, I see.  I can leave it out; its effect 
probably isn't that significant in reducing redundancy when in condensed mode.

Dan

Re: Patches item #1729825 ready to go.

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

On Fri, 08 Jun 2007 00:25:05 +0200, Daniel J Sebald  
<dan...@ie...> wrote:

> Also, I should point out that the patch removes all duplicate spaces  
> from input
> lines before placing them in the history buffer.  This makes things more  
> tidy
> and also makes things like "plot x" and "plot            x" eqivalent.
> Dan

I'd be careful about "tidying" things up. History should show what was  
done , not some arbitary sanitised version. If ppls want "clean" they  
should tap clean commands. I see no justification for this feature.

Without searching for a specific example, I may want to see why something  
happened differently to I expect (bug of finger trouble).  I NEED to see  
exactly what I typed. Please dont mess with.

Appreciate your efforts on this I think the clean up and new ideas look  
very good in general.

;)

Re: Patches item #1729825 ready to go.

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

Petr Mikulik wrote:

> I think you can let it as is; optionally there could be useful
> 	set history full|ignoredups|condensed

OK.  I'll see if there might be an easier way than the unwinding of the number 
inside history.c.  That was simply too convoluted to follow.


> It'd be better to edit $HOME/.gnuplot_history

I too thought that would be a preferable route.

Dan

Re: Patches item #1729825 ready to go.

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

Petr Mikulik wrote:
>>>After one sets
>>>
>>>  set history condensed
>>>
>>>the up arrow should only sequence through unique commands.  That is the 
>>>way it works here.
> 
> 
> Yes, condensed works.
> 
> This may be interesting to add "ignoredups" as a variant of "full".

Well, the appearance of bash 'ignoredups' and gnuplot 'condensed' is the same if 
one starts from an empty history.  It would certainly be possible to have the 
options {full|condensed|ignoredups|erasedups}.  Do ignoredups|erasedups add 
anything?


>>Did you find that 'set hist con' solves the problem?  (Place that command in you 
>>gnuplot initialization file.)  If so, is overall behavior acceptable for you?
> 
> 
> 
> BTW, gnuplot crashes for "h" command ... 
> 
> Terminal type set to 'x11'
> gnuplot> h
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1094909056 (LWP 14570)]
> FindHelp (keyword=0x81cd030 "", matching_key=0xbfb21ba8, 
> print_best_match_len=0xbfb21ba4) at help.c:479
> 479                         expand_buff[i] = expand_buff[i-shift];
> (gdb) quit

Oh boy.  Did I overlook the most obvious of variations on "help", i.e., no other 
tokens?

I'll fix it and put a new patch on SourceForge.

Thanks,

Dan

Re: Patches item #1729825 ready to go.

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

> > "man bash" => search HISTCONTROL gives several nice options -- some of them
> > you are implementing for gnuplot. Have a look.
> 
> Oh yeah...  The 'ignoreboth' means 'ignorespace:ignoredups'.  The ignore space
> doesn't seem like anything that special or useful; it would mean developing a
> habit of typing space before a command one doesn't want to go on the history
> list.  Is that worth implementing?  The 'ignoredups' will leave out commands
> that are the same as last command, not quite what you originally implemented.
> However, the 'erasedups' is pretty similar, although I think your code stopped
> after the first found duplicate...no difference if one starts from a clean
> history stack.

I think you can let it as is; optionally there could be useful
	set history full|ignoredups|condensed

Then I would prefer the default to be the ignoredups.

> On the surface this sounds worthwhile, but who wants to spend time selectively
> deleting entries from an ephemeral history list?  "Sorry, can't go out
> tonight; got to clean my history list."

It'd be better to edit $HOME/.gnuplot_history

---
PM

Re: Patches item #1729825 ready to go.

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

Petr Mikulik wrote:
>>Good point.  On my system it is
>>
>>
>>bash (gnome's default?)
>>----
>>  1000  ls
>>  1001  ls
>>  1002  ls
>>  1003  history
> 
> 
> On OpenSUSE, the default value in environmental variables is
> 	HISTCONTROL=ignoreboth
> 
> so I would see "ls" once only.
> 
> "man bash" => search HISTCONTROL gives several nice options -- some of them 
> you are implementing for gnuplot. Have a look.

Oh yeah...  The 'ignoreboth' means 'ignorespace:ignoredups'.  The ignore space 
doesn't seem like anything that special or useful; it would mean developing a 
habit of typing space before a command one doesn't want to go on the history 
list.  Is that worth implementing?  The 'ignoredups' will leave out commands 
that are the same as last command, not quite what you originally implemented. 
However, the 'erasedups' is pretty similar, although I think your code stopped 
after the first found duplicate...no difference if one starts from a clean 
history stack.

Well, this all works on my bash shell.  Is there some more direct way of getting 
at these features?  Or is gnuplot effectively playing the role that a shell 
plays as far as accessing GNU readline?  I still kind of like the idea of 
keeping the whole history stack and only making it a matter of how one views it 
and steps through it.  The gnuplot rerun-by-number feature

hist !88

just seems like a time saving item.  (If people end up not using it by time of 
next release, remove it.)  When bash does an 'erasedups' all the numbers are 
still contiguous.  I don't see the point of numbers if they keep changing and 
can't be used in some way.

There's one entry in bash history I find a little comical.

               -d offset
                      Delete the history entry at position offset.

On the surface this sounds worthwhile, but who wants to spend time selectively 
deleting entries from an ephemeral history list?  "Sorry, can't go out tonight; 
got to clean my history list."

Dan

Re: Patches item #1729825 ready to go.

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

> > After one sets
> > 
> >   set history condensed
> > 
> > the up arrow should only sequence through unique commands.  That is the 
> > way it works here.

Yes, condensed works.

This may be interesting to add "ignoredups" as a variant of "full".

> Did you find that 'set hist con' solves the problem?  (Place that command in you 
> gnuplot initialization file.)  If so, is overall behavior acceptable for you?


BTW, gnuplot crashes for "h" command ... 

Terminal type set to 'x11'
gnuplot> h

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1094909056 (LWP 14570)]
FindHelp (keyword=0x81cd030 "", matching_key=0xbfb21ba8, 
print_best_match_len=0xbfb21ba4) at help.c:479
479                         expand_buff[i] = expand_buff[i-shift];
(gdb) quit

---
PM

Re: Patches item #1729825 ready to go.

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

> 
> Good point.  On my system it is
> 
> 
> bash (gnome's default?)
> ----
>   1000  ls
>   1001  ls
>   1002  ls
>   1003  history

On OpenSUSE, the default value in environmental variables is
	HISTCONTROL=ignoreboth

so I would see "ls" once only.

"man bash" => search HISTCONTROL gives several nice options -- some of them 
you are implementing for gnuplot. Have a look.

---
PM

Urgent....How to call only output in my Devloped GUI

[amit k. <786...@gm...>]

hello,

      I am developing real time project ,i have need to call graphical
representation in that project.i want to see only output GNU window,
after clicking on command button.I am using Visual C++ for Developing this
project.plz give me clear instructions.


Thanks & Regards

Amit Kumar

ikanos communication

Re: Patches item #1729825 ready to go.

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

Ethan Merritt wrote:
> On Thursday 07 June 2007 15:25, Daniel J Sebald wrote:
> 
>>gnome-term and xterm keep a full history:
>>
>>   998  su
>>   999  exit
>>  1000  ls
>>  1001  ls
>>  1002  ls
>>  1003  history
> 
> 
> Surely that history is maintained by the shell, not the terminal?

Good point.  On my system it is


bash (gnome's default?)
----
  1000  ls
  1001  ls
  1002  ls
  1003  history

(note how history appears as the final entry)


ksh (Korn)
----------
1       ls
2       ls
3       ls

(history doesn't appear, but it shows in the following use of history)

1       ls
2       ls
3       ls
4       history


ash
---
$ history
history: permission denied


csh/tcsh
--------
      1  17:49   ls
      2  17:49   ls
      3  17:49   ls
      4  17:49   history

Re: Patches item #1729825 ready to go.

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

On Thursday 07 June 2007 15:25, Daniel J Sebald wrote:
> 
> gnome-term and xterm keep a full history:
> 
>    998  su
>    999  exit
>   1000  ls
>   1001  ls
>   1002  ls
>   1003  history

Surely that history is maintained by the shell, not the terminal?

The relevant point is not what terminal emulator you're using,
but rather what shell you are using.

-- 
Ethan A Merritt

Re: Patches item #1729825 ready to go.

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

Daniel J Sebald wrote:

>> Please add the to skip duplicated entries with the up-arrow. It does 
>> not make sense to press up so many times, even though many same lines 
>> are in history, does it?
> 
> 
> After one sets
> 
>   set history condensed
> 
> the up arrow should only sequence through unique commands.  That is the 
> way it works here.

Did you find that 'set hist con' solves the problem?  (Place that command in you 
gnuplot initialization file.)  If so, is overall behavior acceptable for you?


>> BTW, bash does not store duplicated entries (try several times to type 
>> "ls" and then "history").

gnome-term and xterm keep a full history:

   998  su
   999  exit
  1000  ls
  1001  ls
  1002  ls
  1003  history

...

Also, I should point out that the patch removes all duplicate spaces from input 
lines before placing them in the history buffer.  This makes things more tidy 
and also makes things like "plot x" and "plot            x" eqivalent.

Dan

Re: default size of wxt terminal

[Dmitri A. S. <das...@gm...>]

On 6/7/07, Timoth=E9e Lecomte <tim...@en...> wrote:

>
> You can still put that line in your $HOME/.gnuplot file and it will be a
> default then ;)

That is the plan :)

>
> I'll try to implement that in the next days.
>

Thanks!

> Best regards,
>
> Timoth=E9e
>
>

Dmitri.
--

Re: default size of wxt terminal

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

> On 6/6/07, Timothée Lecomte <tim...@en...> wrote:
>> > 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'
>
> This is not quite "default" (default is the size that would be
> used if nothing specified explicitly), but it does look as a nice
> option to have, consistent with other terminals.
> So it gets my vote.

You can still put that line in your $HOME/.gnuplot file and it will be a
default then ;)

I'll try to implement that in the next days.

Best regards,

Timothée

Re: default size of wxt terminal

[Dmitri A. S. <das...@gm...>]

On 6/6/07, Timoth=E9e Lecomte <tim...@en...> wrote:
> > 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'

This is not quite "default" (default is the size that would be
used if nothing specified explicitly), but it does look as a nice
option to have, consistent with other terminals.
So it gets my vote.

> Best regards,
>
> Timoth=E9e
>

Sincerely,

Dmitri.
--

Re: "raise" for raise gnuplot console too?

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

On Wednesday 06 June 2007 19:07, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> > 
> > The core gnuplot code will never even 
> > see the <space> keypress event, so it never has the opportunity to decide
> > what terminal function to call.  The difficulty is all on the input end,
> > not the output end.
> > 
> gnuplot tells gplt_x11 to set handle_key_events equal to 0 when it does a 
> term init, where does the space key get lost?

As it is now, the space key does not get lost because gnuplot_x11 will 
always trap it and act on it.  But this makes it unavailable for "bind"
because that handling is done *instead of* sending back to gnuplot for
use either as a normal keystroke or as a trigger for some previously
bound hotkey action.

If we change it so that gnuplot_x11 does not treat it as a special case,
then it will get lost because:
 - gnuplot_x11 sees keystroke (happens to be <space> but nothing special about this)
 - gnuplot_x11 tosses a keystroke event notification into the pipe for gnuplot
   to read via X11_waitforinput()  
 - if the current terminal is x11, then as the stream of chars in the pipe
   is gradually read, this one will be directed to event_keypress() for 
   comparison against the list of "bind" actions
 - but if the current terminal is not x11, nobody will read from the pipe
   at all.  So it is "lost" in the pipe and is never delivered to event_keypress().

Patchset #1500654 "Continue to accept input from previous interactive terminal"
tries to work around this by continuing to use X11_waitforinput() as an input
source even if x11 is no longer the current terminal. It sort of works so long
as x11 is the only interactive terminal in the mix, but when last I looked at
it the result of switching to some other interactive terminal was to flood the
input stream with garbage characters.  I didn't debug it any further, and 
anyhow the wxt terminal driver has evolved since then.  So maybe the patch can
be polished up and made more acceptable.  If you want to work on the problem,
great, but please first explore that patchset and learn why it is necessary and
how it works.

-- 
Ethan A Merritt

Re: "raise" for raise gnuplot console too?

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

On Wednesday 06 June 2007 15:32, Daniel J Sebald wrote:
> would it make sense to have a command that raises the console? 
> > 
> > No.
> > That is the job of your window manager.  You can't even type the command
> > unless you have focus, and if you have focus you can hit whatever key
> > your window manager likes to use for this purpose.  It would be absurd to
> > argue that every application should implement this basic window management
> > function all over again, probably inconsistently with N other apps.
> 
> You may have a setup that works fine, but my point is that I've never had a 
> configuration (I use gnome, not kde) that gets away from requiring the mouse 
> click in some way as opposed to just staying with the keyboard.

Depends on the window manager. Gnome has a well-deserved reputation for
making it hard to change the default behaviour of anything, but if you
can't even change the focus policy that would be beyond absurd.
A quick Google search suggests it is actually quite easy:

Sawfish:
    Helix GNOME Control Center
	The selection box at the top determines how the mouse pointer sets focus.
	The default is to focus when the mouse clicks on the window. The other 
	choices are to focus only when the pointer is in the window ("enter-exit")
	and focus stays with the last window entered ("enter-only").

Enlightenment:
    Enlightenment configuration tool
	Keyboard focus follows
	These buttons determine how "focus" is selected by the actions of the mouse.
	The available settings are Mouse Pointer (focus follows mouse),
	Sloppy Pointer (focus follows mouse after a delay), and Pointer Clicks
	(focus is given to window on which a mouse clicks).

 
> My idea would be simply to do:
> 
>      term = set_term(c_token);
>      [snip]
>      if ({term INTERACTIVE OR HAS MOUSE SOMEHOW})
> 	guiterm = term;
> 
> and then for raise/lower and event input use 'guiterm' pointer rather than 
> 'term' pointer.

That doesn't work at all.  See previous frustrating discussion in which
I totally failed to explain why.  The core gnuplot code will never even
see the <space> keypress event, so it never has the opportunity to decide
what terminal function to call.  The difficulty is all on the input end,
not the output end.


-- 
Ethan A Merritt

Re: "raise" for raise gnuplot console too?

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

Ethan Merritt wrote:
> On Wednesday 06 June 2007 15:01, Daniel J Sebald wrote:
> 
>>I'm putting together a quick little patch of the ' ' and 'q' bindings for X11 
>>that we talked of the other day.
> 
> 
> I have a patch to remove 'q' processing all ready to go.
> You need not work on that one.
> 
> ' ' processing is a more difficult case, but there already patches on
> SourceForge that implement a possible replacement.  If you want to polish these
> up, have at it.
> 
> 	1474309    Bind <space> to builtin_raise in mouse.c
> 	1500654    Continue to accept input from previous interactive terminal
> 
> 
>>I then got to 
>>thinking about another related item we just talked about, i.e., plots taking 
>>focus away from the console.  The variation of this is that when one does "plot 
>>foo", the x11 window comes to the top, unless the user supplies the -noraise 
>>option; 
> 
> 
> I set a permanent resource
> 	 "gnuplot*raise:  off"
> 
> 
>>but perhaps the user generally likes the autoraise behavior.  In that  
>>case, would it make sense to have a command that raises the console?
> 
> 
> No.
> That is the job of your window manager.  You can't even type the command
> unless you have focus, and if you have focus you can hit whatever key
> your window manager likes to use for this purpose.  It would be absurd to
> argue that every application should implement this basic window management
> function all over again, probably inconsistently with N other apps.

But when I have x11 plot active, and type "plot x" again, the gnuplot console 
still retains focus, but the plot comes to the top and partially covers the 
console window.  So then again I'd have to move the mouse over the plot (and 
click) to give it focus, so that I can type the ' ' bar to bring the console 
up... or just mouse click in the gnuplot console window.

You may have a setup that works fine, but my point is that I've never had a 
configuration (I use gnome, not kde) that gets away from requiring the mouse 
click in some way as opposed to just staying with the keyboard.

It's not that important, but the extra mouse clicks do add up.

> 
> 
>>Or is the idea here that we can raise/lower even if the GUI based terminal is 
>>not currently the active one?
> 
> 
> That is indeed a difficulty. See the SourceForge patches.
> 

OK, I'll have a look at this one:

  	1500654    Continue to accept input from previous interactive terminal

My idea would be simply to do:

     term = set_term(c_token);
     [snip]
     if ({term INTERACTIVE OR HAS MOUSE SOMEHOW})
	guiterm = term;

and then for raise/lower and event input use 'guiterm' pointer rather than 
'term' pointer.

Dan

Re: "raise" for raise gnuplot console too?

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

On Wednesday 06 June 2007 15:01, Daniel J Sebald wrote:
> I'm putting together a quick little patch of the ' ' and 'q' bindings for X11 
> that we talked of the other day.

I have a patch to remove 'q' processing all ready to go.
You need not work on that one.

' ' processing is a more difficult case, but there already patches on
SourceForge that implement a possible replacement.  If you want to polish these
up, have at it.

	1474309    Bind <space> to builtin_raise in mouse.c
	1500654    Continue to accept input from previous interactive terminal

> I then got to 
> thinking about another related item we just talked about, i.e., plots taking 
> focus away from the console.  The variation of this is that when one does "plot 
> foo", the x11 window comes to the top, unless the user supplies the -noraise 
> option; 

I set a permanent resource
	 "gnuplot*raise:  off"

> but perhaps the user generally likes the autoraise behavior.  In that  
> case, would it make sense to have a command that raises the console?

No.
That is the job of your window manager.  You can't even type the command
unless you have focus, and if you have focus you can hit whatever key
your window manager likes to use for this purpose.  It would be absurd to
argue that every application should implement this basic window management
function all over again, probably inconsistently with N other apps.

> Or is the idea here that we can raise/lower even if the GUI based terminal is 
> not currently the active one?

That is indeed a difficulty. See the SourceForge patches.

-- 
Ethan A Merritt 

"raise" for raise gnuplot console too?

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

I'm putting together a quick little patch of the ' ' and 'q' bindings for X11 
that we talked of the other day.  (Remember, the idea is to disable the inherent 
gnuplot_x11 key event handling when the mouse is present.)  I then got to 
thinking about another related item we just talked about, i.e., plots taking 
focus away from the console.  The variation of this is that when one does "plot 
foo", the x11 window comes to the top, unless the user supplies the -noraise 
option; but perhaps the user generally likes the autoraise behavior.  In that 
case, would it make sense to have a command that raises the console?

There is the "raise {#}" for raising a GUI plot window.  Perhaps "raise console" 
would be of use.  However, that's too lengthy, one would like a very brief 
command for this sort of thing.

Anyway, rather than do this:

	if (lower) {
#ifdef OS2
	    pm_lower_terminal_window();
#endif
#ifdef X11
	    x11_lower_terminal_group();
#endif
#ifdef _Windows
	    win_lower_terminal_window();
#endif
#ifdef WXWIDGETS
	    wxt_lower_terminal_group();
#endif
	} else {
#ifdef OS2
	    pm_raise_terminal_window();
#endif
#ifdef X11
	    x11_raise_terminal_group();
#endif
#ifdef _Windows
	    win_raise_terminal_window();
#endif
#ifdef WXWIDGETS
	    wxt_raise_terminal_group();
#endif
	}

shouldn't we simply have a term api, even though non-GUI terms will have this 
empty, i.e.,

	if (lower)
	    term->order_plot(plot_num,0);
	else
	    term->order_plot(plot_num,inf);

Make the term api general in the sense that plot_num is the identifier of the 
plot and the second number is where in the displayer order to move it to.  (So 
zero is the lowest and inf the highest.)  Or will there never be a need for such 
general ordering, so just go with 0-bottom, 1-top?

Or is the idea here that we can raise/lower even if the GUI based terminal is 
not currently the active one?  (I'd argue there should be two different terminal 
pointers for such a use, i.e., 'termgui' equals most recent 'term' of the GUI 
variety.)

Dan

Re: Patches item #1729825 ready to go.

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

Petr Mikulik wrote:
>>OK, I think you will like this new patch (#1729825).  Type
>>
>>   help history
>>   help set history
> 
> 
> Yes, it works.
> 
> 
>>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
> 
> 
> Please add the to skip duplicated entries with the up-arrow. It does not 
> make sense to press up so many times, even though many same lines are in 
> history, does it?

After one sets

   set history condensed

the up arrow should only sequence through unique commands.  That is the way it 
works here.

> 
> BTW, bash does not store duplicated entries (try several times to type "ls" 
> and then "history"). Do you need it for gnuplot becase of possible 
> 	k=k+1
> commands?

For commands like

hist !87

which will execute the 87th line on the history stack.  If we keep moving the 
stack around "hist !87" might mean something different in the future.  Also, 
when saving the history of commands to a file, it is an exact record of what was 
typed.

Dan

Re: Patches item #1729825 ready to go.

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

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

Yes, it works.

> 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

Please add the to skip duplicated entries with the up-arrow. It does not 
make sense to press up so many times, even though many same lines are in 
history, does it?

BTW, bash does not store duplicated entries (try several times to type "ls" 
and then "history"). Do you need it for gnuplot becase of possible 
	k=k+1
commands?

---
PM