[OT] Which IDE / Editor do you use?

[H. S. Teoh]

On Wed, Sep 18, 2013 at 03:01:26AM +0200, Adam D. Ruppe wrote:
> On Tuesday, 17 September 2013 at 17:01:55 UTC, H. S. Teoh wrote:
> >Actually, that gives me an idea. What if, instead of defaulting to
> >character data, the terminal input stream defaults to control
> >structures?
> 
> hehe those who don't understand Windows are doomed to reinvent it :)
> :) :)

lol... though it makes me think of the latest C++ proposals as "those
who don't understand D are doomed to reinvent it, poorly". :-P


> >the length) per message, which should minimize the overhead of
> >defaulting to control mode instead of pure data mode.
> 
> I'm actually not sure if overhead is worth worrying about. On the
> input side, it'd be slow anyway since humans only type so fast, and
> on the output side if you transfer big updates at once the few bytes
> for length and type would be quickly irrelevant anyway.
> 
> Besides, we aren't on 300 baud serial lines!

Well, having 1 control byte per 127 data bytes is pretty good throughput
in my book.

And even though we aren't on 300 baud serial lines, sometimes I *do*
wanna transfer large amounts of text into a terminal as fast as I can,
for example:

	http://eusebeia.dyndns.org/bashcp

Though granted, that is so rare as to be almost not worth considering.
:-P


> >I'm not sure what the bash syntax is, but couldn't you just pipe
> >echo to, say, fd 3 (altin?)?
> 
> Yes, we'd just have to change the convention. I should patch vim
> myself!
> 
> It could probabaly be done with existing programs through named
> pipes too.

Hmm, good point! Though I'm not sure what will happen if you run vim on
a named pipe, and it tries to mmap it. :-P


[...]
> and it occurs to me that gnu screen is, at its core, just a terminal
> emulator. So... having a little terminal emulation library is useful
> for a bunch of things - a gnu screen replacement, a customized
> xterm, and perhaps even my own putty program for Windows. And
> embedding it in programs as a nice widget to use for some gui
> programming fun.

And having it available as a *library* makes it very powerful -- you can
use it for all sorts of things, like you said.


[...]
> >Haha, yeah. If I were doing it, I'd say just do .ttf output from
> >the get-go, render it as an image, whatever, just don't even
> >bother with the antiquated X11 font handling.
> 
> I thought about that, but I actually *like* the plain core font
> "fixed". (rxvt's default, at least on my system) I use it in a
> number of places and think it looks pretty good.

To each his own. I can't stand the core fonts. Esp. since they don't
come in 18pt size. :-P  Which I kinda need 'cos my screen resolution is
1600x1200, and a 10-pixel-wide font is unreadably microscopic. Plus,
they don't include quite enough Unicode glyphs for my needs (actually,
do they even support unicode at all?!).


> To the extent that I have two xterm shortcuts: one uses bitstream
> vera mono and the other uses plain old fixed-14.
> 
> Oh well, I'm rendering each character individually anyway, so
> switching won't be a problem.

Make it pluggable. :)


> >Then when it comes time to add inline images, just treat it as a
> >very large character with a custom bitmap font. :-P
> 
> indeed. Which brings up an idea too: you could just define custom
> bitmapped glyphs... arguably at this point you might as well just
> use xlib, but hey doing a printf("\033 magic bitmap stuff") is kinda
> enticing!

I remember in the old DOS days, some games would load up custom graphics
into the video card's text font buffer, so that they can draw sprites
just by writing the corresponding characters into the video card's text
buffer.  You can get very fast drawing rates since the video card does
most of the work for you (and you only need to transfer 1 byte per 8x8
block of pixels instead of 8 bytes or more).

You can even get around the multiple-of-8 placement limitation on the
sprites by loading suitably shifted copies of it into the font buffer
(though it does take up precious character mapping space, so you can
only do that with a small number of sprites).


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in
common: they don't depend on the language. -- Luca De Vitis