This is a reply to a message that was accidantally sent off list. I have Philips permission to post the reply on list.
--- Philip Ganchev <[EMAIL PROTECTED]> skrev: > On 10/1/06, Axel Liljencrantz > <[EMAIL PROTECTED]> wrote: > > Hi Philip > > > > Is it intentional that your emails where not sent > to > > the list? > > Oops -- no. My bad. > > > --- Philip Ganchev <[EMAIL PROTECTED]> skrev: > > > > > On 10/1/06, Axel Liljencrantz > > > <[EMAIL PROTECTED]> wrote: > > > > On 9/22/06, James Vega <[EMAIL PROTECTED]> > > > wrote: > > > > > I do this fairly frequently in irssi. I'll > > > start > > > > typing out a long > > > > > response to something and then press the > down > > > arrow > > > > to get a blank line > > > > > (pushing what I had been typing into the > > > 'history'). > > > > I can then type > > > > > something else and later go back to finish > the > > > long > > > > response I had > > > > > started. > > > > > > > > Fish should have that. To the todo-list! > > > > > > I was hoping that down-arrow would be saved as > the > > > default keybinding > > > for another feature which I had suggested: > guessing > > > the next command > > > in a repeated sequence of commands. > > > > > > > Oh right, my bad. I'd forgotten about that one. To > the > > todo-list! Though they don't really conflict, do > they? > > Add-to-history only makes sense if you've just > written > > something yourself, but -next-in-sequence only > makes > > sense if you haven't written _anything_ yet. > > They do not conflict as such, but I don't know if > using the same key > sequence for both may be considered modal. Possibly, yes. > > Also, the proposed feature would duplicate the use > of kill rings (also > called "cut buffers", etc). Do you plan to remove > the kill buffer, or > to violate orthogonality? > The way I see it: The kill rings main function is to share text snippets between running programs. The historys main function is to permanantly store previously entered text snippets. They are obviosuly related, and I _would_ like to unify them in order to make fish more orthogonal. Unfortunatly, the interface for sharing text between programs (clipboards) don't leave a lot of room for implementing a history-mechanism, so you're pretty much stuck there. As I see it, the kill-ring can never be anything but a souped up clipboard, and one that can't be integrated into the history in a graceful way, either. The only way of 'improving' orthogonality would be to remove the clipboard support entirely, which I don't want to do. Magical unified history clipboard ideas are welcome, though. As is, I can see how the history could be a much nicer base for implementing a really cool cut-buffer. You get things like searching for free, for one thing. In such a scenario, I would argue that the kill-ring should be simplified into a simple X clipboard interface, i.e. no actual ring, only a single entry. In another mail, you mention that you are afraid that important 'saved cuts' get lost if they are mixed into the history. I'm going to address this here, because I'd like to gather all parts of my answer in one mail, I hope I'm not misrepresenting you or breaking anyones mail reader by doing this. I think that the fear that important 'saved cuts' would get lost in the history is unfounded. The reasons for my suspision are: * I generally find that freetext search is a very quick way to find what I'm looking for. I have yet to have any trouble finding a cool command I've used before, even if it is several moths old. This is obviously very subjective. * There have been discussions about providing a history browser, something like the current completion browser, for history searches. This would make it even easier to find things in the history. One could also do things like adding timestamps to the history entries and marking unexecuted items in some way to make the history even more powerful. * The current cut buffer (except the top item) is lost whenever you exit fish, and it is local to a single fish session (once again, except the top item). These drawbacks make the killring a very unreliable place for storing useful data that you'll need in a while. If the cut buffer was made permanent, like the history is, it really _would_ become a history replacement, which would be very redundant. -- Axel ------------------------------------------------------------------------- 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
