Apparently, there are two seaprate issues: 1. whether the history should store only executed commands 2. whether the history (or scratchpad) should be implemented as a variale or as a builtin command.
On 9/22/06, Martin Bähr <[EMAIL PROTECTED]> wrote: > On Fri, Sep 22, 2006 at 04:11:28PM -0400, Philip Ganchev wrote: [...] > > How about using a delete buffer for it -- if the command line had > > multiple buffers, you could paste from them in turn. Wouldn't this be > > simpler? > > for hundreds of commands? Yes. The buffers I was suggesting work similar to the current history of (hundreds of) executed commands. The difference is the command combination used to access the entries. I was suggesting that there should be one for executed commands and another for manually saved text. You think they should be accessed sequentially using the same key combo. Each time you would get a command that was executed, and other times just text that was "saved" earlier. One key combo becomes easier to remember, but becomes more difficult when there are many entries (see below). [...] > is how i can access it. and that access is provided by the current > history mechanism, namely browsing and searching commands with up/down > arrow keys. > > any other way of accessing it would be harder. > > > With your proposal, the non-executed text would be stored together > > with hundreds of executed commands, in the order of writing on the > > command line. How would you fish it out when you need it -- string > > search? > > i don't understand that question. > i would access it just like current history items. Say I start writing a scipt to parse the output of the "dbus-launch" program. I need to know more about the output, so I save the incomplete script. Then I execute ``dbus-launch``, read the dbus-launch manual, execute ``dbus-launch --csh-syntax``, read the manual again, read http://www.freedesktop.org/software/dbus; read some init files, read other manuals, edit some files, read documentation. Now I want to access that saved string, which is buried under 39 entries in the scratchpad. Do I have to try to recall strings in the incomplete script, in order to search for it using string search? Or should I iterate through the scratchpad entries (39 times) till I recognize the script? Neither of these is convenient. It is better to have a separate way of accessing the saved text, because presumably I remember *that* I saved what I need. That may require iterating through only several entries till you reach the script. And that can also be made searchable. This kind of situation occurs to me very often, and was my motivation for wanting to be able to save many entries of text. And I think it was your and James's motivation too. What about when I start writing a command, then I realize that I have to cut part of it and want to be able to paste it later. Currently, only the last string to be cut (deleted) is saved. If this text is stored in the scratchpad, how would I access it? If it is stored in a kill-ring (as currently), don't you think it is a bit confusing to have two "places" for storing cut text? I think users would spend time choosing the right one to use in each case. This is user response is documented (for example) in the book "The Humane Interface" by Jef Raskin, on the basis of experiments with users. > > How would you know whether a given entry was actually executed? How > > would you get a list of all executed commands, if you needed? > > i don't generally need that information. > if i do need it then for me it would only be useful if the order of > commands is kept intact (which is not the case, because doubles are removed) > and i also would want it in a permanent log with timestamps and maybe > even the return value. Those certainly can't be provided by a variable (maybe several variables). But they can be provided by a builtin. > the current history does not tell me the order nor does it say how often > or when a command has been executed. so it is not useful for statistics > or any other things. I was not thinking of statistics but of this scenario, which I think occurs very often to users. I iterate through the process of writing and testing some commands till I get them right. Now I want to save them as a script for future use. They work together, and usually are in the right order because they do not repeat within the sequence. I could start by writing them on a single line, but this requires me to plan the order of testing. Plus, sometimes a command has to be tried on its own first. So the mechanism is not as useful for casual use -- do something, and then realize that you want to save it. > > >i also want to be able to execute some commands without having them > > >added to the history. > > Why? > > to not pollute the history with lots of uninterresting commands. > (history storage is limited. for any new command an old one needs to > go.) or i accidently (or even deliberately, because there was no other > option) supply sensitive information as an argument to a command. > then it is nice to have the option to clear this out. Does the latter issue does not even arise using a builtin? > granted this need happens very rarely, but it does come up occasionally. > > > How would you do that with a history variable -- delete them > > manually after they are added? > > that, or i would write a function that i can call to do it. This strikes me as a bit cumbersome, and only rarely useful, to a few users. I do think each command should be auto-appended to a history file that can be edited, copied to another computer, used to write scripts, etc. Newer entries still must be kept in a cache for fast access. Currently the commands are appended to the history file only when the shell terminates; if the shell exits unexpectedly, the history is lost. [...] ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
