Questions about windows support

[Adam D. Ruppe]

On Tuesday, 21 February 2012 at 02:05:16 UTC, H. S. Teoh wrote:
> Same with Linux, I thought? Although I mainly just use vim for
> programming, so maybe I'm unaware of the full situation.

Yup.

> Terminal escape sequences?! You should be using libcurses or 
> libncurses.
> No wonder you had a bad experience. :)

They don't help that much, since they can't hide the underlying
reality.

Consider how you highlight some text in there. You'd have
to do a change attributes, then a move, then a draw, then
move back.

ncurses has functions and macros to make it a little simpler,
but not that much. (especially if your termcap is broken...)

Mouse is a pain too. ncurses sometimes helps but what about
gpm?

Even old, fairly reliable programs have trouble with mouse. I
do most my programming in vim, inside gnu screen, displayed in
an xterm.

Sometimes, it works great. Sometimes, though, if I click too far
to the side.... it sends some bizarre sequence that vim interprets
as a drag then input.

The ugly escape sequences showed through to the end user (me)!



Another bad one is when I open mysql on a remote server in my
beloved rxvt, hit hte home key, and.... well, it is actually 
working
for me today. But, I've many, many times had it say ^[~m or 
something
like that.

Ugh.



Oh yeah, another one. Ever try to make an app in ncurses where you
hold in a button? I believe it was shift+page up that I wanted,
and its impossible because the terminal it is emulating didn't 
have
a sequence for shift pressed, shift released, nor shift+page up.

You could do that if you were talking to the hardware... but linux
emulates some ancient pieces of trash, so you're left out.


Oh oh, one more. Ever try to run a colored app in a different 
color
terminal?

vi with syntax highlighting fails easily. In vim, you can do
:set bg=light. My vimrc has an environment variable I set 
(ELVISBG)
for my various things.

But... run it in screen. Start it in a white xterm. Detach and
reattach to a black putty.

The contrast is all wrong.



There's no way for an app to query the colors in a unix terminal!


Some ncurses apps just redraw the whole thing. Some use 
environment
variables or something.


But, there's no way without you telling it, and if things change,
it is easy to get out of whack.



Speaking of out of whack, ever resize a terminal connected to a
remote session and see it not work? You're typing a long command,
and it suddenly wraps back well before the edge and overwrites
your old stuff.


My god.



Here's another one: have someone set a prompt with a wrong escape
sequence. bash will mess up the length and will draw over your 
other
stuff as you backspace.





I've been using linux every day for about seven years now. I can
go on all day!



The windows one isn't perfect, not by any means, but it has
a nice separation of control, input, and output.

The Windows console api separates these things. You have an output
buffer and an input event loop, with key and mouse events. You
can set attributes on the cells (very much like the hardware 
again :) )
and get updates and query the system separately from the I/O 
channel.

Much better design. If it did selecting by lines by itself and had
nicer resizing, it'd be a real winner.


> But I agree with you though, that libc incompatibilities are 
> really really REALLY annoying.

Even worse is linux's binary incompatibilities.

The dmd in the zip doesn't work out of the box on centos
for instance... have to recompile it.

> That's why I'm liking D a lot, in spite of it still being under
> development and having nasty compiler/library bugs every now 
> and then.

D rox.

> That's more a bash limitation than anything, AFAIK.

Yes and no. bash (and the kernel) is good about it now,
but it is an effect of the unix design of the shell
doing the expansion.

rm *

could have sent argv == ["rm", "*"], and your app
simply done foreach(a; glob(argv[1..$])) { delete(a); }
or whatever.

But, unix decided to do this in the shell. Which isn't
all bad, it has some nice effects.

But, run that in a folder with 20,000 items, and you send
20,000 strings in argv...



Another side effect of this is

rename *.html *.htm

doesn't just work, since it is all expanded there. You have
to make sure the wildcards are all at the tail of the
command, so you have

rename .htm .html *.htm

instead. Not bad, and an easy rule to get used to, but kinda
annoying at times.

> Besides, what *were* you
> trying to do with such a long command-line anyway? :-)


Once company I worked for had an old FreeBSD system
that dumped tens of thousands of files in a few locations...
which tended to fill up the disk.

They had a cronjob to delete stuff every so often, but it
grew big enough that the cron failed because there was too
much to delete.

And then the disk filled up and it was piles of fun. You'd
be amazed at how many unix apps refuse to run if they can't
write to /tmp!


> Most distros do distribute prebuilt binaries, but if your app 
> isn't part of the distribution, things get tough.

Aye, or if the version you need isn't in there. centos,
I'm looking at you!


> But then again, I *did* also have to deal with having to repair 
> a remote Linux server whose dynamic linker broke

I've had that one too.... I had the luxury of being able
to put in a cd though. Mount the drive and copy that stuff
back to it.