Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2007-06-04 20:34:23
|
I consolidated all help/history patches into one patch #1729825 and it is ready to go. Give it a try. I guess the following would be the improvements: 1) Help now resolves keywords individually as opposed to a whole line of text (i.e., things like "help se ter post" are understood). The algorithm goes with most matching characters as the "winning" help line, and if there is a tie then it is the most number of whole matches. 2) History is much more robust to recursion detection. I went with an algorithm that will complain if every a command off the history stack is run more than once in a series of history recalls. For example plot x; hist !plot plot x; hist !plot is recursive on the second implementation because it will come back to the same line. This uses dynarray to keep track of the recalled history, which actually turns out to be less code. 3) History now has recall by number, e.g., "hist !123". A bit tricky to implement given the shuffling behavior we have, but I think I've got it. (No sense in numbering the stack if we can't recall by number.) Note, as far as shuffling it would be easy to make an option for that. I point this out because if someone is using recall by number, shuffling of the stack can cause a problem. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-04 21:15:03
|
On Monday 04 June 2007 13:31, Daniel J Sebald wrote: > 1) Help now resolves keywords individually as opposed to a whole line of text > (i.e., things like "help se ter post" are understood). The algorithm goes with > most matching characters as the "winning" help line, and if there is a tie then > it is the most number of whole matches. Sounds good. Let's see if it survives stress-testing. > 2) History is much more robust to recursion detection. I went with an algorithm > that will complain if every a command off the history stack is run more than > once in a series of history recalls. For example > > plot x; hist !plot > plot x; hist !plot I cannot imagine anyone having a legitimate reason for issuing such a command. Can't we just forbid commands of the form "hist !command" unless they are the first and only thing on the line? In fact, I can't think of a reason to ever allow a "hist" command except at the beginning of a line. Why would you want to do this? > 3) History now has recall by number, e.g., "hist !123". A bit tricky to > implement given the shuffling behavior we have, but I think I've got it. (No > sense in numbering the stack if we can't recall by number.) Does that number stay constant? I.e., if I go to the trouble of figuring out that some complicated upstream command was "!123", will that still be true 10 minutes later after various intervening commands? If not, then this option is a non-starter. > Note, as far as shuffling it would be easy to make an option for that. I point > this out because if someone is using recall by number, shuffling of the stack > can cause a problem. Er, why are we shuffling the stack? -- Ethan A Merritt |
|
From: Daniel J S. <dan...@ie...> - 2007-06-04 21:35:04
|
Ethan Merritt wrote:
> On Monday 04 June 2007 13:31, Daniel J Sebald wrote:
>
>>1) Help now resolves keywords individually as opposed to a whole line of text
>>(i.e., things like "help se ter post" are understood). The algorithm goes with
>>most matching characters as the "winning" help line, and if there is a tie then
>>it is the most number of whole matches.
>
>
> Sounds good. Let's see if it survives stress-testing.
>
>
>>2) History is much more robust to recursion detection. I went with an algorithm
>>that will complain if every a command off the history stack is run more than
>>once in a series of history recalls. For example
>>
>>plot x; hist !plot
>>plot x; hist !plot
>
>
> I cannot imagine anyone having a legitimate reason for issuing such a command.
> Can't we just forbid commands of the form "hist !command" unless they are the
> first and only thing on the line?
>
> In fact, I can't think of a reason to ever allow a "hist" command except
> at the beginning of a line. Why would you want to do this?
Well, you're changing the target then. Before it was suggested to ignore
"history !hist" if it is in the middle, so that the rest of the line could be
executed. Limiting history in that way, i.e., just first command, seems like
unnecessary conditional code. That is, there's little difference between
myparam=50; hist !plot
and
myparam=50
hist !plot
Why should the user be restricted from using the first syntax and not the second?
Even still, once we put conditional restrictions in this way, all of a sudden
the coding becomes worse than this general, more robust idea. The general
approach just simply identifies an recursive behavior and lets the user figure
out what it was.
>
>
>>3) History now has recall by number, e.g., "hist !123". A bit tricky to
>>implement given the shuffling behavior we have, but I think I've got it. (No
>>sense in numbering the stack if we can't recall by number.)
>
>
> Does that number stay constant?
Yes (but no), it tries to maintain the same numbered sequence, and it would if
not for the shuffling.
I.e., if I go to the trouble of figuring
> out that some complicated upstream command was "!123", will that still be
> true 10 minutes later after various intervening commands? If not, then
> this option is a non-starter.
> >>Note, as far as shuffling it would be easy to make an option for that. I point
>>this out because if someone is using recall by number, shuffling of the stack
>>can cause a problem.
>
>
> Er, why are we shuffling the stack?
I'm not a fan of it, but the idea was to condense the stack by removing
redundancy. ("shuffling" is my expression for taking out redundant history.)
The stack stays more condensed that way so one can see more non-redundant commands.
Actually, another way of doing this, rather than shuffling around the stack,
would be to rewright the "write_history_n" routine so that it keeps all
numbering the same, but doesn't display those numbers in the stack that are the
same as some command higher than it. (Wish I would have thought of that
sooner.) To keep it from being an order N^2 sort of thing, we'd simply search
the stack in history_add() for similar commands and keep a pointer along as part
of the data for the history entry.
Would that work better? (I like it.)
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2007-06-04 21:54:53
|
Let me toss this idea to Petr... What would you think of instead of removing items from the stack, say the user types foo = 35 plot x*foo foo = 25 plot x*foo history foo = 20 plot x*foo history and the result of the final history might be 1 foo = 35 2 plot x*foo 3 foo = 25 6 foo = 20 8 history For a more condensed appearance? Everything could function just as it normally does as this might simply be a display option set history condensed (btw, "quiet" should also be an option... who wants to keep type "history quiet 10"?) Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-04 22:08:35
|
On Monday 04 June 2007 14:54, Daniel J Sebald wrote: > Let me toss this idea to Petr... What would you think of instead of removing > items from the stack, say the user types > > foo = 35 > plot x*foo > foo = 25 > plot x*foo > history > foo = 20 > plot x*foo > history > > and the result of the final history might be > > 1 foo = 35 > 2 plot x*foo > 3 foo = 25 > 6 foo = 20 > 8 history > > For a more condensed appearance? I don't like it at all. If I want the history, then I want it to show all the commands I issued, in the order they were issued. The condensed form you show above would not let me determine from the history command what was the value of 'foo' when I made the most recent plot. It's one thing to remove a series of "replot; replot; replot..." commands, since nothing changes between them. But your example is hiding important changes. -- Ethan A Merritt |
|
From: Petr M. <mi...@ph...> - 2007-06-04 22:00:05
|
> Let me toss this idea to Petr... What would you think of instead of removing > items from the stack, say the user types > > foo = 35 > plot x*foo > foo = 25 > plot x*foo > history > foo = 20 > plot x*foo > history > > and the result of the final history might be > > 1 foo = 35 > 2 plot x*foo > 3 foo = 25 > 6 foo = 20 > 8 history no, plot x*foo will be the last. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2007-06-04 22:08:45
|
Petr Mikulik wrote: >>Let me toss this idea to Petr... What would you think of instead of removing >>items from the stack, say the user types >> >>foo = 35 >>plot x*foo >>foo = 25 >>plot x*foo >>history >>foo = 20 >>plot x*foo >>history >> >>and the result of the final history might be >> >> 1 foo = 35 >> 2 plot x*foo >> 3 foo = 25 >> 6 foo = 20 >> 8 history > > > no, plot x*foo will be the last. You're right, that's what I indended. Actually, the "history" would still be last as we are placing stuff in history, then processing, so it'd be 1 foo = 35 3 foo = 25 6 foo = 20 7 plot x*foo 8 history We place stuff in history first before processing so that the user can recall a command even if it failed (because of a one letter typo or something). I can make that change in the patch. I like that approach. Dan |
|
From: Daniel J S. <dan...@ie...> - 2007-06-04 22:14:29
|
Ethan Merritt wrote: > On Monday 04 June 2007 14:54, Daniel J Sebald wrote: > >>Let me toss this idea to Petr... What would you think of instead of removing >>items from the stack, say the user types >> >>foo = 35 >>plot x*foo >>foo = 25 >>plot x*foo >>history >>foo = 20 >>plot x*foo >>history >> >>and the result of the final history might be >> >> 1 foo = 35 >> 2 plot x*foo >> 3 foo = 25 >> 6 foo = 20 >> 8 history >> >>For a more condensed appearance? > > > I don't like it at all. > > If I want the history, then I want it to show all the > commands I issued, in the order they were issued. The condensed > form you show above would not let me determine from the history > command what was the value of 'foo' when I made the most recent > plot. It's one thing to remove a series of "replot; replot; replot..." > commands, since nothing changes between them. But your example > is hiding important changes. 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. Dan |
|
From: Daniel J S. <dan...@ie...> - 2007-06-04 22:19:56
|
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
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-04 22:22:51
|
On Monday 04 June 2007 15:14, Daniel J Sebald wrote: > > I don't like it at all. > > > > If I want the history, then I want it to show all the > > commands I issued, in the order they were issued. The condensed > > form you show above would not let me determine from the history > > command what was the value of 'foo' when I made the most recent > > plot. It's one thing to remove a series of "replot; replot; replot..." > > commands, since nothing changes between them. But your example > > is hiding important changes. > > Well, it could be programmed that way [but what user keeps typing replot; replot > without making any changes in between? :-)]. Anyone who closes the plot window to do something else for a while? To get it back again, he types "replot". I do this all the time. > The "do not put redundant commands > in the history stack" as But your example has no redundant commands! You are erasing commands that had a real effect on the contents of my screen. > gnuplot currently behaves has the same problem you're > pointing out. Ah, so maybe that's the reason I always found history to be unreliable. 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. -- Ethan A Merritt |
|
From: Daniel J S. <dan...@ie...> - 2007-06-04 22:30:17
|
Ethan Merritt wrote: > On Monday 04 June 2007 15:14, Daniel J Sebald wrote: > >>>I don't like it at all. >>> >>>If I want the history, then I want it to show all the >>>commands I issued, in the order they were issued. The condensed >>>form you show above would not let me determine from the history >>>command what was the value of 'foo' when I made the most recent >>>plot. It's one thing to remove a series of "replot; replot; replot..." >>>commands, since nothing changes between them. But your example >>>is hiding important changes. >> >>Well, it could be programmed that way [but what user keeps typing replot; replot >>without making any changes in between? :-)]. > > > Anyone who closes the plot window to do something else for a while? > To get it back again, he types "replot". I do this all the time. True. >>The "do not put redundant commands >>in the history stack" as > > > But your example has no redundant commands! You are erasing > commands that had a real effect on the contents of my screen. Just going with current behavior (and as I pointed out, it made a tough time of keeping track of what was tossed out). >>gnuplot currently behaves has the same problem you're >>pointing out. > > > Ah, so maybe that's the reason I always found history to be > unreliable. 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. Yes, that's 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'll put a patch together this evening with options (default numbered and non-condensed). Simple changes. So, would you also want that if the current command is exactly the same as the previous (and just the previous, no later) *then* it is not put in the history stack? Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-04 22:39:58
|
On Monday 04 June 2007 15:30, Daniel J Sebald wrote: > Ethan Merritt wrote: > > > I strongly request that the default history behaviour is to leave > > all my commands in place. I would consider this a bug-fix. > > I'll put a patch together this evening with options (default numbered and > non-condensed). Simple changes. > > So, would you also want that if the current command is exactly the same as the > previous (and just the previous, no later) *then* it is not put in the history > stack? I want it to behave like the csh [and tcsh and bash] history commands. Go with what the users expect. -- Ethan A Merritt |
|
From: Petr M. <mi...@ph...> - 2007-06-05 06:32:58
|
> 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. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2007-06-05 15:52:20
|
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
|
|
From: <pl...@pi...> - 2007-06-05 17:36:27
|
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.
;)
|
|
From: Petr M. <mi...@ph...> - 2007-06-05 20:20:14
|
> 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 |
|
From: Daniel J S. <dan...@ie...> - 2007-06-06 09:39:09
|
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
|
|
From: Petr M. <mi...@ph...> - 2007-06-06 21:36:57
|
> 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 |
|
From: Daniel J S. <dan...@ie...> - 2007-06-06 21:48:43
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-07 22:31:44
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2007-06-07 22:53:39
|
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
|
|
From: Petr M. <mi...@ph...> - 2007-06-08 06:28:39
|
> > 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 |
|
From: Daniel J S. <dan...@ie...> - 2007-06-08 07:06:41
|
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
|
|
From: Petr M. <mi...@ph...> - 2007-06-08 07:14:47
|
> > "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 |
|
From: Daniel J S. <dan...@ie...> - 2007-06-08 07:35:10
|
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 |
