Re: Great SWT Program - Java

On Nov 16, 5:48 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > Well, given that you presumably can't just select and delete
> > normally ...
>
> Where "normally" appears to mean "as one does in typical Windows
> applications".

Does vi even *have* selections? (I can't recall ever seeing any,
though I haven't seen vi in action all that much, as I tend to avoid
it like the plague.)

> Yes, I suppose you do. But what you say about vi and emacs
> reminds me strongly of my own rants about Windows, with one
> difference: I recognize on some level that I'm ranting based on
> very limited knowledge, so the ranting should be considered more
> as entertainment than as serious critique.

However, mine is a serious critique based upon on actual experience
with various attempts to actually use emacs and vi.

> Uh-huh. In old-style X11 applications, cut and paste is done
> by selecting text with the left mouse button and pasting it
> with the middle mouse button.

That's wrong on so many levels that I can't even count them all. But
for starters, just about any activity is going to clobber the
clipboard. Select a region and hit paste to replace it with something
you cut earlier and you're in for a nasty shock from the sounds of it.

> I don't remember that working in Windows applications.

Of course not, because Windows doesn't a) gratuitously violate the
standard or b) make it quite as easy to clobber the clipboard, or
impossible to paste-replace a region for that matter.

> > I don't NEED to know much about either vi or emacs to notice that they
> > are awkward to try to learn, awkward to try to use, and never did
> > anything for me that I couldn't get far more easily from a GUI editor
> > that behaved normally.
>
> With all due respect, I claim that your opinions about whether
> these tools are easy to learn are valid, but your opinions about
> whether they provide any benefits to expert users -- how could
> you possibly know?

I can't conceive of a benefit that they might theoretically provide
(with enough intensive training) that isn't more readily gotten from a
normal editor, or else superfluous in such because it's easy to
accomplish the same goal by completely different means using the GUI.

The things that have been mentioned are:
* Incremental search -- a marginal improvement over regular search for
read-only media, and a toss-up for read-write, including any text
editor at all, if implemented in such a way that you lose the ability
to hit next match, edit something nearby, hit next match, etc.
* IDE-type functionality -- Eclipse has this stuff in spades and has a
normal GUI, normal editing bindings, etc.
* Automation of a sort -- most of this stuff is done differently but
as easily with Windows tools and copy/paste. Some more is rendered
superfluous, e.g. importing a list of files, fiddling with it to e.g.
filter some, then turning it into a script or feeding it to a command
line tool as a list of arguments, because of the graphical shell in
Windows and the Mac that integrates search and provides the ability to
move, delete, etc. results directly from the result list without
needing to either retype everything in the listing or import it
somewhere or otherwise redirect stdout, schlep things around, etc.; a
few mouse clicks and you've found a bunch of files and nuked them or
whatever. Handy if you have a batch of 50,000 files of which some need
deleting, all of those have "foobar" in their names, but not all of
the ones with "foobar" in their names need deleting; if there're only
50 with "foobar" in their names you can get a window showing only
these with search, and it's a manageable number to inspect one by one
and delete. If the further criteria for deletion beyond containing
"foobar" in the name would be AI-complete to specify, even your
regular expression tools would be of no additional help, and I find
those of marginal added utility to normal search at best due to the
complexity and difficulty involved with each use. Matching tens of
thousands of files or more according to a complex file name or content
criterion is the only circumstance where I can imagine the work
involved in crafting the exactly correct regexp query would be worth
the payoff in automation, given that a regular search can still
whittle down the list of files by a factor of at least several dozen.
And let's not forget that by searching, moving the hits to a working
directory, and then searching either the moved hits or the directory
now containing only the misses, and repeating as appropriate with
various queries used, one can perform a boolean search too, and
without having to consult some reference for some obscure line-noise-
like syntax. Boolean search should whittle it down by a factor of 100
or more in most likely cases and leave few false positives relative to
a perfectly targeted regexp search. Regexp rarely seems to give enough
bang for the buck.

> > Neither of you likes the idea that someone might know a fair bit about
> > either tool and STILL slam it, methinks, so you try to dismiss me as
> > not knowing much about them...
>
> You're right that I don't like that idea. But with every post you
> reveal that you don't know how these tools work, and you seem
> determined to think the worst of them.

