Menu
▾
▴
gnuplot-beta
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-04 22:26:27
|
On Monday 04 June 2007 15:19, Daniel J Sebald wrote:
> Daniel J Sebald wrote:
>
> > Well, it could be programmed that way [but what user keeps typing replot; replot
> > without making any changes in between? :-)]. The "do not put redundant commands
> > in the history stack" as gnuplot currently behaves has the same problem you're
> > pointing out.
>
> Keep in mind with an option
>
> set history {full|condensed} {quiet|numbered}
>
> it could be
>
> 1 foo = 35
> 2 plot x*foo
> 3 foo = 25
> 4 plot x*foo
> 5 history
> 6 foo = 20
> 7 plot x*foo
> 8 history
>
> or
>
> 1 foo = 35
> 3 foo = 25
> 6 foo = 20
> 7 plot x*foo
> 8 history
The logic here escapes me.
Why are the "plot x*foo" commands any more redundant than the
"foo = baz" commands? Even apart from the fact that one version
can produce 3 windows on my screen, and the other only 1, what
happens if "foo" has side-effects? These two sequences of
commands are not equivalent.
OK, I can understand not putting the "history" command on the
history stack. But everything else should remain visible.
--
Ethan A Merritt Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742
|
|
From: Daniel J S. <dan...@ie...> - 2007-06-04 22:37:54
|
Ethan Merritt wrote:
> On Monday 04 June 2007 15:19, Daniel J Sebald wrote:
>
>>Daniel J Sebald wrote:
>>
>>
>>>Well, it could be programmed that way [but what user keeps typing replot; replot
>>>without making any changes in between? :-)]. The "do not put redundant commands
>>>in the history stack" as gnuplot currently behaves has the same problem you're
>>>pointing out.
>>
>>Keep in mind with an option
>>
>> set history {full|condensed} {quiet|numbered}
>>
>>it could be
>>
>> 1 foo = 35
>> 2 plot x*foo
>> 3 foo = 25
>> 4 plot x*foo
>> 5 history
>> 6 foo = 20
>> 7 plot x*foo
>> 8 history
>>
>>or
>>
>> 1 foo = 35
>> 3 foo = 25
>> 6 foo = 20
>> 7 plot x*foo
>> 8 history
>
>
> The logic here escapes me.
> Why are the "plot x*foo" commands any more redundant than the
> "foo = baz" commands?
No argument here.
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.)
Even apart from the fact that one version
> can produce 3 windows on my screen, and the other only 1, what
> happens if "foo" has side-effects? These two sequences of
> commands are not equivalent.
>
> OK, I can understand not putting the "history" command on the
> history stack. But everything else should remain visible.
Could do that easily. In the above case everything is still on the stack, it's
just how the stack is displayed. I know you might not like it, but Petr does
and so might others.
Dan
|
|
From: Juergen W. <wie...@fr...> - 2007-06-05 11:44:59
|
> 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! Juergen |
|
From: Daniel J S. <dan...@ie...> - 2007-06-05 15:53:21
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-05 16:16:28
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2007-06-05 16:20:20
|
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 |
|
From: <pl...@pi...> - 2007-06-05 17:11:53
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2007-06-05 17:19:20
|
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 |
|
From: Juergen W. <wie...@fr...> - 2007-06-05 16:24:45
|
> > 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 |
|
From: Daniel J S. <dan...@ie...> - 2007-06-05 20:54:36
|
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 |
|
From: Juergen W. <wie...@fr...> - 2007-06-06 05:36:00
|
> 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 |
|
From: Daniel J S. <dan...@ie...> - 2007-06-06 09:43:45
|
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 |
|
From: Petr M. <mi...@ph...> - 2007-06-05 20:29:02
|
> > 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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-05 20:59:41
|
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
|
|
From: Petr M. <mi...@ph...> - 2007-06-05 21:15:59
|
> > > 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 |
|
From: Daniel J S. <dan...@ie...> - 2007-06-07 22:25:15
|
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 |
|
From: Petr M. <mi...@ph...> - 2007-06-08 06:51:20
|
> > 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 |
|
From: Daniel J S. <dan...@ie...> - 2007-06-08 07:18:56
|
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
|
|
From: <pl...@pi...> - 2007-06-08 14:09:23
|
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. ;) |
|
From: Daniel J S. <dan...@ie...> - 2007-06-08 16:04:56
|
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 |
|
From: <pl...@pi...> - 2007-06-08 16:19:38
|
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 ;) |
|
From: Daniel J S. <dan...@ie...> - 2007-06-08 16:26:14
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-08 16:50:44
|
On Friday 08 June 2007 09:26, Daniel J Sebald wrote: > > 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. I agree with <pl...@pi...> Please do not remove spaces when doing string comparisons. To do it correctly, you'd have to build a whole command parsing system into the history routines. -- Ethan A Merritt |
|
From: <pl...@pi...> - 2007-06-08 16:34:25
|
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. |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-08 18:17:51
|
On Friday 08 June 2007 11:11, Daniel J Sebald wrote:
>
> 2) Can we deprecate "historysize". (I've currently programmed "set history <n>"
> and "set historysize <n>" to be the same.)
??
I don't understand the question.
For as far back as I have sources for, "set history" has always been
shorthand for "set historysize". What, exactly, would you be deprecating?
If you just mean:
tables.c
182: - { "his$torysize", S_HISTORYSIZE },
182: + { "his$tory", S_HISTORYSIZE },
I don't see any point.
--
Ethan A Merritt
|
