[OT] Which IDE / Editor do you use?

[Adam D. Ruppe]

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


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.


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

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

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

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


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


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)

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.

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

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.


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.

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.



> Well, nowadays X.org is pretty good about autodetecting most 
> settings,

Indeed, I was pleasantly surprised with the 64 bit install almost 
just working. I still installed the proprietary nvidia driver for 
3d acceleration, but at least it all came up.

The diskless fun was several years ago, I'm sure it'd be better 
now.


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

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

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

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.

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.


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

> Which, if I'm going to do it at all, I rather rewrite in D 
> instead.

aye

> Ratpoison had it right -- C-w and it shows a popup at the top 
> right corner of the screen containing a *vertical* list of 
> windows with full names.

Yeah, I have something similar on my windows key + tab hotkey as 
well as right as middle click on the edge of the screen.

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.

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.

And of course, gnu screen with C-a " does the list too, which is 
great.

>  Trying
> to cram everything into a *horizontal* bar just doesn't scale 
> beyond 10 items or so.

I have 17 open on this workspace and can even read the names! My 
custom taskbar though is 16 pixels tall, writes out the names in 
fixed-10 font (normally I'd consider that way too small to read, 
but it looks good down there), has only two pixels padding 
between the buttons, and almost no nonsense: no start button, 
quick launch bar, notification area. It does have a clock, I like 
clocks, but it consumes only about 40 pixels.

One of the reasons I did my own though was that all other 
taskbars indeed couldn't scale. They made stupid decisions with 
too many windows and wasted space with too few.

  At least a vertical list, given a small enough
> font, can
> support at least 25 items, probably more like 40, before a 
> scrollbar is
> even needed.



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