I know enough about how they *don't* work and have enough experience
trying to use them to know that they're no good and awful.

How they work, i.e. implementation details, should not matter when
discussing the relative merits of the user interfaces. That they
apparently do in the case of vi and emacs is, all by itself, a damning
indictment of both.

[rest snipped]

On Nov 16, 6:06 am, Roger Lindsjö <news.nos...@tilialacus.net> wrote:
> At least in Word ctrl-backspace deletes until the end of previous word
> and ctrl-delete to the end of the current word. Ctrl-(left/right)
> behaves very similar. Ctrl-up moves to the beginning of the paragraph
> unless already there, in which case it moves to the beginning of the
> preceding paragraph. Ctrl-down moves to the beginning of the following
> paragraph.

Delete to end of previous word sounds marginally useful.

The ctrl-left and ctrl-right bindings work in Notepad, but ctrl-bksp
and ctrl-del both appear to delete-to-end-of-line, which shift-end del
does just as well; the latter comes more naturally because it's a
composition of more basic and quite common commands. The ctrl-up and
ctrl-down keys seem to do nothing in Notepad.

Shift-ctrl-left and shift-ctrl-right move by a word extending
selection, consistent with shifting other movement commands.

Interesting.

On Nov 16, 7:06 am, blm...@myrealbox.com <blm...@myrealbox.com> 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 brain***** 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.

On Nov 16, 7:28 am, Pavel Lepin <p.le...@ctncorp.com> wrote:
[calls me a liar]

None of the nasty things that you have said or implied about me are at
all true.

In article <eaddabb5-457c-4789-81c3-1893e5c83b02@w73g2000hsf.googlegroups.com>,
<twerpinator@gmail.com> wrote:
>On Nov 15, 5:56 pm, Tristram Rolph <trist...@trashymail.com> wrote:
>> I find it hard to believe that you can't imagine it to be faster, given all
>> the other things you imagine about emacs and vim.
>
>???
>
>> If it was actually faster for us to select and delete using a mouse,
>> then we would do it using the mouse.
>
>Except that you can't.

Tristram, you need to understand that Twisted has arbitrarily decided
that emacs and vi users are not permitted to use the mouse. So far, we
have decided not to humour him.

>You have odd deletion needs then. I find I most frequently delete:
>
>* Part of all of the most recently typed word. Bksp held down does a
>quick job here; much quicker than a hypothetical move to start of
>word, switch to command mode, "dw", and switch back, the first step of
>which all by itself would take exactly as long as just nuking it with
>bksp.
>* A goodly chunk of the most recently typed sentence. Shift-home, del,
>or shift-home, hold shift-right, del works wonders, or shift-home del
>left and hold bksp, if it started late on the last line. Shift-home
>del isn't much different from switch-to-command-mode dl (or whatever)
>switch-back. A little quicker I'd expect.

How incredibly cumbersome when a couple of C-_ will do the job much
faster and with considerably less need for accuracy and manual
oversight.

>* A much larger chunk, or a chunk elsewhere in the document. In that
>case the fastest way to get to the start is a mouse click. That will
>take a fraction of a second; it would take one or more full seconds at
>least to reach it in any other way (including invoking an incremental
>search and then typing stuff) especially if it's more than one screen
>up. Once that's done it's quickest to shift-click the other end and
>hit del.

I'd be interested to know how you're planning to move your hand to the
mouse, move the pointer to the scrollbar, drag the scrollbar to the
precise location you want, relocate the mouse pointer to the character
you want, and move the hand back to the keyboard - in a fraction of a
second. Unless that "fraction" is, say, 1/0.5 . . .

>Deleting forwards a word at a time seems unuseful to me. I never find
>myself wishing for such a feature.

That's presumably because we adapt our needs to the tools that we
have.

>One thing I find laughable in all of this is how Bent will praise his
>invisible and oddly-behaving selections on the grounds that you only
>need it for a few seconds and should be able to remember where it is
>for that long, then denigrate Windows' easily-canceled selections for
>their fragility even though they only need to last a few seconds by
>his reckoning.

