Re: OT: Unicode and vi(m). Was Re: Great SWT Program



On Sep 22, 2:55 pm, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
The more I think about it, the more I think modern "terminal
emulator" programs probably don't claim to be emulating any
particular form of antique hardware. I mean, the terminal type
for the GNOME one is "xterm" and not "vt100". Was there ever
hardware corresponding to the "xterm" terminal type? I'm not sure,
but I'm inclined to think not, or that if there was, it was an
"X terminal" that would provide features well beyond those of
the text terminals of days gone by.

This begs the obvious question: what is a "terminal emulator" for, if
not to provide an environment for genuinely archaic software to run?
Apparently, to run recent but intentionally "retro" software. What,
however, is the attraction to deliberately "retro" software that
hearkens back to the bad old days of limited system memory and
performance and the consequent terrible, terse and cryptic user
interfaces?

Your analogy sure is. I don't quite get how the analogy applies
to vim, but maybe that just means I lack the right kind of
imagination.

Well that depends on what vim really is. I had been thinking it was an
archaic text editor designed for a far more cramped and claustrophobic
computing environment of the days of yore, clearly obsolete given the
capabilities of modern hardware to run software that gives a far
better user experience and provides far greater capabilities for
display and user interaction.

On the other hand, it's starting to sound like it might instead be
fairly recent but deliberately retro, like a 50s-style diner downtown
that was actually established in the 90s but has the old fashioned
jukebox, the look, the type of menu fare, and all that to fit in with
its historical counterpart. Except that in this particular case, I'll
bet you get the flies everywhere, the refusal to serve black people,
greasy food high in trans fat, and all the other "bad" things to make
a truly authentic 1950s experience. :P

Maybe better, given how fast computers have advanced relative to food,
and how much work it is just to get started doing even the basics in
those archaic Unix programs, would be to compare it to a 50,000 BC
style diner -- you have to catch the food yourself and rub sticks
together to start a fire with which to cook it.

All in all, the attraction to such tools, whether they're the
equivalent of a lovingly-maintained 1950s Chevy convertible or a retro
diner, mystifies. Unlike the car or the diner, the user interface is
going to be terrible; the car's sure to be a manual transmission, but
at least you don't have to take the engine to a water trough and later
tell it "Giddyap!" to make it go. The software from that era being
that primitive by comparison with modern tools.

.



Relevant Pages

  • Re: OT: Unicode and vi(m). Was Re: Great SWT Program
    ... emulator" programs probably don't claim to be emulating any ... particular form of antique hardware. ... hardware corresponding to the "xterm" terminal type? ... to run recent but intentionally "retro" software. ...
    (comp.lang.java.programmer)
  • Re: OT: Unicode and vi(m). Was Re: Great SWT Program
    ... write these emulator programs don't mind providing features not ... possible with the hardware they claim to be emulating. ... ability to use different kinds of terminals. ...
    (comp.lang.java.programmer)
  • Re: OT: Unicode and vi(m). Was Re: Great SWT Program
    ... emulator" programs probably don't claim to be emulating any ... particular form of antique hardware. ... hardware corresponding to the "xterm" terminal type? ... but -- I also remember the xterm mode, ...
    (comp.lang.java.programmer)
  • Re: OT: Unicode and vi(m). Was Re: Great SWT Program
    ... emulator" programs probably don't claim to be emulating any ... particular form of antique hardware. ... hardware corresponding to the "xterm" terminal type? ... It is a superset of the ANSIterminal type, itself a superset of the VTxxx types. ...
    (comp.lang.java.programmer)
  • Re: teaching a child - console or GUI
    ... Actually I have a problem controlling my 'moron's' hardware ... >simultaneous terminal and server failure to mess up their totals. ... it can just go along and re-load it's day totals from the files. ... (although I am now unsure about the interactivity of your terminals) ...
    (comp.lang.pascal.delphi.misc)