Re: [dev] TermKit
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
Re: [dev] TermKit
Hey, On 20 May 2011 12:51, David Tweed david.tw...@gmail.com wrote: 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 fwiw, I agree. TermKit appears to be a very glossy turd, but there are certainly outstanding issues in our terminals, which is why in Plan 9 they tried to fix them by pairing a plaintext-only Rio term with graphical windows which actually replace the spawning term. It's not perfect, but the plaintext / graphics dichotomy does make things simpler in some ways. I think the way to solve this problem is not to add structure to pipes (which tend to be simple to use *because* they have no real structure), but to allow commands to draw directly to the terminal if they wanted. So the standard input / output piping system would remain unchanged, and all commands -- except those which rely on unhygienic escape codes, like curses -- would work just like normal. However, if the command would like it could communicate directly to the term and say show this diagram, or whatever. The term would basically be an ever-downward-scrolling canvas, which shows mostly text but may occasionally display simple graphics too. It would need some experimentation to find out what the best system would be, but ultimately it's just the Plan 9 approach except the drawn information is printed onto the term itself, and thus scrolls with it, rather than replacing the term entirely. This doesn't inherently solve every problem you mentioned, David, but it would probably be a good first step toward an innovative new terminal, and would be less vain than TermKit's approach. Thanks, cls
Re: [dev] TermKit
On Fri, May 20, 2011 at 2:26 PM, Connor Lane Smith c...@lubutu.com wrote: I think the way to solve this problem is not to add structure to pipes (which tend to be simple to use *because* they have no real structure), but to allow commands to draw directly to the terminal if they wanted. So the standard input / output piping system would remain unchanged, and all commands -- except those which rely on unhygienic escape codes, like curses -- would work just like normal. rxvt implements basic drawing primitives via escape codes[1]. It's disabled at compile time by default but you can find some poc in the source distribution that plots stuff. I think it has been dropped in urxvt. It's ok for very simple stuff but I really don't think it's scalable for anything remotely useful. 1: http://www.usf.uos.de/infoservice/doc/localhtml/rxvt/refer.html#Graphics
Re: [dev] TermKit
On Fri, May 20, 2011 at 1:26 PM, Connor Lane Smith c...@lubutu.com wrote: fwiw, I agree. TermKit appears to be a very glossy turd, but there are certainly outstanding issues in our terminals, which is why in Plan 9 they tried to fix them by pairing a plaintext-only Rio term with graphical windows which actually replace the spawning term. It's not perfect, but the plaintext / graphics dichotomy does make things simpler in some ways. That's an interesting proposal. The areas for improvement I tend to see revolve more around text and the information-loss going between the interactive shell and the terminal (so that this information is only accessible via typing shell commands). Eg, the shell knows which bits are the input, output, prompt but by the time the terminal has displayed it it's all one big block of text. -- 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
Re: [dev] TermKit
On Fri, 20 May 2011 14:40:39 +0100 Connor Lane Smith c...@lubutu.com wrote: On 20 May 2011 14:27, Dieter Plaetinck die...@plaetinck.be wrote: I think a fd to write something to like here's an image, please render it somewhere is better than cls's suggestion of having apps directly write to the terminal. I think the latter idea would get messy quickly. It's as if X windows would draw themself to the screen rather then having a window manager take care of it. I disagree. Your approach is as if X windows would have no control over their interface besides draw me now! My approach would probably involve Xembed: the program creates a new window, the terminal embeds it into the right place, and then the program can draw to this (like how tabbed works, only downward-scrolling). Each process can ask for a little space in the canvas and they can draw only within that. I think I misunderstood your previous mail. If you mean that the terminal/shell is the one who can say this region is where you can draw your image, and the app can draw the image, that's fine for me. Maybe that's even better (less complicated) than the app passing an image to the shell/terminal and asking to draw it. This is in fact mandatory for apps who want to draw nice graphs/graphics/interfaces, the terminal isn't even able to do that anyway. I thought earlier you meant that the apps should decide also _where_ (as in: position on screen / inside terminal window) they write output to.
Re: [dev] TermKit
On Fri, May 20, 2011 at 9:40 AM, Connor Lane Smith c...@lubutu.com wrote: I suppose that could be a useful interface, so long as it was clear which commands are associated with which output. Otherwise stdout could get a little messy. Also, by default stdout and stderr ought to be combined, perhaps with stderr in yellow or something. I don't understand why. If you want stderr to be combined into stdout, suffix 21 to your command. By default, I think different filehandles should land in different outputs. As for associating commands with their output, that would be trivial. Typing in your command script in the input window and causing it to be executed should start a subshell. Captured output from stdout should be rendered in the output window, perhaps with a box around it, possibly numbered. Then you can go back to the input window to browse your command history, and selecting a history entry should be able to bring up the output of that command. when you have a clean separation between filehandles, and you're not just dumping all three into one bidirectional window, maintaining the relationships between data in each should be much, much easier. This obviously ignores the problem of backgrounded tasks, but even that would be nicer: instead of just getting shit dumped on the screen with a pid prefix, the terminal could just open another output window. The more I think about this interface the more I want to write it. -- # Kurt H Maier
Re: [dev] TermKit
On 20 May 2011 14:54, Kurt H Maier karmaf...@gmail.com wrote: I don't understand why. If you want stderr to be combined into stdout, suffix 21 to your command. By default, I think different filehandles should land in different outputs. I just think the stdout and stderr ought to be visible at the same time. Or perhaps it would suffice to show stderr above stdout, or automatically switch, or something. Typing in your command script in the input window and causing it to be executed should start a subshell. Captured output from stdout should be rendered in the output window, perhaps with a box around it, possibly numbered. Then you can go back to the input window to browse your command history, and selecting a history entry should be able to bring up the output of that command. That sounds good to me. And you could head each 'output box' with the command which produced it. (Though numbering could be useful too.) I'm considering writing a 'next gen' 9term, if you'll excuse the expression, and these ideas (a terminal 'canvas', and separated streams) sound like they would be a very nice fit. cls
Re: [dev] TermKit
On Fri, 20 May 2011 15:19:00 +0100 Connor Lane Smith c...@lubutu.com wrote: On 20 May 2011 14:54, Kurt H Maier karmaf...@gmail.com wrote: I don't understand why. If you want stderr to be combined into stdout, suffix 21 to your command. By default, I think different filehandles should land in different outputs. I just think the stdout and stderr ought to be visible at the same time. Or perhaps it would suffice to show stderr above stdout, or automatically switch, or something. this could be configurable by the user. or at least changeable at runtime.
Re: [dev] TermKit
2011/5/20 Hadrian Węgrzynowski hadr...@hawski.com: Sometimes I would like to display some graphics inside terminal window. We could draw directly in terminal's window or place graphics inline with text. I would prefer second method. I think the way I described it in my first email was a little confusing. As I clarified to Dieter, what I meant was that the program would request a space in which to draw, and the term would place this drawing space in-line (i.e., as graphics within text), so that it scrolls with the output, and so on. One of the key features of text terminals is monospaced font - that makes everything easier to align and easier to code. As I said I would like to display some graphics, but I don't want to give up on grid aligned display. I would prefer to display graphics within text. But for this to make sense program in many cases needs to know width and height of image in terminal characters. I don't think so. If the term is handling the placement of images, it can maintain the monospaced columns without the drawing process having to know anything about character size. Instead, the image is drawn, and the term simply continues drawing characters in the next column, so everything still lines up fine. We also don't have to reinvent the wheel with escape codes, since we can just use Xembed. Upon receiving an Xembed request the term would just stick that window in-line, with the appropriate size and everything, and that's dandy. (I checked, btw, and it seems you can XCopyArea from child windows, which is necessary for this approach.) cls
Re: [dev] TermKit
On Fri, May 20, 2011 at 12:16 PM, Suraj N. Kurapati sun...@gmail.com wrote:
history | xmessage -file -
I keep this ugly mess around in for convenience:
h()
{
`history | perl -e 'while(STDIN){s/\s+\d+\s+//;push
@o,$_;}for($i=$#o-1;$i=0;$i--){print $o[$i];}' | dmenu -b`
}
--Andrew Hills
Re: [dev] TermKit
On 20 May 2011 17:24, Suraj N. Kurapati sun...@gmail.com wrote: Use /dev/tty to draw to the terminal independently of std streams: date | sh -c 'read; echo $REPLY /dev/tty' /dev/null Your graphics look suspiciously like text. (I think you missed the point.) cls
Re: [dev] TermKit
On 5/20/11, Andrew Hills hills...@gmail.com wrote:
I keep this ugly mess around in for convenience:
h()
{
`history | perl -e 'while(STDIN){s/\s+\d+\s+//;push
@o,$_;}for($i=$#o-1;$i=0;$i--){print $o[$i];}' | dmenu -b`
}
I'm sorry for my total lack of 1337ness, but what does the perl part do?
Re: [dev] TermKit
On Fri, May 20, 2011 at 12:47 PM, Bjartur Thorlacius svartma...@gmail.com wrote: I'm sorry for my total lack of 1337ness, but what does the perl part do? Strips the numbers off the start of each line, reverses the order (for most recent first), and skips the first (last) entry (which is the command you typed to bring up the history). --Andrew Hills
Re: [dev] TermKit
On Fri, 20 May 2011, Andrew Hills wrote:
On Fri, May 20, 2011 at 12:16 PM, Suraj N. Kurapati wrote:
history | xmessage -file -
I keep this ugly mess around in for convenience:
h()
{
`history | perl -e 'while(STDIN){s/\s+\d+\s+//;push
@o,$_;}for($i=$#o-1;$i=0;$i--){print $o[$i];}' | dmenu -b`
}
Yikes. Ugly indeed. Unsolicited (sort of... something wrong on the
internet 'n all), but:
'for($i=$#o-1;$i=0;$i--){print $o[$i];}'
is better written:
'pop @o; print for reverse @o'
or
'print for reverse @o[0..$#o-1]'
Plus it's easier to reverse the whole thing outside of Perl (via tac),
and you can use '-n' to avoid the 'while(STDIN){}', so the whole thing
becomes:
h()
{
`history | perl -nwe 's/\s+\d+\s+//; print unless eof' | tac | dmenu -b`
}
Don't have `tac` installed? (I think it's in linux-utils or core-utils,
but maybe it's linux- and/or GNU-centric.)
tac () { perl -nwe 'unshift @o, $_; END { print for @o }' }
--
Best,
Ben
Re: [dev] TermKit
Thanks for the Perl-readability tip. On Fri, May 20, 2011 at 12:58 PM, Benjamin R. Haskell suckl...@benizi.com wrote: Don't have `tac` installed? (I think it's in linux-utils or core-utils, but maybe it's linux- and/or GNU-centric.) I do most of my work on Solaris, and it's not really worth the effort to install tac to use it in one place. --Andrew Hills
Re: [dev] TermKit
On Fri, 20 May 2011, Andrew Hills wrote: Thanks for the Perl-readability tip. No prob. On Fri, May 20, 2011 at 12:58 PM, Benjamin R. Haskell wrote: Don't have `tac` installed? (I think it's in linux-utils or core-utils, but maybe it's linux- and/or GNU-centric.) I do most of my work on Solaris, and it's not really worth the effort to install tac to use it in one place. Agreed. I might drop the substitute I listed into ~/.zsh/autoload/tac (can't live w/o syncing at least my shell startup files to systems I use). The wikipedia article on `tac` (first result when googling to see if it was indeed linux-specific) mentioned `tail -r` as a possible substitute. Anyone know what `tail`s support '-r' ( == reverse? )? or more generally, anyone have a good reference for differences in common commands across posix-like O/S'es? -- Best, Ben
Re: [dev] TermKit
On Fri, May 20, 2011 at 1:42 PM, Andrew Hills hills...@gmail.com wrote: Not supported by default on Solaris 5.8, Solaris 5.10, RHEL 4(NU7), RHEL 5.6, or Arch Linux (updated an hour ago). According to [0], only BSD tail has the reverse option. Any reason not to sort(1) them before you feed them to perl? And don't get me wrong: perl is my favorite language, but wouldn't something akin to history | sort -r | sed '1d; s/^[ \t]*[0-9]*[ \t]*//' work just as well? -- # Kurt H Maier
Re: [dev] TermKit
On Fri, May 20, 2011 at 2:21 PM, Andrew Hills hills...@gmail.com wrote: (Don't forget to escape your asterisks in sed.) I just pasted the output of TermKit. -- # Kurt H Maier
Re: [dev] TermKit
On Fri, May 20, 2011 at 2:22 PM, Kurt H Maier karmaf...@gmail.com wrote: I just pasted the output of TermKit. Something tells me to suspect that this is untrue. --Andrew Hills
