On Tuesday, 17 September 2013 at 01:59:42 UTC, H. S. Teoh wrote:
No kidding! Never knew that. I guess that just shows how b0rken
(or antiquated) X11 font handling is.
indeed.
0xb800 -- I remember that! Brings back the memories!
Oh yeah. This is half the fun of my minimal-d
(http://arsdnet.net/dcode/minimal.zip) toy that runs on bare
metal (after booting with grub) - I can do some of that stuff
again!
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!
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.
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.
So the other files let you just set up pipes easily without
necessarily hijacking the interactivity.
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.
Hmm. I've gotta try that sometime. Does XKB support mappings
like that?
I don't know.
I suppose one way is to delimit it with invalid UTF-8 bytes
like:
yea.
then you have the problem of spewing random garbage to the
screen if somehow the 0xFC got lost in transit.
Right... but the connections are reliable enough that we can
probably get away with just leaving that to the other layer (tcp
or whatever).
But on second thoughts, aren't terminals over raw, unreliable
connections passé these days? As long as you have TCP, you
should be good to go.
exactly
Thankfully,ratpoison lets me hardcode a manually-specified name
onto windows, which causes the window's title string to be
ignored.
cool. Maybe I'll put that in my terminal emulator too...
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.
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!
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.
