On Fri, May 20, 2011 at 10:06 AM, Nick <suckless-...@njw.me.uk> wrote: > On Fri, May 20, 2011 at 12:23:39AM +0200, hiro wrote: >> https://github.com/unconed/TermKit >> >> no comment, only sorry. > > indeed. i read about it yesterday. makes me want to vomit. > > Certainly the general implementation, the language and the architecture do seem nasty. OTOH, it always depresses me that it's kind of taken as a virtue that the interactive shell and the terminal are know almost nothing about each other (at least for almost all modern computing devices, I can see if you genuinely are using a 1970's dumb terminal you don't have the wiggle room for more). At the very least, it would be very productive to
1. Have a terminal/shell combination that, upon resizing, actually redisplays text properly rather than just chops off stuff in vanished/newly visible space. 2. Had the _option_ for shell history to pop up in another window, rather than _only_ being available as a command output, so that it scrolls other stuff you've been doing off the screen. 3. Had more flexible context-sensitive cutting support. (Eg, let me somehow copy a sequence of commands text without including either the prompt or command output.) Obviously it's not clear what the best way to provide greater information flow between interactive shells and terminals, and it may/may not be that the Plan9 or emacs-shell approach is the way to go, but it'd be nice if there was some increase in terminal productivity in the coming years. (Of course, the other problem is it's a large number of shells and terminals to change, and if additional "metadata" needs adding to commands that's a huge number of programs to change, so it's unlikely to happen...) -- cheers, dave tweed__________________________ computer vision reasearcher: david.tw...@gmail.com "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
