Re: Great SWT Program

In article <1194132507.254404.144830@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<bbound@xxxxxxxxx> wrote:
Why would you assume that? Emacs has however many "modes" you care to
program into it, and a number of "modes" are available out of the box.
Incremental search "mode" would be one. Directory browsing "mode"
another, command "mode" yet another.

Oh, just *wonderful* then. That means that a) one of the things emacs
people keep saying in their war with vi people is a lie, and b) emacs
is even more confusing and difficult to use than it initially appears.
What mode is it in? No-one knows! Hit a key and try to guess what will
happen! Fun for the whole family!

If you are incapable of remembering five seconds back, and also
incapable of glancing at the status bar to see which mode you are in -
yeah, you're up *** creek without a paddle.

Console apps programmers have long since discovered something that you
apparantly have not: it is possible to detect the terminal type and
act accordingly.

Bollocks. It has no way of knowing what's actually at the other end of
a serial connection. It could be a terminal of any of several types, a
terminal emulator running on a full-blown computer and emulating nigh-
anything, a serial printer, a disk drive of one of certain older
models, or just plain nothing. Perhaps it can be told it's something
particular, but there's no way for it to autodetect anything. We're
not talking modern sophisticated things like USB here, after all.

And yet, despite the universe-shattering impossibility of it all,
software programmers tackled this problem several decades ago.

That is what emacs calls a "window", yes. What /you/ probably call a
window is what emacs calls a "frame". Frames can overlap to the extent
that the underlying windowing system that you use permits them to.

Emacs doesn't *have* an "underlying windowing system". It sees the
display as an MxN array of characters, which may or may not actually
be the inside of a terminal emulator window on a window system.
(...)

And you have been an emacs programmer since . . . when?

A graphical port of emacs will presumably amount to (...)

A graphical "port" of emacs does, in fact, amount to the emacs that
most people today use.

Do you have something more
concrete than personal preference to support the notion that text mode
sucks?

Sure: the mathematically provable greater flexibility and information
capacity of a fully bitmapped display in which every pixel can be
individually and separately controlled. One way to check this out is
to note the amount of video RAM needed to display a) a text mode
display and b) even one of the crummier graphics modes, say
800x600x8bpp. The more memory needed, the more information the display
mode can convey to the human user per video frame (so generally around
sixty times a second).

And this still does not prove that superior "GUI" applications /do/
exist - only that they /might/ in some possible universe.

Indeed - incremental search is so powerful, it is applicable for a
great number of different software types.

Alternatively, it's only in niche circumstances that it offers any
real benefits over normal "incremental-find-next" search.

And of course, so long as this niche includes general text editing, I
shall remain a happy puppy :-)

Cheers,
Bent D
--
Bent Dalager - bcd@xxxxxxx - http://www.pvv.org/~bcd
powered by emacs
.