[OT] Which IDE / Editor do you use?

[H. S. Teoh]

On Mon, Sep 16, 2013 at 09:53:34PM +0200, Adam D. Ruppe wrote:
> On Monday, 16 September 2013 at 17:04:46 UTC, H. S. Teoh wrote:
> >It's a miniscule time savings, but it does add up when you're
> >editing a complex command-line pipeline.
> 
> You know what would actually be huge for me? The mouse. If you have
> a 200 character command line, just clicking it would be so nice.
> 
> I'm sure there's some ctrl+meta+alt that can do it too, but I don't
> know my emacs (and readline's vi mode is weak).

There's a vi mode to readline??

My ideal, actually, would be to liberate the command-line from its
single-line restriction. It would be in insert mode by default, to cater
for the common case, but hitting ESC would put it into navigation mode,
where you can use vi movement keys to navigate. You could construct the
command in a block (almost like a one-off shell script) before
committing and executing it.


> Eventually I'll finish my terminal emulator that will include that
> kind of thing. Probably on a wild combo like ctrl+alt+click so I
> don't accidentally trigger it when I don't want to. But I'm not in a
> huge rush to write that since I actually quite like rxvt and xterm.

I'm a huge fan of rxvt-unicode. No need to switch between (non-unicode)
rxvt and xterm, it handles it all.


> >Eek. I use C-s frequently for throttling program output; it would
> >suck to have to escape it!
> 
> 
> heh, I use gigantic scroll back buffers for that whenever I can.

Well, I do too, but still, sometimes you kinda want a fast key combo to
freeze the output from an accidental infinite loop while logged in over
a slow ssh connection. It's not so nice to have to disconnect and
reconnect just to stop the program (or wait for 5MB of the same text
repeated 10 million times to choke through the ssh link). Though I
suppose C-c does just as well by killing the program off.

In fact, now that I think of it, my use cases for C-s has drastically
diminished over the years. Maybe it's not as important as I remember it
is anymore. :-)


> >inability to handle UTF-8 (in this day and age! seriously!).
> 
> The X server doesn't make utf-8 easy... I was looking into utf8
> input for simpledisplay.d and it is kinda complicated. (Another
> advantage Windows has - it's been unicode aware for a long time.)

True.


> But, how much do you really need for a window manager?

Just enough to be able to render window titles in UTF-8 correctly. It's
not really *that* important otherwise... it's very rare (if ever!) that
the WM will actually need to translate keyboard input into UTF-8, for
example. For the most part, it could just treat it as an opaque 8-bit
byte string.


> >have the new mobo serving as a headless compute server, then I can
> >have the best of both worlds!
> 
> yes!
> 
> (BTW, I just hit esc after typing that. I'm on the website, but
> that's my vi habit - enter something, then immediately hit esc to
> get back to command mode. When I was a vi newb I spent most my time
> in insert mode, but now I'm only rarely in there - just long enough
> to actually insert, then it is back to command immediately.)

When I first started learning vi, I steeled myself to learn it the
"right" way by only entering input mode when necessary. The learning
curve was a lot steeper that way, but then I also learned faster by not
acquiring n00b habits that must later be shed.

But yeah, my left little finger has acquired this twitch every now and
then to want to hit ESC, even when there's no reason to do so. :-P


> >Really? I never had a kernel panic from misconfigured X11.
> 
> The kernel panics were from earlier in the boot process. For
> example, NFS over my at the time 10mbps hub was very unreliable, so
> it went to mount the root filesystem, lost some packets, and kernel
> panicked.
> 
> IIRC I ended up fixing that by making nfs use tcp connections rather
> than the unreliable udp datagrams.

I see. Thanks for the tip, I'll have to keep that in mind in case I run
into similar issues. :)


> Of course, X wasn't easy either. It didn't autoconfigure right, the
> driver that was supposed to work for the chip didn't (the screen
> would be garbled), and the other settings are just whoooo. I can
> only imagine how awful it was before then - at least my monitors
> weren't at risk of frying themselves. (or was that a myth too? i
> don't know but i'd believe it)

All I remember was that the X server was so paranoid about not frying
your monitor that it often refused to use a resolution / refresh rate
that is clearly advertised in both monitor and video card manuals as
supported. I often had to feed fake values into the conf file just to
make it do what I want (though I may have inadvertently put my monitor
at risk of being fried -- never actually happened, though!).


> It did work with the vesa driver though pretty reliably, but that
> couldn't max out the potential of that 1 MB of video ram! But that's
> ok 800x600 looks good anyway.

I ran at 800x600 for many years, before I upgraded to a 1600x1200 LCD
monitor. Then 800x600 kinda... didn't fit very well. :-P


> >annoying, since the kernel (and every else) actually still works,
> >and I can ssh into it, etc., but it's unusable from the desk and
> 
> Maybe svgalib could have helped there too. But yeah, X.org my old
> motherboard would do something similarly annoying: all input and
> output at the desktop would freeze dead, all of it, but I could
> still ssh into the machine so clearly the kernel was still alive.

Actually, it was X malfunctions like that that drove me to compile the
SysRq hack in the kernel, so when things went awry, I can hit
ctrl-SysRq-k to forcefully kill the X server. If that didn't help, I
could at least ctrl-SysRq-s to sync the disk buffers, then ctrl-SysRq-R
to force a reboot (the sync is so that I didn't have to wait 15 minutes
for fsck to run).