Losing a selection is all the more annoying when it is only half a
second since you made it.

>Which, of course, is leaving aside the minor matter of how visual
>feedback also aids in on-the-fly error correction; if the selection is
>slightly out of whack you'll *see* it with a typical native Windows
>(or Mac) app *before* you do something like delete it. Instead of
>having to undo, then remake the selection, you just have to remake the
>selection; saves time and work the sooner you can spot something like
>that. Of course you can't spot what you can't even see...

Since search-based selection is driven by context rather than by
geometry, it will tend to be erroneous less often: mouse-based
clicking easily misses by a character or two - text-based search is
not prone to this.

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

In article <6b00d6a8-7443-460b-b3ea-aa583ca8d4ec@w28g2000hsf.googlegroups.com>,
<twerpinator@gmail.com> wrote:
>On Nov 15, 5:31 pm, Owen Jacobson <angrybald...@gmail.com> wrote:
>> Screen's killer feature is that it keeps
>> the session running if the screen client loses its connection or shuts
>> down, blah blah blah...
>
>Of course, this is only of interest if you're doing remote stuff.

Which I do.

> For
>that, I expect a simple ssh session and an (s)ftp session, plus a
>bunch of local tools, to suffice,

One of those tools being screen.

> with the ssh session used to launch
>noninteractive jobs to generate distilled-down material to schlep over
>via ftp and work on with local interactive software,

My tools are powerful enough not to force me into awkwardness like
this.

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

In article <e2da8b29-d834-44c1-a6fa-c76ccdf69059@d61g2000hsa.googlegroups.com>,
<twerpinator@gmail.com> wrote:
> On Nov 16, 5:48 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> > > Well, given that you presumably can't just select and delete
> > > normally ...
> >
> > Where "normally" appears to mean "as one does in typical Windows
> > applications".
>
> Does vi even *have* selections? (I can't recall ever seeing any,
> though I haven't seen vi in action all that much, as I tend to avoid
> it like the plague.)

"Real" vi doesn't. vim does.

> > Yes, I suppose you do. But what you say about vi and emacs
> > reminds me strongly of my own rants about Windows, with one
> > difference: I recognize on some level that I'm ranting based on
> > very limited knowledge, so the ranting should be considered more
> > as entertainment than as serious critique.
>
> However, mine is a serious critique based upon on actual experience
> with various attempts to actually use emacs and vi.

I strongly suspect that I have more experience with Windows -- and
more-current experience -- than you have with vi and emacs combined.

> > Uh-huh. In old-style X11 applications, cut and paste is done
> > by selecting text with the left mouse button and pasting it
> > with the middle mouse button.
>
> That's wrong on so many levels that I can't even count them all.

And yet it's the convention, for old-style X11 applications.
That would seem to counter your claim about the existence of
"universal GUI/mouse conventions" -- which was the point I
was making.

> But
> for starters, just about any activity is going to clobber the
> clipboard. Select a region and hit paste to replace it with something
> you cut earlier and you're in for a nasty shock from the sounds of it.

I'm not sure how well this earlier convention interoperates with
the ones adopted from Windows (and Mac?).

> > I don't remember that working in Windows applications.
>
> Of course not, because Windows doesn't a) gratuitously violate the
> standard or b) make it quite as easy to clobber the clipboard, or
> impossible to paste-replace a region for that matter.

"The standard" -- as if there were only one. Pfui.

[ snip ]

> I can't conceive of a benefit that they might theoretically provide
> (with enough intensive training) that isn't more readily gotten from a
> normal editor, or else superfluous in such because it's easy to
> accomplish the same goal by completely different means using the GUI.
>
> The things that have been mentioned are:
> * Incremental search -- a marginal improvement over regular search for
> read-only media, and a toss-up for read-write, including any text
> editor at all, if implemented in such a way that you lose the ability
> to hit next match, edit something nearby, hit next match, etc.
> * IDE-type functionality -- Eclipse has this stuff in spades and has a
> normal GUI, normal editing bindings, etc.
> * Automation of a sort -- most of this stuff is done differently but
> as easily with Windows tools and copy/paste. Some more is rendered
> superfluous, e.g. importing a list of files, fiddling with it to e.g.
> filter some, then turning it into a script or feeding it to a command
> line tool as a list of arguments, because of the graphical shell in
> Windows and the Mac that integrates search and provides the ability to
> move, delete, etc. results directly from the result list without
> needing to either retype everything in the listing or import it
> somewhere or otherwise redirect stdout, schlep things around, etc.;

