On Tue, Sep 17, 2013 at 04:25:50AM +0200, Adam D. Ruppe wrote: > On Tuesday, 17 September 2013 at 01:59:42 UTC, H. S. Teoh wrote: [...] > >Heh. I was on the other extreme... I reinvented everything from > >the square wheel to the triangular peg in the round hole. > > Oh, I've done my share of that too, but my lines were so slow and > Bresenham's algorithm was so fast, so I had to make the switch!
I never got that far. :-P > >How would you intermix it with character data, though? > > If you have a reliable connection it isn't too bad. You can either > define anything outside a struct to be character info or you can > have an INPUT_TYPE_CHAR struct that showsit. Actually, that gives me an idea. What if, instead of defaulting to character data, the terminal input stream defaults to control structures? That is, you're sending structs by default. Character data would then be represented as a length followed by the data, and the length would be chosen based on how much data is currently available. So, say we use a single byte for length, then we can reserve lengths with the high bit set to non-character control data, and values from 0-127 indicates how many subsequent data bytes follow. Of course, a 0 length is kinda useless, but perhaps could be used for EOF or other such indications. This lets us send up to 127 bytes of data (128 including the length) per message, which should minimize the overhead of defaulting to control mode instead of pure data mode. > >That's the problem with the Unix design. The control stream and > >the data stream is intermixed, which is the source of much of the > >headaches in terminal handling. > > Yup. I've thought before about doing up to five standard streams: > > 1) system control in, the event stream > 2) user control in, a character stream > 3) standard file in, a plain file. might be user control or might be > another file > 4) standard file out, might be the terminal or might be a file > 5) interactive output, the terminal. > > The #3 and #4 are different from unix stdin/out because they aren't > necessarily the terminal. Suppose you want to edit a temporary file. > You can'd do > > echo "initial data" | vi > > since that would be considered user input and be interpreted by vi > as a command. So what you end up doing is something like this > > echo "initial data" > /tmp/filexxx > vi /tmp/filexxx > > And ditto on output, you'd tell vi to write to the tmpfile since > redirecting stdout would screw up the user interactivity. I'm not sure what the bash syntax is, but couldn't you just pipe echo to, say, fd 3 (altin?)? Assuming that vim is changed to understand that, of course. If this convention becomes widely adopted, then it would effectively become "non-terminal input". Similarly, fd 4 could be used as altout, for non-terminal output. As a transition, programs could check if fd 3 and fd 4 are valid fd's; if they are, then assume the shell (or whatever invoked the process) knows about altin/altout and wants to send data along those channels, and adapt accordingly. > So the other files let you just set up pipes easily without > necessarily hijacking the interactivity. Yep. Though I think nowadays some programs already check whether stdin/stdout is hooked up to a terminal (IIRC using one of those obscure ioctl calls). I know for sure pagers like 'less' do it: if stdout is a non-terminal, it simply pipes the data through without attempting to page. > But, overall, I think unix does a pretty ok in this department - the > system is simple, maybe too simple, but it gets the job done. Yeah, adding more stuff to it makes sense but may introduce a lot more complexity. [...] > >Well, ranges are one of D's big selling points, aren't they? > > tbh I'm kinda meh on them. When they're great, they're great, but > otherwise eh, no need to force them in when it isn't necessary. I know. :) I was half-kidding. > BTW I did a lot of snippage here since I generally agree, but the > big fun is I just spent the last half hour playing with the idea of > doing my own terminal emulator again. > > And you know, that might not be so hard. In just this short time, I > got it started: in about 100 lines with simpledisplay.d and > eventloop.d as helper libraries, I have it running a basic shell. > The hard part is still coming: all the escape sequence nonsense, but > that's kinda additive, I can just do each one as I come to them, > making it more or less xterm compatible but just enough for the > programs I use.... then start doing extensions! Cool! > Most the work is actually done by forkpty() apparently. It even > handles echo automatically and I think it does line buffering too, > I'll know more as I play with it. And of course, simpledisplay.d > already does a lot of messy Xlib stuff and input events so this > might not be that hard at all. > > ...until I get to the issue of utf8 font output lol. Haha, yeah. If I were doing it, I'd say just do .ttf output from the get-go, render it as an image, whatever, just don't even bother with the antiquated X11 font handling. (FWIW I don't even use core X11 fonts on my system anymore, and don't even bother installing them except those that are absolutely, absolutely necessary for the thing to even start.) Then when it comes time to add inline images, just treat it as a very large character with a custom bitmap font. :-P T -- Long, long ago, the ancient Chinese invented a device that lets them see through walls. It was called the "window".
