Menu
▾
▴
gnuplot-beta
|
From: Allin C. <cot...@wf...> - 2013-10-21 20:50:22
|
I'm wondering when this changed, and whether the change was intentional: it used to be that if you did, say, set title 'Under_score' then (at least when using the wxt and x11 terminals) the text came out shown, with an underscore. Now (recent CVS[*]) The underscore produces a subscript 's' (in wxt and x11). It seems to me that it's more intuitive to have to do something special to get a superscript than having to do something special to get an underscore when you want one. [*] I can't say "current CVS" because when I try updating today I'm getting the message: Fatal error, aborting. anoncvs_gnuplot: no such system user -- Allin Cottrell Department of Economics Wake Forest University, NC |
|
From: Ethan A M. <merritt@u.washington.edu> - 2013-10-21 21:40:09
|
On Monday, 21 October, 2013 16:19:48 Allin Cottrell wrote:
> I'm wondering when this changed, and whether the change was intentional:
> it used to be that if you did, say,
>
> set title 'Under_score'
>
> then (at least when using the wxt and x11 terminals) the text came out
> shown, with an underscore. Now (recent CVS[*]) The underscore produces a
> subscript 's' (in wxt and x11).
Recent cvs defaults to enhanced text mode.
We can discuss whether this is a good thing or a bad thing, or a good thing
thing in principle that needs adjustment in practice.
This is not the sort of change in expectations that would be acceptable within
a minor version series (4.2 4.4 4.6) but seems to me OK to explore as we
head towards a major version 5 release.
The motivation for the change was to support "prettier" default formats for
axis tic labels. The new default format " %h" produces, for example,
1.2 x 10^6 as a label rather than 1.2e06
See discussion here:
https://sourceforge.net/p/gnuplot/patches/637/
and here
https://sourceforge.net/mailarchive/message.php?msg_id=31498730
It seemed kind of pointless to change the default format without also
enabling the enhanced text mode needed to produce it.
The enhanced/noenhanced attribute can still be applied to everything
e.g. set termoption noenhanced
or to an individual plot element
e.g set title "under_score" noenhanced
Some plot elements have always defaulted to noenhanced and continue
to do so. For instance autogenerated key entries default to noenhanced
so as to preserved underscores in a file name or function name.
Other plot elements, like "set title", have always defaulted to enhanced,
though of course this doesn't actually take effect unless enhanced text
mode is globally enabled.
I would have thought that underscores in user-supplied titles and labels
were more likely to be intended as subscripts than literals, but I could be wrong.
What would you prefer?
Revert the change in default terminal setting?
Revert the default state of just the "set title" command?
More obvious warnings that something has changed?
Some other combination?
FWIW, I've just noticed that the enhanced/noenhanced attribute of the
plot title is sticky, but which I mean that it isn't touched by a "reset" command.
>From the perspective of 4.6, that's a bug.
>From the perspective of your query, maybe it's a feature :-)
That is, you could put "set title noenhanced" in ~/.gnuplot and for your
own sessions it would always be that way unless explicitly changed.
> It seems to me that it's more intuitive to
> have to do something special to get a superscript than having to do
> something special to get an underscore when you want one.
Perhaps. I don't think it is intrinsically more or less intuitive than having to
escape backslashes, tabs, dollar signs, etc. It's just a matter of what you
are expecting.
Ethan
|
|
From: Jonathan T. <jt...@as...> - 2013-10-21 22:55:26
|
On Mon, 21 Oct 2013, Ethan A Merritt wrote:
> Recent cvs defaults to enhanced text mode.
[[...]]
> I would have thought that underscores in user-supplied titles and labels
> were more likely to be intended as subscripts than literals, but I could be wrong.
>
> What would you prefer?
> Revert the change in default terminal setting?
> Revert the default state of just the "set title" command?
> More obvious warnings that something has changed?
> Some other combination?
I was (am) under the impression that strings in "double quotes" use
enhanced mode if it's enabled, while strings in 'single quotes' never
use enhanced mode. Is this correct?
--
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"
|
|
From: Ethan A M. <sf...@us...> - 2013-10-21 22:41:59
|
On Monday, 21 October, 2013 15:36:23 Jonathan Thornburg wrote: > On Mon, 21 Oct 2013, Ethan A Merritt wrote: > > Recent cvs defaults to enhanced text mode. > [[...]] > > I would have thought that underscores in user-supplied titles and labels > > were more likely to be intended as subscripts than literals, but I could be wrong. > > > > What would you prefer? > > Revert the change in default terminal setting? > > Revert the default state of just the "set title" command? > > More obvious warnings that something has changed? > > Some other combination? > > I was (am) under the impression that strings in "double quotes" use > enhanced mode if it's enabled, while strings in 'single quotes' never > use enhanced mode. Is this correct? No. That has never been true that I recall. See "help quotes" Ethan |
|
From: <pl...@pi...> - 2013-11-18 23:27:58
|
Hi,
is there was way to stop gnuplot compacting history?
While I realise this is done to save storage space somewhere, this is a
constant annoyance.
I have an annoying problem where something keeps changing and I need to
track exactly what is happening.
In a shell I would use the history command to see _exactly_ what I did
and in what order to see what I have changed. I can see a true record of
my commands and repeat various parts of it until I reproduce and
understand the error.
with gnuplot this does not seem possible because history is forever
being revised and compacted and no longer retains a useful record. In
fact "history" does not provide the command history. It's more like
recent favourites, that often saves some typing but it is not the
command history.
I'm not that tight for space that I need to economise a few K. I'd much
rather save the few hours it's going to take me to find this problem
without a proper record of the commands I've issued to make the problem
repeatable.
Is there a means of preventing gnuplot from compacting the command
history be removing dupes?
regards, Peter.
|
|
From: Daniel J S. <dan...@ie...> - 2013-11-19 07:11:49
|
On 11/18/2013 02:58 PM, pl...@pi... wrote: > Hi, > > is there was way to stop gnuplot compacting history? Do you mean that the current command is not repeated in history if it matches the previous most recent command in the history buffer? My history looks pretty lengthy, but I do seem to recall a limit. Also, given it isn't recent history I can't look through it and conclude that it is complete. > While I realise this is done to save storage space somewhere, this is a > constant annoyance. > > I have an annoying problem where something keeps changing and I need to > track exactly what is happening. > > In a shell I would use the history command to see _exactly_ what I did > and in what order to see what I have changed. I can see a true record of > my commands and repeat various parts of it until I reproduce and > understand the error. > > with gnuplot this does not seem possible because history is forever > being revised and compacted and no longer retains a useful record. In > fact "history" does not provide the command history. It's more like > recent favourites, that often saves some typing but it is not the > command history. > > I'm not that tight for space that I need to economise a few K. I'd much > rather save the few hours it's going to take me to find this problem > without a proper record of the commands I've issued to make the problem > repeatable. > > Is there a means of preventing gnuplot from compacting the command > history be removing dupes? I recall some years ago writing a history patch that allowed it to be configured in a couple ways: one being complete history, one being more condensed. I might still have that around if you are interested, but I'd have to search for it and I'm sure it has conflicting hunks by now. Dan |
|
From: <pl...@pi...> - 2013-11-19 08:19:22
|
On 11/19/13 07:05, Daniel J Sebald wrote: > On 11/18/2013 02:58 PM, pl...@pi... wrote: >> Hi, >> >> is there was way to stop gnuplot compacting history? > > Do you mean that the current command is not repeated in history if it > matches the previous most recent command in the history buffer? > > My history looks pretty lengthy, but I do seem to recall a limit. Also, > given it isn't recent history I can't look through it and conclude that > it is complete. yes, it's a feature that dupes are eliminated. Just try repeating your last plot command a few times. Only the last occurrence will appear in history. I've been pulling my hair trying to work out why a fit command is producing different results. Having an accurate record of my command history would be an immense help. I'm currently having to cut and paste every command into a text file as I go along which is a serious PITA. Peter. > > >> While I realise this is done to save storage space somewhere, this is a >> constant annoyance. >> >> I have an annoying problem where something keeps changing and I need to >> track exactly what is happening. >> >> In a shell I would use the history command to see _exactly_ what I did >> and in what order to see what I have changed. I can see a true record of >> my commands and repeat various parts of it until I reproduce and >> understand the error. >> >> with gnuplot this does not seem possible because history is forever >> being revised and compacted and no longer retains a useful record. In >> fact "history" does not provide the command history. It's more like >> recent favourites, that often saves some typing but it is not the >> command history. >> >> I'm not that tight for space that I need to economise a few K. I'd much >> rather save the few hours it's going to take me to find this problem >> without a proper record of the commands I've issued to make the problem >> repeatable. >> >> Is there a means of preventing gnuplot from compacting the command >> history be removing dupes? > > I recall some years ago writing a history patch that allowed it to be > configured in a couple ways: one being complete history, one being more > condensed. I might still have that around if you are interested, but > I'd have to search for it and I'm sure it has conflicting hunks by now. > > Dan > |
|
From: Daniel J S. <dan...@ie...> - 2013-11-19 08:18:11
|
On 11/19/2013 01:03 AM, pl...@pi... wrote: > On 11/19/13 07:05, Daniel J Sebald wrote: >> On 11/18/2013 02:58 PM, pl...@pi... wrote: >>> Hi, >>> >>> is there was way to stop gnuplot compacting history? >> >> Do you mean that the current command is not repeated in history if it >> matches the previous most recent command in the history buffer? >> >> My history looks pretty lengthy, but I do seem to recall a limit. Also, >> given it isn't recent history I can't look through it and conclude that >> it is complete. > > yes, it's a feature that dupes are eliminated. Just try repeating your > last plot command a few times. Only the last occurrence will appear in > history. > > I've been pulling my hair trying to work out why a fit command is > producing different results. Having an accurate record of my command > history would be an immense help. > > I'm currently having to cut and paste every command into a text file as > I go along which is a serious PITA. That's sort of my modus operandi, except I edit in a file and either select and copy with the center mouse button or save and load the file. History is nice for tweaking commands and trial-and-error, but anything more than five commands deep is tough to edit. Nonetheless, history modifications might be worthwhile. Dan > > Peter. > > > >> >> >>> While I realise this is done to save storage space somewhere, this is a >>> constant annoyance. >>> >>> I have an annoying problem where something keeps changing and I need to >>> track exactly what is happening. >>> >>> In a shell I would use the history command to see _exactly_ what I did >>> and in what order to see what I have changed. I can see a true record of >>> my commands and repeat various parts of it until I reproduce and >>> understand the error. >>> >>> with gnuplot this does not seem possible because history is forever >>> being revised and compacted and no longer retains a useful record. In >>> fact "history" does not provide the command history. It's more like >>> recent favourites, that often saves some typing but it is not the >>> command history. >>> >>> I'm not that tight for space that I need to economise a few K. I'd much >>> rather save the few hours it's going to take me to find this problem >>> without a proper record of the commands I've issued to make the problem >>> repeatable. >>> >>> Is there a means of preventing gnuplot from compacting the command >>> history be removing dupes? >> >> I recall some years ago writing a history patch that allowed it to be >> configured in a couple ways: one being complete history, one being more >> condensed. I might still have that around if you are interested, but >> I'd have to search for it and I'm sure it has conflicting hunks by now. >> >> Dan >> > > -- Dan Sebald email: daniel(DOT)sebald(AT)ieee(DOT)org URL: http://www(DOT)dansebald(DOT)com |
|
From: <pl...@pi...> - 2013-11-19 10:09:34
|
On 11/19/13 09:17, Daniel J Sebald wrote: > On 11/19/2013 01:03 AM, pl...@pi... wrote: >> On 11/19/13 07:05, Daniel J Sebald wrote: >>> On 11/18/2013 02:58 PM, pl...@pi... wrote: >>>> Hi, >>>> >>>> is there was way to stop gnuplot compacting history? >>> >>> Do you mean that the current command is not repeated in history if it >>> matches the previous most recent command in the history buffer? >>> >>> My history looks pretty lengthy, but I do seem to recall a limit. Also, >>> given it isn't recent history I can't look through it and conclude that >>> it is complete. >> >> yes, it's a feature that dupes are eliminated. Just try repeating your >> last plot command a few times. Only the last occurrence will appear in >> history. >> >> I've been pulling my hair trying to work out why a fit command is >> producing different results. Having an accurate record of my command >> history would be an immense help. >> >> I'm currently having to cut and paste every command into a text file as >> I go along which is a serious PITA. > > That's sort of my modus operandi, except I edit in a file and either > select and copy with the center mouse button or save and load the file. > History is nice for tweaking commands and trial-and-error, but > anything more than five commands deep is tough to edit. Nonetheless, > history modifications might be worthwhile. > > Dan > > >> >> Peter. >> >> >> >>> >>> >>>> While I realise this is done to save storage space somewhere, this is a >>>> constant annoyance. >>>> >>>> I have an annoying problem where something keeps changing and I need to >>>> track exactly what is happening. >>>> >>>> In a shell I would use the history command to see _exactly_ what I did >>>> and in what order to see what I have changed. I can see a true >>>> record of >>>> my commands and repeat various parts of it until I reproduce and >>>> understand the error. >>>> >>>> with gnuplot this does not seem possible because history is forever >>>> being revised and compacted and no longer retains a useful record. In >>>> fact "history" does not provide the command history. It's more like >>>> recent favourites, that often saves some typing but it is not the >>>> command history. >>>> >>>> I'm not that tight for space that I need to economise a few K. I'd much >>>> rather save the few hours it's going to take me to find this problem >>>> without a proper record of the commands I've issued to make the problem >>>> repeatable. >>>> >>>> Is there a means of preventing gnuplot from compacting the command >>>> history be removing dupes? >>> >>> I recall some years ago writing a history patch that allowed it to be >>> configured in a couple ways: one being complete history, one being more >>> condensed. I might still have that around if you are interested, but >>> I'd have to search for it and I'm sure it has conflicting hunks by now. >>> >>> Dan >>> >> >> > For this to be of most use to me I would like to have (at least options on ) recording verbatim command history and history display without numbers, which would make copying to a runnable script file less laborious. m2c, Peter. |
|
From: Allin C. <cot...@wf...> - 2013-10-21 23:41:29
|
On Mon, 21 Oct 2013, Ethan A Merritt wrote: > On Monday, 21 October, 2013 16:19:48 Allin Cottrell wrote: >> I'm wondering when this changed, and whether the change was intentional: >> it used to be that if you did, say, >> >> set title 'Under_score' >> >> then (at least when using the wxt and x11 terminals) the text came out >> shown, with an underscore. Now (recent CVS[*]) The underscore produces a >> subscript 's' (in wxt and x11). > > Recent cvs defaults to enhanced text mode. Ah, I see. For my personal use of gnuplot I wouldn't have a problem with using the "noenhanced" keyword if I wanted a literal underscore. The practical issue is that gnuplot is used as the plotting engine for other programs and that, in general, the names of variables that could be plotted might well contain underscores; and the names of variables can easily find their way into titles. If this change goes into "production", coders (such as myself) who make "third-party" use of gnuplot will have to be careful to modulate gnuplot titling commands per version. > The motivation for the change was to support "prettier" default formats for > axis tic labels. The new default format " %h" produces, for example, > 1.2 x 10^6 as a label rather than 1.2e06 > See discussion here: > https://sourceforge.net/p/gnuplot/patches/637/ > and here > https://sourceforge.net/mailarchive/message.php?msg_id=31498730 > > It seemed kind of pointless to change the default format without also > enabling the enhanced text mode needed to produce it. OK. Pity the screenshots referenced in the text don't seem to be available. But on this matter I'm not fully persuaded in favor of the (more verbose and therefore more likely to cause interference in tighly tic'd plots) "1.2 x 10^6" versus "1.2e06". As you say in that exchange, "ugliness" in tic labels is mostly a matter of inconsistency (or excessive population of zeros). > What would you prefer? > Revert the change in default terminal setting? > Revert the default state of just the "set title" command? > More obvious warnings that something has changed? > Some other combination? Well, I don't want to stand in the way of progress ;-) I think I have to experiment a bit before offering an opinion. Allin Cottrell |
|
From: Ethan A M. <merritt@u.washington.edu> - 2013-10-22 00:00:33
|
On Monday, 21 October, 2013 19:41:20 Allin Cottrell wrote: > On Mon, 21 Oct 2013, Ethan A Merritt wrote: > > > On Monday, 21 October, 2013 16:19:48 Allin Cottrell wrote: > >> I'm wondering when this changed, and whether the change was intentional: > >> it used to be that if you did, say, > >> > >> set title 'Under_score' > >> > >> then (at least when using the wxt and x11 terminals) the text came out > >> shown, with an underscore. Now (recent CVS[*]) The underscore produces a > >> subscript 's' (in wxt and x11). > > > > Recent cvs defaults to enhanced text mode. > > Ah, I see. > > For my personal use of gnuplot I wouldn't have a problem with using > the "noenhanced" keyword if I wanted a literal underscore. The > practical issue is that gnuplot is used as the plotting engine for > other programs and that, in general, the names of variables that > could be plotted might well contain underscores; and the names of > variables can easily find their way into titles. Do those programs never use enhanced text mode? If they do, then this conflict already existed. If not, then wouldn't it be relatively painless for them to specify "noenhanced" when selecting a terminal? I imagine they already have a standard set of properties that they use for terminal selection. Ethan > > If this change goes into "production", coders (such as myself) who > make "third-party" use of gnuplot will have to be careful to > modulate gnuplot titling commands per version. > > > The motivation for the change was to support "prettier" default formats for > > axis tic labels. The new default format " %h" produces, for example, > > 1.2 x 10^6 as a label rather than 1.2e06 > > See discussion here: > > https://sourceforge.net/p/gnuplot/patches/637/ > > and here > > https://sourceforge.net/mailarchive/message.php?msg_id=31498730 > > > > It seemed kind of pointless to change the default format without also > > enabling the enhanced text mode needed to produce it. > > OK. Pity the screenshots referenced in the text don't seem to be > available. But on this matter I'm not fully persuaded in favor of > the (more verbose and therefore more likely to cause interference in > tighly tic'd plots) "1.2 x 10^6" versus "1.2e06". As you say in that > exchange, "ugliness" in tic labels is mostly a matter of > inconsistency (or excessive population of zeros). > > > What would you prefer? > > Revert the change in default terminal setting? > > Revert the default state of just the "set title" command? > > More obvious warnings that something has changed? > > Some other combination? > > Well, I don't want to stand in the way of progress ;-) I think I > have to experiment a bit before offering an opinion. > > Allin Cottrell |
|
From: <pl...@pi...> - 2013-10-22 21:32:36
|
On 10/21/13 23:36, Ethan A Merritt wrote: > On Monday, 21 October, 2013 16:19:48 Allin Cottrell wrote: >> I'm wondering when this changed, and whether the change was intentional: >> it used to be that if you did, say, >> >> set title 'Under_score' >> inspired by this discussion to use enhanced , I just found out that clicking on legend text in wxt no longer toggles line with this option on. unsetting it restores line toggle. set termoption noenhanced Is that intended Peter. |
|
From: sfeam <sf...@us...> - 2013-10-22 22:49:42
|
On Tuesday, 22 October 2013 06:45:10 PM pl...@pi... wrote: > On 10/21/13 23:36, Ethan A Merritt wrote: > > On Monday, 21 October, 2013 16:19:48 Allin Cottrell wrote: > >> I'm wondering when this changed, and whether the change was intentional: > >> it used to be that if you did, say, > >> > >> set title 'Under_score' > >> > > inspired by this discussion to use enhanced , I just found out that > clicking on legend text in wxt no longer toggles line with this option on. Sounds like a bug. An equivalent bug was fixed for the qt terminal a while ago. I didn't realize wxt suffered from the same. Ethan > > unsetting it restores line toggle. > > set termoption noenhanced > > Is that intended > > Peter. > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
|
From: Daniel J S. <dan...@ie...> - 2013-11-19 14:09:21
|
On 11/19/2013 04:01 AM, pl...@pi... wrote: > For this to be of most use to me I would like to have (at least options > on ) recording verbatim command history and history display without > numbers, which would make copying to a runnable script file less laborious. > > m2c, Peter. A quick search shows the history issue was around the 2005/2006 time frame, so it will take a while to jog my memory on that one. But, yes, I think suppressing the number was part of the mods I proposed. Also, avoiding the "his !his" recursion. Dan |
|
From: Petr M. <mi...@ph...> - 2013-11-19 15:24:58
|
>>>because history is forever being revised and compacted Oh yes, that was my first contribution to gnuplot! In 90's, long synchrotron experiments, and gnuplot history with one "plot ...", one "set log y", one "set nolog" a 50x "replot". >> For this to be of most use to me I would like to have (at least options >> on ) recording verbatim command history and history display without >> numbers, which would make copying to a runnable script file less laborious. It's already there exactly for the purpose you mention: history quiet see "help history". There is no option to switch "history" between "compact" and "full" recording. That could be probably added... --- Petr Mikulik |
|
From: <pl...@pi...> - 2013-11-19 20:08:43
|
On 11/19/13 16:24, Petr Mikulik wrote: > There is no option to switch "history" between "compact" and "full" > recording. That could be probably added... > > --- > Petr Mikulik that would be nice and presumably pretty trivial to just stop it doing the compacting. If anyone can point me at the relevant code I will have a poke. thx, Peter. |
|
From: Ethan M. <merritt@u.washington.edu> - 2013-12-14 07:59:07
|
On Tuesday, 19 November 2013 05:29:58 PM pl...@pi... wrote: > On 11/19/13 16:24, Petr Mikulik wrote: > > There is no option to switch "history" between "compact" and "full" > > recording. That could be probably added... > > > > --- > > Petr Mikulik > > that would be nice and presumably pretty trivial to just stop it doing > the compacting. > > > If anyone can point me at the relevant code I will have a poke. > > thx, Peter. I think you can replace the entire #ifdef clause at command.c(rlgets) lines 2718-2751 with the single line add_history(line); This works for all three cases of the #ifdef. Note that the built-in readline already acts this way. An intermediate option would be to suppress only duplication of the previous command. This is what the comments say the libedit version does, but the code seems to contradict that (I have not tried it). I think you could get that behavior by replacing found = history_search(line, -1); with found = 0; but again I have not tested. Ethan |
|
From: <pl...@pi...> - 2013-12-14 12:59:02
|
On 12/14/13 08:58, Ethan Merritt wrote: > On Tuesday, 19 November 2013 05:29:58 PM pl...@pi... wrote: >> On 11/19/13 16:24, Petr Mikulik wrote: >>> There is no option to switch "history" between "compact" and "full" >>> recording. That could be probably added... >>> >>> --- >>> Petr Mikulik >> >> that would be nice and presumably pretty trivial to just stop it doing >> the compacting. >> >> >> If anyone can point me at the relevant code I will have a poke. >> >> thx, Peter. > > I think you can replace the entire #ifdef clause at command.c(rlgets) lines 2718-2751 > with the single line > add_history(line); > > This works for all three cases of the #ifdef. > Note that the built-in readline already acts this way. > > An intermediate option would be to suppress only duplication of the > previous command. This is what the comments say the libedit version > does, but the code seems to contradict that (I have not tried it). > I think you could get that behavior by replacing > found = history_search(line, -1); > with > found = 0; > but again I have not tested. > > Ethan > Thanks Ethan, I'll try to find time to check that out. It's about time a did fresh build anyway. Peter. |
|
From: Ethan A M. <sf...@us...> - 2013-12-17 17:44:40
|
On Saturday, 14 December, 2013 09:10:12 pl...@pi... wrote:
> On 12/14/13 08:58, Ethan Merritt wrote:
> > On Tuesday, 19 November 2013 05:29:58 PM pl...@pi... wrote:
> >> On 11/19/13 16:24, Petr Mikulik wrote:
> >>> There is no option to switch "history" between "compact" and "full"
> >>> recording. That could be probably added...
> >>>
> >>> ---
> >>> Petr Mikulik
> >>
> >> that would be nice and presumably pretty trivial to just stop it doing
> >> the compacting.
> >>
> >>
> >> If anyone can point me at the relevant code I will have a poke.
> >>
> >> thx, Peter.
> >
> > I think you can replace the entire #ifdef clause at command.c(rlgets) lines 2718-2751
> > with the single line
> > add_history(line);
> >
> > This works for all three cases of the #ifdef.
> >
> > Ethan
> >
>
> Thanks Ethan,
>
> I'll try to find time to check that out. It's about time a did fresh
> build anyway.
I went ahead and added this to CVS since it's a trivial amount of code.
The new command to trigger it is "set history full".
Full syntax for new command is
set history {size <N>} {quiet|numbers} {full|trim} {default}
Examples
set history size N # replaces "set historysize N"
set history size -1 # replaces "unset historysize"
set history quiet # subsequent `history` commands will not show numbers
set history numbers # subsequent `history` commands will show numbers
set history trim # [old default] remove duplicate history entries
set history full # do not alter list by removing old duplicate entries
set history default # equivalent to "set history size 500, numbers, trim"
Tested under linux with libreadline, builtin readline, and BSD editline.
Not tested with the OSX mangled version of editline that masquerades as readline.
I dind't try for an option to suppress only duplication of the previous command.
It probably wouldn't be that much additional code if someone wants to pursue it.
Ethan
|