Could be. I'm not convinced yet that "your way" interoperates
nicely with the set of tools I've already mastered. Of course,
perhaps mastering them was a waste of time too ....

(I wonder whether anyone else finds your long long paragraphs
difficult to read.)

[ snip ]

> And let's not forget that by searching, moving the hits to a working
> directory, and then searching either the moved hits or the directory
> now containing only the misses, and repeating as appropriate with
> various queries used, one can perform a boolean search too, and
> without having to consult some reference for some obscure line-noise-
> like syntax. Boolean search should whittle it down by a factor of 100
> or more in most likely cases and leave few false positives relative to
> a perfectly targeted regexp search. Regexp rarely seems to give enough
> bang for the buck.

"Could be" again. I only really learned regular expressions a few
years ago, and I do find that sometimes they give me a shorter way
of doing something. Worth the time to learn? Hard to say.

As for the scenario you describe, I might be inclined to pipe the
result of the first search into grep or some other tool that would
allow me to narrow the search. <shrug>

[ snip ]

> [rest snipped]

Ah yes, the part about how I think your attitude toward my tools
strongly resembles my attitude toward yours, which leads me to
believe that both are based more on prejudice than .... Well,
whatever.

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.

In article <eaddabb5-457c-4789-81c3-1893e5c83b02@w73g2000hsf.googlegroups.com>,
<twerpinator@gmail.com> wrote:
> On Nov 15, 5:56 pm, Tristram Rolph <trist...@trashymail.com> wrote:
> > I find it hard to believe that you can't imagine it to be faster, given all
> > the other things you imagine about emacs and vim.
>
> ???
>
> > If it was actually faster for us to select and delete using a mouse,
> > then we would do it using the mouse.
>
> Except that you can't.

At least one person (me) has told you that this is possible. You
don't believe us (me)?

[ snip ]

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.

In article <71f724d4-eefd-4c61-9b38-2efd6935d02f@f3g2000hsg.googlegroups.com>,
<twerpinator@gmail.com> wrote:
> On Nov 16, 7:06 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:

[ snip ]

> > 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;

I prefer to think it as "not cluttering up the screen with stuff
I don't need right now".

> 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.

Your mileage varies. I find that typical GUI applications try to
guess what I might want and leap to provide it, whether it's actually
what I want or not.

> > 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.

Quite. People didn't know how useful a thing the WWW would be
because it didn't exist, and apparently not many people imagined
it, so there was no widespread demand. That's a different thing
from its being widely adopted when it *did* appear.

Similarly, perhaps there are things about my platform of choice
that many users would find invaluable if they knew about them.
Or perhaps not -- but my point was that if they don't know about
them (as people didn't know about the WWW in 1990) they might not
think to demand them, whereas ....

> > 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.

Could be. I don't have a T1-speed connection from home. You do?
How nice!

> 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".

Text editing that might involve referring to large files, perhaps
cutting and pasting from them.

[ snip ]

> > 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.

Perhaps something to go to the beginning/end of the line as well?

Otherwise -- sure, but why *not* do all of this, however limited it
is compared to full-blown text editing, with the same keybindings
used in one's text editor?

[ snip ]

> 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.

"Terminology" doesn't include what "selection" means in the context
of (some?) computer applications?

> > > 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.

Not a liar, just mistaken.

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

Whatever.

[ snip ]

> > "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.

Except that "undo" seems to work pretty well in vim.

> > 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.

Actually they *do* compose nicely -- "d" followed by one of the many
cursor-movement commands deletes up to wherever the cursor would move
with that command.

> > 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.

Yes .... Well, some of the situations in which I find comments
useful involve explaining what some bit of syntax (e.g., #define
in a C program) does. And real "beginners" -- they don't find
*any* code readable, do they? though I do try, and the comments
aren't as extensive as you may be imagining.

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

Probably true.

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.