[OT] Which IDE / Editor do you use?

[H. S. Teoh]

On Tue, Sep 17, 2013 at 02:03:33AM +0200, Adam D. Ruppe wrote:
> On Monday, 16 September 2013 at 22:53:04 UTC, H. S. Teoh wrote:
> >There's a vi mode to readline??
> 
> yeah, in bash you can enable it with
> 
> set -o vi
> 
> I've found some little problems with it, though your mileage may
> vary. One is that terminal escape sequences might mess it up. For
> example, in my rxvt, if I hit the end key, it uppercases the next
> few characters: my rxvt sends ^[[7~ on home, which the vi mode sees
> as 7~. But, in the default (emacs) mode, all these keys work.

Well, now that I just learned about C-x C-e in bash, I think I won't
need this anymore. :) Just need to set $EDITOR to vim, and off I go.


[...]
> >Just enough to be able to render window titles in UTF-8 correctly.
> 
> eh, I'm not sure which X function does it, but that's small enough
> you could just render it as a pixmap and draw it that way. (This is
> the way gtk and qt do all text!)

No kidding! Never knew that. I guess that just shows how b0rken (or
antiquated) X11 font handling is. I remember reading through the
protocols for it... looks like a valiant attempt at future-proofing,
which fell flat because of the unpredictability of what the future might
hold. Premature generalization at its finest. :)


> On my github, you can also find stb_truetype.d which renders ttfs to
> little images without dependencies (it is a port of the
> stb_truetype.h public domain C file). The D api portion is still
> incomplete but there's enough there to use it, and I *think* I did
> unicode correctly.

Interesting! I'll have to check it out sometime.


> >I see. Thanks for the tip, I'll have to keep that in mind in case
> >I run into similar issues. :)
> 
> there's a good chance you'll be ok with a switch/router instead of a
> hub. I actually got the hub so I could sniff the network traffic
> from my brother....

lol...


> but I never actually did any of that and instead set it up as the
> upstairs hub, so I'd only have to run one long wire from the router
> downstairs.

I still have an unused hub lying around, after replacing it with a
wireless router so that my wife doesn't need to constantly plug in stray
ethernet cables just to make her laptop work. Never realized collisions
can be so bad on a hub.


[...]
> >I ran at 800x600 for many years, before I upgraded to a 1600x1200
> >LCD monitor.
> 
> that's huge! The one I have now is 1280x1024, the biggest I've ever
> used. (I notice you are using 4:3 too. 4:3 rox.)

I'm a stickler for 4:3. I *hate* those shortscreen monitors (aka
widescreen :-P). It feels like the top got chopped off. I value my
vertical real estate!


[...]
> >Speaking of which, have you had a chance to look at the latest
> >breakage with DMD git HEAD yet?
> 
> I just did, and it worked, though I had to grab updated druntime and
> phobos too.
> 
> ./dmd  -c ~/arsd/terminal.d  -I~/d/wtf/druntime-master/src/
> -I~/d/wtf/phobos-master/
> # silence is good!
> me at arsd:~/d/wtf/dmd-master/src$

Hmm lemme try that again...

Yikes, I'm getting an ICE. :-(  Gah, looks like it's caused by
-property, which is b0rken anyway. I'll take it out of my build file.
Sorry for the false alarm!


> >I might just be able to get rid of my GUI browser dependence once
> >and for all. :)
> 
> arguably it'd still be a gui, since it'd need to run in graphics
> mode and all! Just a *great* gui.

Right. :)


[...]
> >I do remember that feature in the BIOS, actually. I also remember it
> >was horrifically slow. In fact, I reinvented my own text output
> >system in assembly which was orders of magnitude faster.
> 
> Aye, all BIOS text output was brutally slow, I'm sure just about
> every DOS programmer did their own text output at one point or
> another!

I wrote my text routines with 6-pixel wide fonts instead of the normal
8-pixel font, just so I could cram more text onto the screen. :-P
Needless to say, those were the days before I got a clue about
typography.


> In text mode, you just write to segment 0xb800, and in graphics mode
> what I did was blit some little bitmaps over. Wrote my own bitmap font
> editor too.

0xb800 -- I remember that! Brings back the memories!


> Actually, I recently ported some of my old DOS drawing stuff to D,
> called image_basicdrawing.d. Does bresenham's line algorithm,
> ellipses, and bitmapped text.
> 
> I haven't put it to github yet though because I'm pretty sure I
> copy/pasted half that code back in the day and thus aren't sure
> about the copyright status!

Heh. I was on the other extreme... I reinvented everything from the
square wheel to the triangular peg in the round hole. It was free of
copyright issues, it's true. But it also mostly sucked. :-P


