Re: Great SWT Program

On Nov 16, 7:06 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
Then why are you backing the wrong horse? The software of the future
will have far more in common with present GUI software, interaction
wise, than with things like vi, although it may have things in common
with the latter under the hood and functionality-wise (automatability,
particularly).

Could be. I find that both paradigms (GUI and CLI) have limitations
and annoyances, but that I personally am apt to find those of CLIs
less objectionable.

This is odd, particularly considering that those of CLIs include
"inability to see WTF you're doing" because information about state
and options is doled out a morsel at a time; you have to do something
explicit to get directory listings; you have to read a name from one
and then type it in to act on it; etc.

The paucity of automatic visual feedback to the user and inability to
see the context of their actions at a glance without explicit querying
is reminiscent of poking around a dark place with a narrow flashlight
beam instead of having the lights on. The need to give verbal
instructions that must be exactly correct or Bad Things may happen, or
at best, nothing but a beep and/or error message, is reminiscent of
having to tell some butler with the IQ of a turnip to do things.
Including aim that flashlight beam. In short, it's like suddenly
becoming a quadriplegic during a power failure. Not fun.

Broad, widespread demand? Huh. I'm not always very clued-in about
what's going on in the world, but would I have missed that ....
Possible, I guess.

The need was clearly there; just witness its rapid adoption once an
implementation appeared on the market. It just went unrecognized, even
by many of those with the need.

My point is that if the connection speed isn't fast enough to
make transfer of large files nearly instantaneous (which is very
much the case with my home setup, though it's certainly faster
than the dial-up access I used to have), it makes sense to avoid
transferring them if one can.

It's faster to transfer a few megs over a T1-speed connection twice
than it is to operate some clunky, shoddily-documented weird excuse
for an "application" remotely over same, I'll warrant.

Besides, we were discussing text editing. Who normally edits text
files even that large? If anything gets that big: reduce, reuse,
refactor. If it's program code this is obvious. If it's TeX or
something like it, there's usually a way to split the file into many
section files included into one master file via directives of some
sort. If it's plain text, just divide it up into separate section or
chapter files with appropriate file names such as "NNN - Chapter
Title.txt".

Only fiddling with large log files seems to have come up as an example
of such. Normally one just reads excerpts or copies some stuff to the
clipboard to paste into a forum posting or something. Grep would
extract the excerpts; with some finesse it could extract a chunk and
its output could be redirected to a new file, which becomes a copy of
the stuff you want to copy. This can be ftp'd over in a wink over a
megabit connection if it's at all short enough to go posting
somewhere. Besides you need it on your local machine anyway to get it
into the clipboard on that machine so you can paste it into your mail
or newsreader or browser or whatever. (Perhaps you could post from the
other machine, but why would you prefer using some clunky text-mode
newsreader over a proper graphical one? It would be painful and
awkward. Posting to a web forum from the remote machine would be
completely out of the question; I've never seen a forum site that
played nice with anything resembling Lynx.)

I understood the original discussion to be about what happens
when you want to work with large files and your connection to the
machine that houses them is not very fast. In those circumstances,
either you transfer the files (which takes time), or you leave
the files where they are and run the application that accesses
them remotely (which is apt to be significantly slower with a GUI
application than a text-mode one). A not-very-fast connection to
a machine elsewhere in the same building -- how common is that?
Maybe more than I know. <shrug>

There are other options. The large file might be wanting refactoring,
for instance; see above. It may even be better off converted from a
flat file to some type of database. Those are designed to allow
efficient remote querying and manipulation, usually via SQL queries,
which a nice graphical frontend app at the client side can generate
behind the scenes. With code, it should be factored down into smaller
files AND put into a CVS/SVN/whatever repository. Logfiles that get
huge and need manual inspection and suchlike are amenable to the grep-
remotely, use-distillate-locally strategy, and maybe should be set up
to drop entries older than n days or only ever contain the last 100
entries or some such anyway, or at least have the newest 100 entries
or most recent 7 days worth of entries automatically present by
themselves in one file as well as appended to another, which would
much more rarely need any consulting.

Many applications I use regularly have *some* function that
involves potentially entering a line of text -- even something
as simple as entering a URL to a Web browser. <shrug>

For which a full blown text editor is overkill. All it needs to do is
accept typed input, enter to submit, left and right arrow, bksp and
del, shift-same, cut, copy, and paste, and in some cases some form of
autocomplete and/or history would be nice, too.

Sure it does. emacs is not lying, only telling you something in
its language

Which language? Are you saying that the English localization doesn't
behave the way Bent's apparently-Norwegian copy does?

I mean that emacs terminology differs from Windows terminology,
though both may use English words.

This wasn't a discussion of terminology (e.g. buffer vs. document)
however. It was a discussion of the selection highlight's behavior.
That obviously is orthogonal to terminology as much as it is to key
bindings.

Except that yours only work in the one application,

Untrue. 'j' and 'k' move up and down the list of messages in mutt
(mail program).

I don't take kindly to being publicly called a liar.

I also don't see these as being "the same bindings", which would be
"move up and down inside text being edited".

