Re: Great SWT Program

On Nov 30, 5:46 am, Andreas Leitgeb <a...@xxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
Irrelevant.

No, not.

Do not bluntly contradict me. Ever.

because not all text-apps care about what happens with
their output. E.g. "echo" just prints out its stuff, and leaves
the preserving of that output to whatever terminal you have.

But the text-apps at issue in this thread, vi and emacs, are not
"echo".

Afterall, it was *you* who said, that you couldn't think
of *whatever*. If *we* say, that you can't think of some
particular thing, you usually call that an insult.

Because if *you* say anything of the sort it's intended to call my
intelligence into question, and therefore is an implied insult.

That's what Bent claimed too,

Of course, since he is not lying.

But you can't use only one key to make selections and issue a copy
command, not without doing something pretty nasty in the way of
depending on the timing channel for semantically-important
information, which would be a huge pain for users. The simplest I can
think of is making a double-hit of the key start a cursor scanning the
display, and one single hit flags the current position as the start of
the selection, another flags the then-current position as the end and
does a copy, and a third does a paste. Even then, the underlying
application may be modifying the display or trying to move the cursor
at the same time, creating a race condition and serious problems. This
isn't an issue with a graphical tool like a DOS box or xterm, which
can have its own cursor/selection independently of the underlying
application's and can have a menu or other separate-keyboard-focus UI
to accept some forms of input, as well as use mouse input. Screen
lacks any of these possibilities, being text-mode itself, which means
it and the underlying app will contend for the one and only text-mode
hardware cursor (or emulation of same). A DOS box is a full blown VM
for running DOS apps these days too, which means it can actually
suspend and resume the underlying app as needed so that it freezes
while you make selections, or can be paused by the user. A DOS box and
an xterm have a scrollback buffer you can copy from undisturbed --
though this won't capture anything from "curses-type" apps, at least
not reliably. Screen and an xterm however can't pause and resume the
attached process, since it's a separate unix process running on the
real hardware; neither of them is actually a VM running the process.
Either might freeze what it displays, but the underlying process would
be marching on and the user not seeing whatever the heck they are
doing anymore. The DOS box, in essence, lets you pull over to the side
of the road to take photographs; screen or an xterm will effectively
have you jump out to take photographs while the car continues on,
pilotless and undoubtedly magnetically attracted to the nearest deep
ditch, lamppost, or tree. Or into oncoming traffic. :P The user would
have to do something app-dependent to pause the application to avoid
such difficulties -- if the application even allows it. (But for vi
and emacs that shouldn't be a problem. They *do* just sit quietly
doing nothing autonomously until the user types, as text editors
normally do, don't they? Then again, assuming that either of those
does what a normal text editor does may not ever be very wise ... no
matter how fundamental and sacrosanct the behavior in question
normally is to that application type.)

The only thing silently implied

In other words, lied about by omission?

While in selection-mode, of course all keys go to screen. they
are not intercepted, but consumed. The difference being, that
during this mode *no* key-press at all reaches the app inside.

And it coasts on, pilotless, into the nearest lamppost?

I can't see how this concept can look strange to you:
A windows app, that has a modal dialog open, cannot even be moved,
nor closed nor done anything in it, until the modal dialog is finished.

But the modal dialog is *visible*, and provides its own obvious UI.
Screen accidentally entering this mode may seem to have simply locked
up, or the underlying application will seem to have locked up,
assuming screen also provides a frozen view. If it doesn't, the app
seems to have simply stopped responding to user input while continuing
to do whatever it does autonomously (and if that's the empty set it
still looks to have hung).

(This of course is not so broken on graphical linux/unix desktops: at
least you can still move/resize/iconify the main window of such an app)

You normally can iconify in this circumstance in Windows too, via the
modal dialog box's own minimize button; minimizing a modal dialog box
minimizes the entire app. Of course it's up to the programmer whether
to provide a minimize button on the dialog box.

You can always bring other windows to the front to cover the
bothersome one as well. And you can always right click the taskbar and
choose "Show the desktop" (in WinXP at least) to minimize everything
at once, regardless of whether a particular app provides any minimize
buttons of its own at all. Moving or resizing won't work (though the
modal dialog may be movable, moving it won't move the underlying
window; it won't be resizable as a general rule, though that isn't an
ironclad guarantee, and even if it is that likewise will only resize
the dialog itself).

In practise, I don't find this situation at all bothersome. I find
invisible modal states to be far more so. I'd previously mentioned XON/
XOFF flow control on Unix text-mode software as one such that can
cause consternation, and vi's command mode is an infamous example of
the species. In general, they make software vastly harder to learn,
and significantly harder to use particularly if the mode can easily be
entered accidentally. On Windows machines, three modes *almost* fit
this description -- menus can activate and grab focus with only subtle
visual changes to indicate what's happened, and caps lock and (not as
often these days) overtype mode can engage unexpectedly with only a
keyboard LED to indicate that anything has happened. The latter two
are quickly discovered when editing text and quickly fixed, at least;
menu-activation is a bit more bothersome sometimes, because attempting
to type may trigger a more-or-less random menu command that may do
something drastic. Caps lock used to be a problem with password entry,
too, but typically you'll notice it either when typing your username
or when Windows warns you that you're about to type a password with
caps lock on.
.