> >The first thing I'd do if I were to write a terminal spec is to
> >get rid of the stupid dependence on ESC as the terminal control
> >escape code.
> 
> god yes, especially on input. This is another thing (omg back to the
> roots of this hijack!) that Windows just does so much better.
> 
> Raw console input on Windows is delivered as INPUT_RECORD structs:
> 
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms683499%28v=vs.85%29.aspx
> 
> which is nice and structured. Extensible, unambigious, and a lot
> less hideous than the mess of input sequences you can get on linux.

Yeah... unfortunately the Unix obsession over everything being a byte
stream is coming back to byte us. ;-)


> I guess it is less efficient over ssh, but it is so much simpler.

ssh -C. :)

How would you intermix it with character data, though? 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.


> Though, an easy fix to the unix thing: make your esc key send it
> twice. So ^[^[ == user hit esc, similarly to how "\\" is `\`. At
> least then it won't be as messy. Sending it twice might even be more
> backward compatible since a lot of unix programs either specifically
> watch for the second esc, or at least ignore the second one already
> since that's a fairly common manual workaround for the crappy
> design.

Hmm. I've gotta try that sometime. Does XKB support mappings like that?
Or that is to say, I'm pretty sure it does but I've no idea how to
configure that.


> If I was doing it from scratch, I'd probably say plain input is one
> byte, escape is either ^[ with ^[^[ the literal esc, or an invalid
> utf-8 byte like you said, though that might reduce error detection,
> and anything else is a struct: <ESC>size_of_struct type_of_event
> event_data....\n (or something).

But how would you intersperse structs in the middle of an input stream?

I suppose one way is to delimit it with invalid UTF-8 bytes like:

	0xFC <binary data> 0xFD

but then you have the problem of spewing random garbage to the screen if
somehow the 0xFC got lost in transit. Again, it's caused by the Unix
obsession of shoehorning everything into a byte stream. :-/


> The data could be binary or ascii, whatever, but this way you could
> skip it by only knowing the size (unlike the termcap mess on linux),
> it could embed arbitrary data in there, and is unambiguous.
> 
> Another thing that might be nice is to make sure it is all invalid
> utf bytes, but encoding data that way would get long. But then you
> could ignore it even if you missed the size - would be nice to
> recover a broken stream.

Right. The best solution is to admit that the control stream and the
data stream are two different things, and use *two* streams for them.
But then you may have trouble with synchronizing the two should there be
network lag or packet reordering in between. Bah. Some days you just
can't win.


> I'd do output similarly too. Escape sequences on output aren't
> nearly as nasty as on input - you probably don't output an esc
> character most the time - but still they should be structured enough
> so you can easily ignore unknown ones and be a little more binary
> safe.

Yeah no kidding. Nothing like `cat binary.file` turning your terminal
settings into mush just because it happens to contain the wrong byte
sequences. :-/

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. The stream API for terminals should automatically escape
*all* data, and have a separate set of APIs for sending control
sequences. That way the terminal library layer ensures data is always
correctly encoded. Writing raw data to a terminal is a dangerous
operation anyway.


> Then you output a png image in that same set too!
> 
> 
> >rather than being constantly interrupted by dings and beeps and
> >popups,
> 
> i love beeps lol
> 
> modprobe pcspkr

Heh. I'm the opposite. I hate beeps so much that I specifically
configured my kernel to *not* have the pcspkr module. :-P


> >I never leave the title as 'rxvt'; I wrote a little program that
> >writes the escape sequence to change the window title to the
> >command-line args,
> 
> I did one of those too (a shell script too lol) but I do it
> spacially or transiently anyway - my rxvts either live long enough
> that I get to know them by position on the taskbar, or they are gone
> so quickly that it doesn't matter.
> 
> Another hassle is screen sometimes doesn't propagate that correctly
> which is annoying too...

Yeah, that *is* annoying. But that's more annoying is programs that
randomly change the terminal title just 'cos they can. Thankfully,
ratpoison lets me hardcode a manually-specified name onto windows, which
causes the window's title string to be ignored. This way I can turn off
intrusive title changes without the offending program even realizing it.
:-P


> >Yeah I should stop talking about ratpoison replacements, and
> >actually go write one. In D. With ranges. :-P
> 
> lol ranges

Well, ranges are one of D's big selling points, aren't they? :-P I mean
after all, a WM is basically a program that processes a *range* of X11
events, outputs a *range* of X11 requests, manages a *range* of windows,
etc...


T

-- 
Claiming that your operating system is the best in the world because
more people use it is like saying McDonalds makes the best food in the
world. -- Carl B. Constantine