And as I understand it, the original vi borrowed its keybindings
for cursor movement from some game that was popular at the time.

Well, THAT would explain a great deal. Pity they didn't pick WASD
instead; those at least have a suggestive layout (on a normal keyboard
anyway) that would aid memory in which did what.

and whereas undo
can't possibly be mapped in a "relational" way, direction keys clearly
can.

But it could be mapped to something more mnemonic, something
involving U or u. Why isn't it? (There could well be a reason;
I don't know.)

A flaw in Windows CUA. I never claimed that there were none. :P

Arguably even the terminology chosen was less than ideal. Cut and copy
have the unfortunate feature of sharing the same initial letter. Two
ways it could have been better include using ctrl-C for copy and alt-
ctrl-C for cut (shift-ctrl-C risks trouble if you let go of shift a
fraction late after that last selection-extending move and before
hitting ctrl-C; adding extra chording for the "dangerous" stuff-
deleting command makes it less likely to be hit accidentally, though
copy also is "dangerous" inasmuch as it clobbers the clipboard). Ctrl-
P for paste would have been better, as paste is far more commonly done
than print and putting it far from cut/copy would reduce the danger of
miskeying one of the trio causing one of the other two to execute.
Renaming the operations opens up more possibilities: duplicate in
place of copy lets you map that to ctrl-D and cut to ctrl-C for
instance, with the downside that they can easily be accidentally hit
in place of each other as they're adjacent on a normal keyboard. Or
using ctrl-del for cut instead of ctrl-X, leaving ctrl-C as copy and
using ctrl-P for paste. Of course, it's water under the bridge; CUA is
too widely supported and entrenched to change now.

Answered below. Why then didn't you go back and delete this part
of your reply?

It would have taken extra time and I had about 80 other posts
requiring replies to reply to at the time and an annoyingly short day
in which to do it -- only 24 hours long. :P

Lines make sense when working with code, which I suspect was the
most common use case foreseen when these applications were developed.

True, but nowadays an IDE also makes sense when working with code.

AFAICT both emacs and vi were designed more to be very primitive proto-
IDEs than to be simple text editors, and then the job was done bass-
ackwards, resulting in an unholy mess in emacs and something nifty in
an abstract way but nigh-unusable in the case of vi. Curiously they
have me in mind of two things more deliberately developed to have such
traits: INTERCAL and brainfuck, respectively. (Or maybe one of them
should be befunge instead? Maybe edlin is like brainfuck and vi is
like befunge ... or something ... which would even have been cool if
only it had been done on purpose.)

"Not so much", as they say. If I'm deleting a few words, I'm
probably going to type "dw" and then "." (repeat previous change)
as needed. The "lawyerly rules" to which you refer -- oh, I'm not
going to try to spell them out; I'll just say that they make sense
to me in context, and I'm rarely surprised by my tool's behavior.

Well, I'm *never* surprised by mine when using bksp or del. And, of
course, when one is deleting things, this failure of the UI to
surprise assumes extra significance.

You seem to have trouble imagining that anything other than
what you're used to could be convenient and quick. There are
vim equivalents for everything you describe, with the possible
exception of "delete everything from the start of line to here".

But they don't come naturally, nor do they compose tidily the way the
Windows nav keys + mouse, shift to modify selection state, and cut,
copy, paste, and delete do.

Probably true of code written by experienced users for experienced
users. A lot of the code I write these days is meant as examples
for beginners. Comments seem more useful there. Not a common
situation, I guess.

I wonder if ultimately such comments are more of a crutch than a
genuine educational aid for students. If they saw mature, well-
factored, readable and maintainable code with a normal (low) amount of
comments they'd pay more attention to what the code says it does and
less to what the author of some comments says it does, perhaps.

Then again, perhaps not. You do have more experience teaching the
subject than I.
.

Relevant Pages

  • Re: Backup question
    ... Minor disadvantage - only one backup. ... >same time is remote (though not impossible if caused by, say, a nearby ... Power supplies and perhaps disk controllers can also cause common ... If the hill is high enough and far enough away from the beach, ...
    (alt.computer.security)
  • Re: Kin Selection contradiction?
    ... >> above statement for all cases in which the allele in question is not ... I agree that a fixed or common allele arose (in the sense of formal ... cause) from a single mutation which happened once in some remote ... It is also important to note that formal cause IBD, ...
    (sci.bio.evolution)
  • Re: iLO - 3200 32 in. LCD Television problems
    ... The remote was built with the ... There is only one fix brain surgery replace the ... but this failure is a bit too common for too many ... of what fails in these sets. ...
    (sci.electronics.repair)
  • Re: insurance question
    ... I'd agree I don't think remote start is a very common *factory option* in the ... This is the first post I've seen from you asking me a question. ...
    (uk.legal)
  • Re: No tail-recursion optimize in clisp?
    ... completely correct association of the terminology to Common Lisp? ... It's mostly a matter of resistance to the terminology. ... he prefers "space-efficient tail calling" ... I agree that I (as do other Common Lispers) resist this terminology. ...
    (comp.lang.lisp)