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



In article <1190377413.447598.150170@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<nebulous99@xxxxxxxxx> wrote:
On Sep 17, 5:36 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
Apparently the people who
write these emulator programs don't mind providing features not
possible with the hardware they claim to be emulating. <shrug>

In other words, they cheated. :)

Define "cheating" in this context.

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.

As far as I know, vim and other text-mode programs are designed
to run correctly in a variety of terminal environments and take
advantage of whatever features are provided by the current
environment (e.g., reverse video, underlining). That they
can also make use of a terminal emulator's ability to display
glyphs[*] that couldn't be displayed on one of those plain-text
consoles of days past to me seems like a logical extension of this
ability to use different kinds of terminals. Is that "cheating"?
whatever you mean by that ....

Putting this sort of support in a text console app/emulator/both is
like putting an altimeter, radar, GPS, and OnStar navigation
technology, and sixty thousand dials and switches into a steam
locomotive and structuring the thing's engine so it will still
function at 30,000 feet and supersonic speeds, even though the only
way it's getting anywhere near either is if you pilot it directly into
a tornado. :P

(What a queer mix of primitive and advanced technology!)

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.

[*] I think that's the word I want -- something that includes
characters from different alphabets, non-alphabetic symbols, etc.

It is.

Good to have that confirmed; thanks.

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
.



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? ... the text terminals of days gone by. ...
    (comp.lang.java.programmer)
  • Re: A computer.
    ... The problem is to make a simple computer with hardware easy to be ... So you advice to make an emulator and when it will be find useful ... as EDO memory driver FPM memory driver or some other memory drivers. ... And from the features of the chip is dependent the features of the software. ...
    (comp.misc)
  • 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)
  • Re: Editors
    ... >> real terminal and not an emulator. ... That applies to the Unisys world (UTS emulation) and to the A-series ... Wsing a PC-based UTS emulator I can make blinking text appear red on ... Since UTS20/UTS40 terminals don't have real colors like the UTS60 does, ...
    (comp.lang.cobol)
  • Re: Editors
    ... "pictures" of what this looks like (either with a 3270 terminal or PC emulator). ... > That applies to the Unisys world (UTS emulation) and to the A-series ... > You might have noticed that the UEDIT screenshot I posted demonstrates ... > Since UTS20/UTS40 terminals don't have real colors like the UTS60 does, ...
    (comp.lang.cobol)