Re: Great SWT Program

On Nov 3, 7:16 pm, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
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.

I don't remember any useful status bar information in emacs. Sometimes
it showed something cryptic, like "M-x:", but no English mode name of
any sort. Usually if something like that appeared I just tried to back
out with esc, which didn't always work, and when it did usually made
emacs complain at the same time, e.g. "M-x ESC ESC: no such command"
or something along those lines. Needless to say the hopelessly
confusing and uninformative status information was one of the reasons
I quickly abandoned all attempts to make use of emacs.

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

I can't see how. You could send a signal down the line and see what
kind of response comes back. Sometimes that might give a clue as to
what sort of device it is. Meanwhile of course it may have had side
effects. The remote terminal might hang, or go into a screwy mode of
some sort. If it's a serial disk drive, it may corrupt or overwrite
something. If it's a printer, it will probably waste ink and paper
printing something spurious. In short, autodetecting what's on a plain
old serial COM port is impractical. USB was designed with something
like this in mind, so there are harmless "identify yourself" signals
all complaint devices should recognize and respond to appropriately;
nothing of the sort exists for the old serial standards like RS-232.

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?

I don't need to be to know that a text-mode terminal-oriented program
sees the display as an MxN array of characters. This therefore is what
(old enough) emacs sees. And this is therefore a design property that
constains any descendant. In particular, no such descendant could
represent overlapping rectangular text regions (i.e. poor-man's text-
mode windows overlapping) without either a major nasty hack or a
complete redesign from the ground up. The assumption that the display
is a rectangular array of characters with only one character per array
cell would have been woven all through the original code. Breaking
that assumption, even if possible, would probably result in a brittle
and bug-prone descendant, unless again it was completely rewritten
from scratch. (In which case why not write a powerful but otherwise
normal GUI text editor instead?)

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.

Thus the argument boils down to your claiming, purely subjectively,
that current GUI apps are "not good enough" in some sense, and being
unable to furnish any reasonable argument or evidence to support your
claim.

There is therefore no point in your continuing it.

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 :-)

It does not, however, include "general text editing", except perhaps
for certain memorization savants. It mainly includes "navigating a
text file in a GUI-less environment while possessing a prodigious
ability to exactly memorize large volumes of ASCII character
sequences", which is quite narrow.

.