[OT] Which IDE / Editor do you use?

[Adam D. Ruppe]

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.