Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2005-06-21 21:35:42
|
It seems the 'help exit' does not say anything that it exits gnuplot when in interactive? What about this text: When running gnuplot in interactive mode, the commands `exit` and `quit` quit your gnuplot session. When reading a command file (script), the commands `exit` and `quit` and the END-OF-FILE character will exit this file immediately and `load` the next one. See "help batch/interactive" for more details. Each of these commands will clear the output device (as does the `clear` command) before exiting. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-21 22:36:59
|
On Tuesday 21 June 2005 02:35 pm, Petr Mikulik wrote: > It seems the 'help exit' does not say anything that it exits gnuplot when in > interactive? There is nothing special about interactive sessions. If you would like to clarify the help text, I suggest something like The commands `exit` and `quit` terminate input from the current input stream. This is true for terminal, pipe, and file input. If input streams are nested, then input will continue to be accepted from the parent stream. When the top level stream is closed, the program itself will exit. To demonstrate that "interactive" is not relevant to this, try the following: gnuplot plot sin(x) load '/dev/tty' plot cos(x) load '/dev/tty' plot x exit history exit hisory exit You will find that it takes three `exits` to get back to the shell from this nested interactive session. > What about this text: > > When running gnuplot in interactive mode, the commands `exit` and `quit` > quit your gnuplot session. > > When reading a command file (script), the commands `exit` and `quit` and > the END-OF-FILE character will exit this file immediately and `load` the > next one. > > See "help batch/interactive" for more details. > > Each of these commands will clear the output device (as does the `clear` > command) before exiting. > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2005-06-22 20:50:54
Attachments:
help_22jun2005.patch
|
Ethan Merritt wrote:
> On Tuesday 21 June 2005 02:35 pm, Petr Mikulik wrote:
>
>>It seems the 'help exit' does not say anything that it exits gnuplot when in
>>interactive?
Speaking of "help", attached is a short patch for displaying the topic at the
very beginning of help, e.g.,
gnuplot> help gnuplot
TOPIC: gnuplot-defined variables
The variable `pi` is defined to be pi, see
print pi
[...]
I accidentally typed "help gnuplot" and then found it disorienting that what
returned was actually help about variables.
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-22 21:07:07
|
On Wednesday 22 June 2005 01:54 pm, Daniel J Sebald wrote: > > Speaking of "help", attached is a short patch for displaying the topic at the > very beginning of help, e.g., > > gnuplot> help gnuplot > TOPIC: gnuplot-defined variables > The variable `pi` is defined to be pi, see > print pi Don't you think a more reasonable fix would be to add a line ?gnuplot at the start of some more appropraite help section? -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From:
<br...@ph...> - 2005-06-23 20:39:11
|
Daniel J Sebald wrote: > Speaking of "help", attached is a short patch for displaying the topic > at the very beginning of help, e.g., > > gnuplot> help gnuplot > TOPIC: gnuplot-defined variables Good idea. But let me point out a detail: at least for gih help, some of the node already *have* such a display: it's shown after you come out of the pager, and it asks you about a choice of sub-node. It may not be a major issue if the title is displayed twice, but it may be a better idea to print it always at the same place (which would thus have to be at the end). |
|
From: Daniel J S. <dan...@ie...> - 2005-06-23 21:13:23
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: >=20 >> Speaking of "help", attached is a short patch for displaying the topic= =20 >> at the very beginning of help, e.g., >> >> gnuplot> help gnuplot >> TOPIC: gnuplot-defined variables >=20 >=20 > Good idea. But let me point out a detail: at least for gih help, > some of the node already *have* such a display: it's shown after you=20 > come out of the pager, and it asks you about a choice of sub-node. Oh yeah. Some things to worry about there. > It may not be a major issue if the title is displayed twice, but it may= =20 > be a better idea to print it always at the same place (which would thus= =20 > have to be at the end). Eh, displaying multiple times isn't professional looking. In some way, w= e can=20 think of the topic as a "header". As you point out, we really don't want= to=20 print it as part of the help text. Rather, what would be nice, if possib= le, is=20 if the pager had it's own kind of header, e.g., at the top of the termina= l is=20 the header in bold while the text scrolls underneath it. Is that possibl= e? Dan |
|
From:
<br...@ph...> - 2005-06-23 21:18:15
|
Daniel J Sebald wrote: > Eh, displaying multiple times isn't professional looking. In some way, > we can think of the topic as a "header". As you point out, we really > don't want to print it as part of the help text. Rather, what would be > nice, if possible, is if the pager had it's own kind of header, e.g., at > the top of the terminal is the header in bold while the text scrolls > underneath it. Is that possible? No --- if only because we have no control over what the $PAGER chosen by the user might be. IIRC we have our own fall-back pager implementation in which such things could be done, but I would have to strictly oppose any change that made gnuplot ignore $PAGER, or only work "properly" if $PAGER wasn't set. |
|
From: Daniel J S. <dan...@ie...> - 2005-06-23 21:28:28
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: >=20 >> Eh, displaying multiple times isn't professional looking. In some=20 >> way, we can think of the topic as a "header". As you point out, we=20 >> really don't want to print it as part of the help text. Rather, what=20 >> would be nice, if possible, is if the pager had it's own kind of=20 >> header, e.g., at the top of the terminal is the header in bold while=20 >> the text scrolls underneath it. Is that possible? >=20 >=20 > No --- if only because we have no control over what the $PAGER chosen b= y=20 > the user might be. IIRC we have our own fall-back pager implementation= =20 > in which such things could be done, but I would have to strictly oppose= =20 > any change that made gnuplot ignore $PAGER, or only work "properly" if=20 > $PAGER wasn't set. Yes, I suppose. Then an orderly convention would be the only alternative= . It=20 might mean going through the gnuplot.doc and clearing out first lines of = help=20 that say, e.g., "gnuplot-variable":... that is, if there are any. But seriously, programming alternate behavior wouldn't be that difficult.= If=20 gnuplot's pager is active then don't print the first (or last) line "TOPI= C:=20 <help>" but create a header if possible. Not suggesting that, just argui= ng it=20 would be easy. And possibly, as the pager seems like a configurable thin= g=20 already, perhaps an environment variable could be set to turn off the pri= nting=20 of "TOPIC: <help>". You'd think that advanced pagers would have a header= =20 convention, but maybe not. Dan |
|
From: Daniel J S. <dan...@ie...> - 2005-06-23 21:34:20
|
Daniel J Sebald wrote: > But seriously, programming alternate behavior wouldn't be that > difficult. If gnuplot's pager is active then don't print the first (or > last) line "TOPIC: <help>" but create a header if possible. Not > suggesting that, just arguing it would be easy. And possibly, as the > pager seems like a configurable thing already, perhaps an environment > variable could be set to turn off the printing of "TOPIC: <help>". > You'd think that advanced pagers would have a header convention, but > maybe not. Octave has two modes of help and both appear to simply print information at the beginning of the help; no header... not worth the effort. Dan |
|
From: Petr M. <mi...@ph...> - 2005-06-24 17:05:17
|
>> Speaking of "help", attached is a short patch for displaying the topic at >> the very beginning of help, e.g., >> >> gnuplot> help gnuplot >> TOPIC: gnuplot-defined variables I really like this. I would prefer this title: GNUPLOT HELP TOPIC: x11 x11_fonts\n Typing sth like "help x11 x11" will display where your abbreviation points to. > Good idea. But let me point out a detail: at least for gih help, > some of the node already *have* such a display: it's shown after you come out > of the pager, and it asks you about a choice of sub-node. I don't see any... --- PM |
|
From:
<br...@ph...> - 2005-06-24 17:21:46
|
Petr Mikulik wrote:
>> Good idea. But let me point out a detail: at least for gih help,
>> some of the node already *have* such a display: it's shown after you
>> come out of the pager, and it asks you about a choice of sub-node.
> I don't see any...
Then you didn't look in the right place. Here's the end of "help fit"
in a .gih-based version, as an example:
Subtopics available for fit:
adjustable_parameters beginners_guide control
error error_estimate errors guide
multi-branch parameters starting_values tips
Subtopic for fit: <input cursor here>
If you type "tips" here, it'll put you to the same node otherwise
reached by "help fit tips".
In Windows, you get a collection of clickable links to the sub-nodes
instead.
|
|
From: Petr M. <mi...@ph...> - 2005-06-24 17:58:23
|
> Then you didn't look in the right place. Here's the end of "help fit" > in a .gih-based version, as an example: > > Subtopics available for fit: > adjustable_parameters beginners_guide control > error error_estimate errors guide > multi-branch parameters starting_values tips > > Subtopic for fit: <input cursor here> > > If you type "tips" here, it'll put you to the same node otherwise reached by > "help fit tips". Yes, but this table is for few items, and it appers on the button, as an inherent part of the particular help text. This cannot be considered as a common header what Daniel has proposed. > In Windows, you get a collection of clickable links to the sub-nodes instead. It does not use .gih, but its own GUI-driven help file. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2005-06-30 05:02:46
|
Petr Mikulik wrote: >> Then you didn't look in the right place. Here's the end of "help fit" >> in a .gih-based version, as an example: >> >> Subtopics available for fit: >> adjustable_parameters beginners_guide control >> error error_estimate errors guide >> multi-branch parameters starting_values tips >> >> Subtopic for fit: <input cursor here> >> >> If you type "tips" here, it'll put you to the same node otherwise >> reached by "help fit tips". > > > Yes, but this table is for few items, and it appers on the button, as an > inherent part of the particular help text. This cannot be considered as > a common header what Daniel has proposed. It sounds as though this patch should be put on SourceForge for further consideration. Dan |
|
From:
<br...@ph...> - 2005-06-30 08:38:13
|
Daniel J Sebald wrote: > It sounds as though this patch should be put on SourceForge for further > consideration. Either that, or put it into CVS right away --- and let the users tell us how they like it. Experience so far has been that we will get essentially zero feedback for patches until they are in CVS, and full feedback only after the eventual release. |
|
From: Petr M. <mi...@ph...> - 2005-06-23 14:45:05
|
I propose this text: The commands `exit` and `quit`, as well as the END-OF-FILE character (usually Ctrl-D) terminate input from the current input stream: terminal session, pipe, and file input (pipe). If input streams are nested (inherited `load` scripts), then reading will continue in the parent stream. When the top level stream is closed, the program itself will exit. See "help batch/interactive" for more details. Each of these commands will clear the output device (as does the `clear` command) before exiting. BUT: Is the last point right??? Definitely not for -persist option! --- PM |
|
From: Robert H. <en...@no...> - 2005-06-22 09:57:26
|
On Tue, 2005-06-21 at 23:35 +0200, Petr Mikulik wrote: > When running gnuplot in interactive mode, the commands `exit` and `quit` > quit your gnuplot session. > > When reading a command file (script), the commands `exit` and `quit` and > the END-OF-FILE character will exit this file immediately and `load` the > next one. > > See "help batch/interactive" for more details. > > Each of these commands will clear the output device (as does the `clear` > command) before exiting. Isn't ^D considered to be END-OF-FILE for interactive input? It certainly works, so I don't see the distinction between interactive and command file. Rob -- Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
|
From: Daniel J S. <dan...@ie...> - 2005-06-22 23:52:14
|
Ethan Merritt wrote: > On Wednesday 22 June 2005 01:54 pm, Daniel J Sebald wrote: > >>Speaking of "help", attached is a short patch for displaying the topic at the >>very beginning of help, e.g., >> >>gnuplot> help gnuplot >>TOPIC: gnuplot-defined variables >> The variable `pi` is defined to be pi, see >> print pi > > > > Don't you think a more reasonable fix would be to add a line > ?gnuplot > at the start of some more appropraite help section? Yes and no. Whether a help for "gnuplot" is needed is even questionable. But the problem is accounting for all the possible things a user could type expecting to see help for. In most cases gnuplot would say "Sorry, no help", but occassionally the user will by chance choose some characters that match a key. Sure, correcting by filling a hole in gnuplot.doc will work, but that's a potentially never ending game, isn't it? It's not that critical. Dan |
|
From: Petr M. <mi...@ph...> - 2005-06-23 14:48:08
|
>>> gnuplot> help gnuplot >>> TOPIC: gnuplot-defined variables Good idea. Will it list all options (those "?" lines in gnuplot.doc) for the given topic? > Whether a help for "gnuplot" is needed is even questionable. gnuplot.doc many times cites `gnuplot` > but occassionally the user will by chance choose some characters that > match a key. Exactly, it's good to know what I'm actually reading. The GUI hypertext help readers show this, but not the default command line help browser. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-24 01:01:03
|
On Thursday 23 June 2005 07:44 am, Petr Mikulik wrote: > I propose this text: > > > The commands `exit` and `quit`, as well as the END-OF-FILE character > (usually Ctrl-D) terminate input from the current input stream: terminal > session, pipe, and file input (pipe). > > If input streams are nested (inherited `load` scripts), then reading will > continue in the parent stream. When the top level stream is closed, the > program itself will exit. > > See "help batch/interactive" for more details. Looks OK to me. > Each of these commands will clear the output device (as does the `clear` > command) before exiting. > BUT: Is the last point right??? Definitely not for -persist option! I see nowhere in the code that calls clear_command() except for an explicit `clear` from the command line. So I think this is not right. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Dave D. <dde...@es...> - 2005-06-24 17:35:05
|
Ethan Merritt <merritt@u.washington.edu> writes: > On Thursday 23 June 2005 07:44 am, Petr Mikulik wrote: >> I propose this text: >> >> >> The commands `exit` and `quit`, as well as the END-OF-FILE character >> (usually Ctrl-D) terminate input from the current input stream: terminal >> session, pipe, and file input (pipe). >> >> If input streams are nested (inherited `load` scripts), then reading will >> continue in the parent stream. When the top level stream is closed, the >> program itself will exit. >> >> See "help batch/interactive" for more details. > > Looks OK to me. > Just trying now (inspired by earlier suggested text), gnuplot can have a sequence of top-level streams. $ gnuplot <(echo print 3) - <(echo print 4) 3 gnuplot> print 6*7 42 gnuplot> exit 4 dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
