Re: Great SWT Program
- From: bbound@xxxxxxxxx
- Date: Sat, 03 Nov 2007 23:28:27 -0000
On Nov 1, 8:57 am, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
Not to you at least, that much is clear.
Is this supposed to be some sort of insult? If so, whatever you meant
to imply about me is untrue.
If typing jumps you around to matches instead of inserting what you
type, then I'd say there is indeed an "actual problem". Of course vi
has its command mode to allow overloading the alphabetic keys, and
crufty though that is, it does make such an overload make sense. But
we were discussing emacs, which lacks such a mode...
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!
Do you have a tool that generates random sentences for you? If so, it
would help if you programmed it to construct sentences that have some
link to the preceding discussion.
There was a link. If you couldn't see it, well, that's between you and
your optometrist to figure out.
A shame a unix console app can't use such features, since it has to
pander to the lowest common denominator of terminal types.
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.
Not in emacs. I definitely saw its idea of "windows" used once, and
they split the display into nonoverlapping panes, which quickly got
claustrophobic.
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. It
can't manipulate that window system any more than MS-DOS Edit running
in a DOS Prompt window in Windows can, say to pop up a Windows-native
dialog box.
A graphical port of emacs will presumably amount to a copy of emacs
bundled with a terminal emulation and a bunch of menus and other
graphical commands that produce simulated keypresses, or use the
escape sequences of some fictitious terminal type with quasi-GUI
features to communicate with the emacs lurking inside. A more
sophisticated one would alter emacs itself to surround itself with a
native window, but I still don't see it "understanding" multiple
native windows or dialogs; that would take a complete rewrite as a
true graphical app I would expect. All kinds of formerly-true
assumptions and invariants get violated in such a situation, after
all; the original code will have assumed that every character
displayed had an XY address in a single plane, after all. Everywhere
that that assumption was implicitly embedded in the code would need
rewriting, and the same for every other similar assumption that is
violated by adding proper windowing support.
Perhaps, but all the rational reasons that you have claimed for it
doing so have fallen flat to the ground.
No, they have not. Just because you will apparently resist admitting
the truth with your dying breath, arguing and arguing forever, doesn't
make it not true.
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).
They may be special cases. I don't see a big rush by text editor
makers to do this. You mentioned a full-blown IDE and a Web browser.
Hardly the same thing.
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.
.
- Follow-Ups:
- Re: Great SWT Program
- From: Roger Lindsjö
- Re: Great SWT Program
- From: Wildemar Wildenburger
- Re: Great SWT Program
- From: Bent C Dalager
- Re: Great SWT Program
- References:
- Re: Great SWT Program
- From: Bent C Dalager
- Re: Great SWT Program
- Prev by Date: Re: Great SWT Program
- Next by Date: Re: Great SWT Program
- Previous by thread: Re: Great SWT Program
- Next by thread: Re: Great SWT Program
- Index(es):
Relevant Pages
|
