On 9/21/06, Beni Cherniavsky <[EMAIL PROTECTED]> wrote: > On 18/09/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: > > On 9/17/06, Beni Cherniavsky <[EMAIL PROTECTED]> wrote: [...] > > * This makes the output of 'set' meaningless, since $history alone is > > several screenfulls. > > This is generic a problem with ``set``. It means any big array is > inconvenient in fish. I'd rather change ``set`` to shorten long > arrays. One approach is to restrict the number of values (e.g. ``a b > c ... x y z``), but perhaps restricting the total string length is > even better (e.g. ``aaaaaaaaa...aaaa bbb c``).
I think that would be good. The same problem exists for ``functions`` and ``history`` (if it is a command), as well as the help of some commands. So the same could be done there. Indeed, any command that has a long output is problematic. The problem is that you lose sight of previous output; and scrolling throught the output buffer requires visually searching for the end of each command's output and for the right command. A general solution would be a terminal that stores each output in its own buffer, and lets you scroll by buffer, search the output, and create a new window containing a buffer. But with a terminal like Xterm, there is not much a shell can do. In fact, the best idea I have heard so far is to remove the distinction between output and user content (except for short interactive messages). The results is essentially a text editor that can access all the user's content (without using filenames). This is the approach in Archy (http://www.raskincenter.org) > The downside is that the output of ``set`` ceases to be reliably > parsable. I don't think that's important. Perhaps shortening only > when the output is a terminal is best. And you should always be able to override the shortening by using a switch. > > * The indexes for history items change all the time, making it hard to > > keep track of history items. > > > True enough. Let's use normal order then, growing at the end. The > last commands will still be easily accessible with negative indexing. Well, if the history is ordered oldest-last, you can access the n-th-oldest element as -n. So the two orderings are functionally equivalent. That's the beauty of negative indexing. So now the question is, which indexing is coneptually simpler. ``(history)[13]`` to mean the 13th-oldest element, or the 13th-newest (conversely ``(history)[-21]`` for the 21st-newest or -oldest)? > > In conclusion, a $history variable seems to me to be a solution that > > is great on paper and a pain in practice. My way was bad and the bash > > way is better. Unless someone has some good arguments, I'm going to > > implement a history builtin like in bash. Even if you reorder the history (oldest-first), this is not a reason for making it a variable. > A builtin whose only purpose is accessing something which is > essentially an array means two interfaces to a single concept. It > violates the law of orthogonality. Unless someone has good arguments, > history should be just an array. I think the history is conceptually a builtin, because you can't set it (and should not be able to). If possible, all variables should be settable, to keep things conceptually simple. Sure, the output is an array. You can always access the n-th element using ``(history)[n]``, so the cost in terms of verbosity is negligible. I would think that ``history`` as a builtin is also more discoverable, because you don't need to type a dollar-sign to access it. ``history`` on its own can shorten the output (as with ``set``) to the last few commands. You can't do that with a variable. (You can pass the text to be shortened to a "shorten" function: ``echo $history | shorten``.) > > > * Expose the history of command-line editing commands in > > > $__fish_edit_history or something like that. The motivation is > > > commands like M-. that notice when they are used repeatedly. > > > > A detailed suggestion of exactly how this should be exposed, and what > > information is critical would be needed. > > > Looking at Emacs' facilities for this, it's enough to remember only > the last editing command (what's enough for Emacs is surely enough for > us :-). Let $__fish_last_edit_command be one string containg the last > editing command executed (builtin, function name or arbitrary string, > whatever was on the right side of bind/inputrc). Every keyboard > sequence must set it (to '' if there is some problem computing the > real name). > > Then, I could do something like this:: > > function yank-last-arg > if [ $__fish_last_edit_command = yank-last-arg ] > set -g __yank-last-arg_index (expr $__yank-last-arg_index + 1) > commandline $__yank-last-arg_base_cmd > else > set -g __yank-last-arg_base_cmd (commandline) > set -g __yank-last-arg_index 1 > end > commandline -a (commandline -o $history[-$__yank-last-arg_index])[-1] > end > > For such tasks you could just expose a counter of how many times the > current command was repeated - but that would be weaker and one day > somebody will write several cooperating commands. > [...] What's the benefit of this over using Fish's Alt-uparrow? ------------------------------------------------------------------------- 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
