[OT] Which IDE / Editor do you use?

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Sep 19 10:48:39 PDT 2013


On Thu, Sep 19, 2013 at 04:49:34PM +0200, Adam D. Ruppe wrote:
> On Wednesday, 18 September 2013 at 20:33:10 UTC, H. S. Teoh wrote:
> >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:
> 
> actually, I do want some way to transfer files easily. Using scp and
> so on is kinda a pain, I would like to just
> 
> cat file > REMOTE_COMPUTER
> 
> and be done with it.

Actually, didn't the old (X,Y,Z)MODEM protocols support this? You'd run
a ZMODEM utility on the remote end, then switch your local ZMODEM client
to receive mode, and they'd sync and transfer the file transparently.

I'm pretty sure this should be possible over the SSH protocol as well,
it just needs client-side support.


> scp is ok if you have keys set up on both sides and they are unix, but
> when you're on putty and just want to dump a file over to the Windows
> side, what I'd love is to hit a command and then get a save as prompt
> on the receiving end. Or, better yet, run a program right on it too.

Hmm. Maybe the way to do it is to have ssh forward some fixed port
number, say 20001 or some such, then have the local ssh client listen to
this port for incoming connections. On the remote end, write a client
that connects to this port, does handshake and transfers (or receive)
the file. The local ssh client would then trigger whatever local Windows
function it is to handle downloads. Then on the remote end you'd do:

	ssh-send myfile

and it connects to port 20001, then the local ssh client picks up the
connection, receives the file, and opens the dialogue to prompt what to
do with it.

Sending would work the same way: say we forward port 20001 in both
directions, then to send a file, you'd run ssh-recv on the remote end,
which listens to the *remote* port 20001, then the local client can
connect to it and transfer the file.

The file would even be encrypted over the connection since everything
passes through the ssh tunnel.


[...]
> >Plus, they don't include quite enough Unicode glyphs for my needs
> >(actually, do they even support unicode at all?!).
> 
> not really, I don't think so anyway. They (at least on my box) have
> some iso 8859-1 characters, but not beyond that.

Yeah, so it's unusable for me. :-(


[...]
> >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.
> 
> god yes, and even the built in DOS graphics could be utterly
> beautiful. Or the OEM font as I guess it should be called. My
> image_basicdrawing.d embeds that font too because I like it lol.
> 
> BTW I'm pretty sure Unicode has a few user defined sections that
> would be ideal for this. You set a bitmap for your user defined
> characters and then send them right out. Though it makes me wonder:
> should it be a 1 bit bitmap? Or palette somehow? idk, for anti
> aliasing it seems to me you'd want to do a few bits that is just
> alpha, with the colors being defined elsewhere. But the NES had a
> sweet 4 color setup for its tiles!
> 
> Eh though, this is a text terminal, let's not go too nuts.

Right, 'cos then the next thing you know, you'd be wanting to support
arbitrary-sized bitmaps, which then leads to it being used for fonts,
which then turns into a proportional font layout problem, which then
turns into a GUI, reinvented. :-P


> The magic display image sequence can be full color.

Yep.


T

-- 
Chance favours the prepared mind. -- Louis Pasteur


More information about the Digitalmars-d mailing list