> Even switching vt wouldn't work, X locked up and took the hardware
> with it. Sometimes, kill -9 X via ssh would fix it, but sometimes
> that just left it in another indeterminate state that wouldn't
> recover properly either, forcing the reboot.

Yeah I remember doing some research on that. Apparently X leaves the
video card in graphics mode in a way that the kernel didn't know how to
undo, so good luck getting the console back. If your intuition of
exactly how the VT consoles worked was good enough, though, you could
login as root (blind), and restart X11, and sometimes it would come
back. Provided it didn't outright crash again immediately, that is. I
did try editing X11.conf blind once, in an attempt to fix things, but
that was a little too complex for me. :-P


> The weird thing though is sometimes, if I just left it alone for 30
> mins or so, it would actually fix itself. Maybe had to do with power
> management, i don't know.

Really? Never knew about that!


> My new motherboard is a lot saner. Other than the alsa volume
> control problem (pretty minor all things considered) it has worked
> very well.
> 
> But I guess we'll see if it continues to when it is 5 years old too.
> My pentium 1 box, now 16 years old, works flawlessly to this day.
> But cliched as it is, they don't make 'em like they used to.

Hmph. My plan is for my current mobo to last for the next 5 years, if
not 10. I deliberately invested in an AMD hexacore so that it wouldn't
go out of date for a looong time. But we'll see if the hardware can hold
up that long.


[...]
> >pretty efficient unlike X11, but it doesn't support unicode fonts.
> 
> You sure? I thought it does now, if you enable the kernel
> framebuffer. (Now I like the vga text mode, so no framebuffer for
> me, but I'm pretty sure the new stuff is workable there.)

Really? I remember trying it, but the non-ASCII characters came out all
wrong. Well, the kernel didn't *have* unicode fonts built-in, and there
was no way I know of to make it use .ttf, so I gave up.


> >Hooray for rewriting old lost projects in D. :) You'd probably get
> >it back up and running faster anyway, thanks to D's awesome
> >features.
> 
> I can use my own terminal.d instead of ncurses too, yay.

Speaking of which, have you had a chance to look at the latest breakage
with DMD git HEAD yet? I'd file a regression on the bugtracker, but I
don't know enough about the internals of terminal.d to be able to tell
at a glance exactly what went wrong.


> >What I'd *really* like, is to extend the Linux console to handle
> >inline graphics (rounded to the next largest multiple of the
> >character tile size).
> 
> Heh, I've been thinking about that too. Part of the reason
> terminal.d has an enum { linear, cellular } is due to a design I've
> been pondering (and, of course, it matches right up to the alternate
> screen feature of linux terminals too).
> 
> If graphics were available in linear mode, cat file.png would go
> right ahead and draw it out there. Or something like that, it'd
> probably need an escape sequence to enable graphic mode to be sane.
> 
> And then cellular mode would be a framebuffer as well as a text
> buffer.

I remember talking about this before (IIRC with you). If I could do it,
I might just be able to get rid of my GUI browser dependence once and
for all. :)


> Believe it or not, the BIOS on DOS used to kinda support all this!
> If you switched to mode 13h and printf()'d, at least using Digital
> Mars C, maybe it is a dm runtime feature rather than the BIOS or DOS
> or whatever, but if you did that, the text would indeed output, and
> you can still write graphics.

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.


> In mode 3, vga text mode, the graphics stuff would just be swallowed
> and/or replaced by alternate text (omg I have a program that renders
> arbitrary images to ascii art. If you run a .mpg through it, you can
> actually watch movies on a text terminal! tempting to try to write
> that... but i'd prolly just keep it simple), but if you're in a
> graphics capable window and cat image, sure, let's show it.

That would be cool. I'd be able to watch videos over an ssh terminal.
:-P Or play 3D games. :-P  (And feel nice and geeky about it.)


> I almost think I saw a terminal program that did that. But I want to
> write my own terminal emulator and specification anyway.

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.
There are just too many legit user usages of ESC (such as vim!) for that
choice to be anything but a horrible one. If anything, I'd use an
invalid UTF-8 value like 0xFD so that it will never get mixed up with
literal output data. In fact, I'd use all the 1-byte invalid UTF code
points as terminal control sequences, for brevity.


[...]
> But what's important about the task bar is you can see it without
> asking for a popup. So then, say, I get an IM and it adds a * to the
> left side of the name, and now I can see it without making an
> effort.

I dunno, I prefer to explicitly check for messages when I want to,
rather than being constantly interrupted by dings and beeps and popups,
including on-screen text that changes. If anything, I'd have the * added
to the window name and I'd look for it when I actually feel like looking
at the window list.

I'm a pretty big fan of pull media rather than push media.


> The other nice thing is the programs stay in a certain space. Most
> the titles on my thing are just 'rxvt' - pretty useless. But I know
> the one on the left is one thing, the one in the middle is another,
> etc.

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,
and the first thing that I usually do upon firing up a new terminal is
to set its title to something meaningful.


[...]
> blargh i need to stop dreaming of and talking about my ideal linux
> and get to work! lol

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


T

-- 
Marketing: the art of convincing people to pay for what they didn't need
before which you can't deliver after.