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".

On Tuesday, 17 September 2013 at 17:01:55 UTC, H. S. Teoh wrote:
> Actually, that gives me an idea. What if, instead of defaulting to character data, the terminal input stream defaults to control
> structures?

hehe those who don't understand Windows are doomed to reinvent it :) :) :)

> the length) per message, which should minimize the overhead of
> defaulting to control mode instead of pure data mode.

I'm actually not sure if overhead is worth worrying about. On the input side, it'd be slow anyway since humans only type so fast, and on the output side if you transfer big updates at once the few bytes for length and type would be quickly irrelevant anyway.

Besides, we aren't on 300 baud serial lines!

> I'm not sure what the bash syntax is, but couldn't you just pipe echo to, say, fd 3 (altin?)?

Yes, we'd just have to change the convention. I should patch vim myself!

It could probabaly be done with existing programs through named pipes too.

> Cool!

and it occurs to me that gnu screen is, at its core, just a terminal emulator. So... having a little terminal emulation library is useful for a bunch of things - a gnu screen replacement, a customized xterm, and perhaps even my own putty program for Windows. And embedding it in programs as a nice widget to use for some gui programming fun.

But wow, these escape sequences are even more annoying. I thought dealing with the input was a hassle, being on the other end is no walk in the park either!

However, I've implemented a handful and vim and bash are both kinda running. Some bugs in vim but it is usable.

> 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.

I thought about that, but I actually *like* the plain core font "fixed". (rxvt's default, at least on my system) I use it in a number of places and think it looks pretty good.

To the extent that I have two xterm shortcuts: one uses bitstream vera mono and the other uses plain old fixed-14.

Oh well, I'm rendering each character individually anyway, so switching won't be a problem.

> Then when it comes time to add inline images, just treat it as a very large character with a custom bitmap font. :-P

indeed. Which brings up an idea too: you could just define custom bitmapped glyphs... arguably at this point you might as well just use xlib, but hey doing a printf("\033 magic bitmap stuff") is kinda enticing!

>
> Besides, we aren't on 300 baud serial lines!
>

As backup line I have 56k dial-up modem ;)
We still trolling each other about IDE ?) Or Win 8.1 UI is the best UI?

On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote:
> Just out of interest.
>
> I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD.

I have been using jEdit quite a lot, in fact I've done most of my D programming in jEdit. jEdit may be the odd on out (i.e. written in Java), but I have not yet found an editor that has so many useful features and is so easily customizable, I can also use it on any platform. It is quite stable and performance (Java) is usually not an issue. I've tried loads of different editors but keep coming back to this one. (Textadept looks good, but it's too much of a hassle to customize it).

Although nice to have, D doesn't really need an IDE. IDEs can easily degenerate into luxurious prisons.

On Wednesday, 18 September 2013 at 08:42:16 UTC, Chris wrote:
> On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote:
>> Just out of interest.
>>
>> I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD.
>
> I have been using jEdit quite a lot, in fact I've done most of my D programming in jEdit. jEdit may be the odd on out (i.e. written in Java), but I have not yet found an editor that has so many useful features and is so easily customizable, I can also use it on any platform. It is quite stable and performance (Java) is usually not an issue. I've tried loads of different editors but keep coming back to this one. (Textadept looks good, but it's too much of a hassle to customize it).
>
> Although nice to have, D doesn't really need an IDE. IDEs can easily degenerate into luxurious prisons.

Enjoying gold cage prisons since 1991. :)

On Wednesday, 18 September 2013 at 09:15:36 UTC, PauloPinto wrote:
> On Wednesday, 18 September 2013 at 08:42:16 UTC, Chris wrote:
>> On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote:
>>> Just out of interest.
>>>
>>> I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD.
>>
>> I have been using jEdit quite a lot, in fact I've done most of my D programming in jEdit. jEdit may be the odd on out (i.e. written in Java), but I have not yet found an editor that has so many useful features and is so easily customizable, I can also use it on any platform. It is quite stable and performance (Java) is usually not an issue. I've tried loads of different editors but keep coming back to this one. (Textadept looks good, but it's too much of a hassle to customize it).
>>
>> Although nice to have, D doesn't really need an IDE. IDEs can easily degenerate into luxurious prisons.
>
> Enjoying gold cage prisons since 1991. :)

"We are all just prisoners here, of our own device" - Hotel California

On 18 September 2013 10:38, Chris <wendlec@tcd.ie> wrote:
> On Wednesday, 18 September 2013 at 09:15:36 UTC, PauloPinto wrote:
>>
>> On Wednesday, 18 September 2013 at 08:42:16 UTC, Chris wrote:
>>>
>>> On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote:
>>>>
>>>> Just out of interest.
>>>>
>>>> I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD.
>>>
>>>
>>> I have been using jEdit quite a lot, in fact I've done most of my D programming in jEdit. jEdit may be the odd on out (i.e. written in Java), but I have not yet found an editor that has so many useful features and is so easily customizable, I can also use it on any platform. It is quite stable and performance (Java) is usually not an issue. I've tried loads of different editors but keep coming back to this one. (Textadept looks good, but it's too much of a hassle to customize it).
>>>
>>> Although nice to have, D doesn't really need an IDE. IDEs can easily degenerate into luxurious prisons.
>>
>>
>> Enjoying gold cage prisons since 1991. :)
>
>
> "We are all just prisoners here, of our own device" - Hotel California

"Hanging on in quiet desperation is the English way" - Time


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Wed, 2013-09-18 at 11:38 +0200, Chris wrote:
[…]
> "We are all just prisoners here, of our own device" - Hotel California

but note:

"You can check out any time you like, but you can never leave" ibid.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wed, 18 Sep 2013 11:15:35 +0200
"PauloPinto" <pjmlp@progtools.org> wrote:

> On Wednesday, 18 September 2013 at 08:42:16 UTC, Chris wrote:
> >
> > Although nice to have, D doesn't really need an IDE. IDEs can easily degenerate into luxurious prisons.
> 
> Enjoying gold cage prisons since 1991. :)

"But I could stay, Stay in this luxury cage.
Wouldn't that be great? I don't think so."
- Republica: https://www.youtube.com/watch?v=Hk7gTRtW64E

(Great album, every bit as much as their first. A shame it never hit the
states.)

On Wednesday, 18 September 2013 at 18:29:25 UTC, Nick Sabalausky wrote:
> On Wed, 18 Sep 2013 11:15:35 +0200
> "PauloPinto" <pjmlp@progtools.org> wrote:
>
>> On Wednesday, 18 September 2013 at 08:42:16 UTC, Chris wrote:
>> >
>> > Although nice to have, D doesn't really need an IDE. IDEs can easily degenerate into luxurious prisons.
>> 
>> Enjoying gold cage prisons since 1991. :)
>
> "But I could stay, Stay in this luxury cage.
> Wouldn't that be great? I don't think so."
> - Republica: https://www.youtube.com/watch?v=Hk7gTRtW64E
>
> (Great album, every bit as much as their first. A shame it never hit the
> states.)

Star Trek the cage, the very first episode :D Humans posses a unique hatred of captivity, even when pleasant.