[OT] Which IDE / Editor do you use?

[Adam D. Ruppe]

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.

So I think the escape sequence is being misinterpreted as a 
series of user input. On my xterm however, it works correctly.


Another weird thing is when you hit a number, so I hit 3, it says:

me at arsd:~$ tESTING vi mode
<hit 3 now>
(arg: 3) tESTING vi mode

Which I guess isn't that bad, it is just different....

but here's something awesome: if you hit v, it actually brings up 
the actual vi (probably $EDITOR, since it loaded vim for me 
whereas my plain vi is elvis) to edit the command line!

That might just be your idea: edit it by hitting esc v.


So you know, I think it is time I give this another try. Time to 
edit bashrc...

> In fact, now that I think of it, my use cases for C-s has 
> drastically diminished over the years.

Aye, but I agree it is useful from time to time. I've used it on 
ssh too, or when building or running something like mplayer that 
just won't shut up long enough to scroll back.

BTW I used to not know about ^Q, so if I accidentally hit ^S, I'd 
get pissed at it freezing and not know what to do!

> 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!)

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.

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

But the problem is that hub was kinda slow and would get packet 
collisions fairly often. A switch, or maybe even a 10/100 hub, 
would probably work a lot better.

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


> Really? I remember trying it, but the non-ASCII characters came 
> out all wrong.

I might be wrong.

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

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

I think links can actually be configured to run a svgamodelib 
helper program to display images one by one in the linux terminal 
too...

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

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.


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!


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

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


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.

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

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.


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.

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


> 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 I should stop talking about ratpoison replacements, and 
> actually go write one. In D. With ranges. :-P

lol ranges