Re: Great SWT Program

On Nov 18, 7:42 pm, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
Of course not - most people will probably never be trained in emacs.

So much for your claims of its superiority then. If it were truly
superior it would displace other editors given time.

You are (deliberately?) muddying the issue.

I grow tired of your incessant digs, barbs, accusations, and insults
like this one. I am doing nothing of the kind. Stop accusing me of
***.

"Superior" means different things for different people. Considered
in relation to emacs, notepad and its like is largely to be
considered a disruptive technology: inferior but more popular.

Define "superior" then. Empirically, the market should be a good
instrument for measuring it, because it's completely impartial.

If you're thinking Betamax vs. VHS, you need to consider the network
effects and not just each type in isolation. Early in the game,
Betamax may have been superior because only the technical capabilities
counted. Later, the porn industry began to discreetly deliver plain-
wrapped video tapes to customers -- a killer app for home video,
watching stuff you wouldn't want to watch in public view. They
overwhelmingly provided only the VHS format and suddenly, VHS became
superior for porn viewers. As there are many of these, the VHS format
gained market share until it greatly exceeded 50%, and network effects
became important as the overall market began to be significantly
saturated. The costs involved in supporting both formats meant that
oftentimes the best choice for a video seller was to support only the
more popular one, i.e. they would make more money that way than by
supporting both. This happened once the additional cost of producing
Betamax tapes exceeded the expected net revenue from the small pool of
Betamax customers. Customers in turn would prefer the format with the
most content. So once one market share (VHS) got large enough and the
whole market had gotten large enough, a snowball effect took place:
due to content availability differences, VHS was now superior for non-
porn viewers too, and so it was superior for vendors, and this
spiraled until it was increasingly, enormously the superior choice.
Then Betamax disappeared, and VHS was the *only* choice.

Network effects also make word processors that can read the latest
Microsoft Word .doc files superior to those that cannot, at any given
time.

In the case of vi and emacs vs. normal editors, there's no network
effects as such, but it's clear that for the vast majority of people
something easier to use is superior to vi and to emacs. You and a few
other people are evidently exceptions. You type differently, you
perhaps have different information-processing needs or goals, and you
appear to even think differently, and that makes a niche for emacs and
vi. They aren't however like Betamax; they're much more like stick
shift vs. automatic transmission cars, with niche appeal for certain
personality drivers and mechanics that like to tinker, but inferior
for the general car-driving public due to their greater difficulty and
awkwardness in use.

As a general rule, that makes the automatic transmission superior:
there'd me more chaos, unpleasantness, or whatever if they were no
longer available than if stick shifts were no longer available. They'd
be missed by far more people. The impact on the economy from such an
event would be greater. And so forth.

The disparity is even more extreme with emacs and vi. Far more people
would be bothered or else hear someone else complaining about it if
all cars suddenly only had automatic transmissions than if emacs and
vi mysteriously disappeared off the face of the earth. On the flip
side, almost everybody in the entire world, from casual home users to
business users and including a large number of Fortune 100 CEOs, would
scream bloody murder if it were suddenly the 80s again as far as
computer UIs were concerned; if automatic transmissions were suddenly
gone (e.g. found to have a subtle but definite link to higher accident
rates and so banned, unlikely though that sounds) a nearly as large
set of people would grumble and then quickly learn to manage with a
stick shift. :P

For the dedicated or professional text editor user, however, emacs
remains the most powerful and effecient alternative.

This is an unqualified blanket statement that is certainly false. You
feel the need to arrogantly opine that your personal preferences for
things like that constitute objective measures of superiority, and
that anyone who does not have the same preferences as you has inferior
preferences, is inefficient, or something like that. You sound like a
certain ex-Borg I know, but lack the redeeming feature of being easy
on the eyes. :P

You need to accept that it is you who is unusual here; the preferences
of the general computer-using public, including people who spend a lot
of time composing e-mails, presentations, term papers, dissertations,
and other text documents, have become clear over the years and they go
nowhere near emacs, vi, or anything else with their crufty and archaic
interaction styles. Either the whole world is wrong, stupid, and
inefficient, or you are. Which seems to be the more likely?

[insult deleted]

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

Then why did you bring up localization in the first place?

I believed you did.

No, you did.

No. Nothing I have said is null and void.

Except, I suppose, the bits that you eventually treat with an
"irrelevancies snipped" response.

No, those are things that *you* have said.

They only seem deceptive to you because you are unwilling to accept
any deviation from your own ingrained view of the world.

Sophistry. The same argument could be used to justify having a File
menu with a Save item that doesn't actually save the document to disk.

It's exactly the same principle as my example
of a file menu's save item not saving the document: a trained user
would presumably expect this misbehavior, but it would still be
misbehavior.

Seeing as emacs' File->Save item does, indeed, save the current file,
your complaint seems misplaced.

You deliberately misunderstand. It was a hypothetical example of
equally deceptive behavior, rather than a claim about the behavior of
any actual software in the real world. See above.

Something isn't abnormal just because you are not used to it. It is
just something you are not used to.

No, something is abnormal just because the vast majority of people are
"not used to it", or because it's not a matter of merely "who's used
to it" at all. Everyone is used to undesirable things such as death,
taxes, Windows Product Activation, and the DRM on iTunes downloads,
but that doesn't make those things anything but tolerated. A world
without three of those things would be better. Libertarians would say
all four, though they would expect market forces rather than
regulation to get rid of the latter two. (I don't know what
libertarians would propose doing about enforcing antitrust to stop big
monopolies like Microsoft and Apple being able to exist as such, and
thus dictate terms, mind you.)

A different GUI paradigm can certainly be both confusing and annoying
until you get used to it. People who transition from Unix to Windows
have much the same experience.

Bull. It's orders of magnitude worse. Switching between Windoze and
Mac is not very difficult because most things work the same way. The
biggest issue is probably the one-button mouse vs. context menus -- I
guess there's a modifier key that turns a left click into a "right
click" semantics-wise. There's also the command key displaces control
key, control key displaces alt key thing, and the single global menu
bar thing. All would take a bit of getting used to. None would be very
difficult or require weeks of training before which *nothing* could be
accomplished. The transition to text-mode unix would be vastly worse.
Think not stick shift instead of automatic transmission, so much as
having to drive the damn thing yourself instead of having a chauffer
-- and never having learned to drive. In the relatively near future
(15 years? Maybe only 8-10) it would be manual driving vs. having the
car drive itself to the GPS coordinates or map location you selected.
If a generation later the autopilots all conked out one day it would
be weeks before anyone could get anywhere, except for old fuddy-
duddies that had at one time learned to drive manually, and they'd all
be rusty at it.

This isn't even totally unlikely -- a big enough EMP could do it, or a
bad geomagnetic storm coupled with the planet's magnetic field
weakening towards its next reversal 3000 years or so from now.
Fortunately, it's far less likely that we'll somehow lose the use of
modern UIs while retaining access to old crummy things like vi and
emacs. Disaster scenarios that wipe out the former wipe out all of our
computing infrastructure rendering the matter moot. So while there
would be some public-policy reasons to preserve the manual driving
skill (and cars capable of being driven manually!) in an age of fully
automatic cars, I don't see any such reason to preserve emacs or vi.
Of course, "that some people would howl in pain" is still sufficient
to make destroying all copies unjustifiable. But your claims that it's
superior and anyone using anything "normal" is "inefficient" and, by
implication, a moron ... those are even less justifiable. So for
Chrissake, please give it a rest already!

This behaviour is exhibited by both notepad and word, and every other
Windows software I have used. It is altogether very difficult to find
mode-less software.

Bull***. Backspace and the horizontal arrows and other keys that have
a fixed purpose don't change behavior from one text area to another.

What is sensible and not sensible is entirely learned.

What is sensible and not sensible is partly determined by physical
constraints, and partly by group consensus. The group consensus in the
English-speaking world is that "file -> save" means save changes to
disk, among other things, and various analogous things, such as all of
the things I've mentioned previously.

Your personal, idiosyncratic idea of what's sensible is irrelevant
and, to the extent that it does not jibe with the rest of the English-
speaking world, is broken.

The only reason
you may think "enter" is a reasonable key to use to cancel a dialog is
that you have become accustomed to the idea.

Bull***. I said "escape", and the very name of the key means that
having it NOT escape from a dialog canceling any unapplied changes is
a clear standards violation. With the standard in question going back
to the first 101-key type keyboard with an esc key, so you can't
"grandfather in" your precious emacs here the way you can with its CUA
violations as predating the standard.

You seem to be confused again. I thought we were discussing stuff
typed at the "Enter search query here:" prompt, not stuff typed into
the document?

You are /still/ not getting how incremental search works? There is no
"Enter search query here:" prompt in emacs.

You're joking.

Then where the *** are you supposed to enter the search query?

But I *do* get how "incremental search" (your usage) works; I've used
it in Firefox, and I distinctly remember there being a prompt at which
to enter a search query, but it finds hits as you type.

Which is it? Either you're editing in the document proper or you're
editing the query at the search prompt.

No.

Yes. You're either editing in the document proper, editing at some
prompt ("mini-buffer"?), or not typing in text at all. There's really
no fourth possibility here, aside from editing-blind-because-the-
software-doesn't-have-a-UI-or-even-echo-any-input, which, mind you,
does seem to describe some of the even more primitive tools that
preceded emacs and vi.

I know that this is probably mathematically impossible, but
nevertheless, the cursor is in the document and you are simultaneously
editing the search text.

That's not mathematically impossible, but it sure is broken UI. Now
you seem to be claiming that the search prompt is a) invisible and b)
doesn't have focus, yet c) intercepting keystrokes typed into the
component that does have focus, apparently the document textarea. This
is a recipe for disaster if it's true: there's a state the editor can
get into where it just eats everything one types instead of inserting
it at the insertion point. I seem to recall the emacs crowd lambasting
vi for exhibiting such behavior; apparently this was yet another case
of the pot calling the kettle black.

Even to those who know what the hell is going on, it will encruftulate
all attempts at search by forcing them to a) type blind, b) edit
blind, and c) probably be unable to make mid-query edits using the
arrow keys. The only bright spot is that if there exists a hit for
what's currently entered, it will show it on the screen somewhere; if
you've typed "mona" though and there's "mon"s but no "mona"s, you
won't be able to see the "a" (or any of it, if it doesn't show and
mark one of the "mon"s any more once the non-matching "a" is typed).

And guess what, hell hasn't broken loose yet. Who'd of thunk it?

Sure it has. And every time a novice tries to use emacs, they have
firsthand experience of it. Hell, that is.

Each such software will have its own idiosyncratic and awkward
MDI-switching, or none at all (single document only).

Your insistence that anything you do not know must (as a law of
nature?) be awkward is amusing.

Anything that has to be done differently in each of the 20-30 apps
that one uses on a regular basis is awkward pretty much by definition.

Listen, Bent. Gone are the days when people spent nearly all of their
time using only one application, or even only three or four or five.
People routinely use dozens with dozens more they use occasionally.
Having to painstakingly learn a whole new UI and complex stateful
behaviors separately for each application you learn is something that
may have worked back then but clearly does not scale. Your computer
use pattern is unusual, and even archaic: you apparently do very
little BUT edit text. (AFAICT, more specifically, you do very little
BUT compose long off-topic Usenet posts full of tripe to post to
comp.lang.java.programmer. :P) An editor that fits your needs could
clearly be different from one that fits the needs of most of the
general population, and could clearly require extensive training, with
the cost that it then would CERTAINLY not fit the needs of most of the
general population.

One of those needs is that their 30-50 occasional-use-or-more-often
applications behave as consistently with one another as possible,
because the mental burden of keeping 30-50 completely different
command sets in mind and switching among them appropriately when
switching tasks would either crush them entirely, or at least slow
them down enormously. And that's just considering the consequences of
skin-deep differences such as key bindings. Not only does having to
train extensively on every app separately not scale in the modern age,
but having to keep a separate command set in memory for every app and
always use the right one with each app also does not scale.

A second key difference is that not only do people now use many more
apps routinely than they did in the 80s -- at least an order of
magnitude more -- but they also multitask. They don't serially task;
they have things going on in parallel and switch among them. They may
spend as little as five or ten minutes in a text editor before
switching to something else, before later switching back. In some
applications they may spend as little as five or ten *seconds* just
switching to it, setting it a task, and switching away again. They
quickly check email but nothing urgent appears, or they switch to that
download that just completed and right-click virus-scan it, then go
back to what they were doing, or something of the sort.

Having to keep several separate command sets straight may have scaled
up to four or five apps you used for tens of minutes at a stretch
before switching, but it does not scale to 20-30 apps you spend
sometimes only minutes or even seconds at before switching.

Perhaps emacs would be technically superior in a vacuum, like Betamax
was. (But I doubt it.) However, emacs does not actually exist in a
vacuum, but in an environment in which computer users also have dozens
of other applications to use and tasks to perform besides a text
editor and text editing, and in which multitasking and short sessions
are now also the norm. Outside of that vacuum, in the real world,
where the rubber meets the road, emacs (and vi) come up looking a lot
less efficient, to use your favorite word, than under some theoretical
ideal set of circumstances that doesn't ever actually occur.

Launch separate
instances for each document in separate xterms and you can use the
window manager's switch windows key to switch between documents the
way you're supposed to be able to.

This solution is too awkward for me to bother with.

It's awkward because you insist on using archaic terminal-mode
software. Launching Notepads as separate top level windows is easy: it
happens automatically. And then switching among them is a breeze.
Launching those old editors in separate xterms is much more of a pain,
but then switching among them is a breeze. Opening multiple documents
in one instance of one of those old editors is less of a pain (but not
a breeze) but then switching among them is a pain.

This, of course, I do quite often.

Then why are we still arguing?

Yes, you do. It's unusable without some serious expertise of some
sort.

Ah, yes, the Zen of pointing your mouse at File->Save. Brain surgery
that is, brain surgery.

Non-sequitur. I refer to the Zen of M-x C-space local-f<space>
foobar<space><space>ESC, or whatever the *** it was.

I call bull*** here. The little blinking line is there precisely to
tell the user where whatever they type will go.

It doesn't blink and its not a line. Although I'm sure it's
configurable.

Hair-splitting. Although what you describe sounds broken. Now why am I
not surprised that emacs would also hide the character under the
cursor from you? Which apparently it does. If the cursor's not a line
it's a box, and if it also doesn't blink it completely hides the
character it's on from view. Oops. Well, unless it's always-off
instead of always-on in the "not blinking" department. In which case
you can't see where the *** the insertion point is, which is arguably
even worse.

It's strange, but when I try out new software I do not tend to start
by issuing it an ultimatum: you must not under any circumstance do
anything in any other way than what I am used to.

Do you have a point to make here or are you just meandering randomly?
If the former, get to the point already. If the latter, shut up
already. :P

based *** really seems to take the cake.

And eat it too! That's the beauty of it!

Bull***.

Note that I'm not talking about a Windoze convention here. I'm talking
about a flashy-thing-is-where-the-text-goes convention that is AT
LEAST forty years old and considered inviolable.

Since there isn't actually a flashy thing here anyway, your point is
moot.

More hair-splitting. The details of exactly what the cursor looks like
visually are irrelevant here. (Though see above -- from what you've
said, the way they chose to make it look will create yet more
usability problems. Severe ones, as usual.)

Yet here you are claiming that this software you love so much
sometimes shows the insertion point in a document but typing goes to a
prompt. Or, I think to use the emacs terminology you seem to favor,
the insertion point is in one buffer, and the typing goes to another
(which happens to be a mini-buffer). :P This behavior sounds broken
even when described using the emacs terminology.

And yet, immensely useful. Usefulness trumps understandable-by-Twisted
any day of the week :-)

There is nothing at all useful about a mini-buffer capturing input the
user explicitly directed at another buffer.

See above. I'm not. The earliest text-terminal applications in history
established, and adhered to, the standard that there is a blinking
thing on the screen and it marks the point at which what you type will
be inserted, hence "insertion point", also known as "the cursor".

Again with the blinking thing.

Well, some use a steady underline or similarly, but most animate it so
that it draws the eye. Many good UIs have the cursor the ONLY thing
that normally animates, so it's a) easy to find it on the screen when
you have lost track of it for whatever reason and b) nothing else is
distracting you when you're trying to find it. (Of course, some good
UIs differ for particular reasons -- for example, a movie player app
that didn't animate anything but a cursor wouldn't be very useful,
now, would it? Ditto an action game, or a stock ticker, or...)

[insult deleted]

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

And if you don't? For example you're adding something near each
occurrence, and it's not the SAME something each time? Then you need
to quit the search, make your edits, and then do a separate search to
find the next occurrence. You can't just park the search while you
edit and then simply hit "next match".

Actually, that is generally what you do. C-s C-s will repeat the last
search.

That's at least one extra keystroke over just hitting F3 (which is all
you need to do even in the lowly, miserable Notepad!) as well as
unobvious. And that's assuming that it immediately jumps to the next
match when you type those two chords, rather than landing on the same
match you'd just visited and waiting for you to hit next-match AS
WELL, in which case it's *two* extra keystrokes. *Five* if you count
two-key chords as two keystrokes rather than one keystroke, assuming
that next-match is a two-key chord and comparing to Notepad's F3,
which requires no modifier and therefore still counts as only one. If
you don't need to hit next-match it's still *three* by that metric.

Most likely, if the edit was after the hit or changed the hit, your C-
s C-s goes to the next one immediately, and if the edit was slightly
ahead of the hit and didn't change it, your C-s C-s goes to that hit
again as the first one after the current cursor position, and next-
match needs to be hit to jump to the next one, so it will average
maybe *four* extra keystrokes with the chord-penalizing metric (one-
and-one-half without chord-penalizing).

What the *** ARE you talking about? Those are the three ways to
navigate (in a GUI text editor, anyway). Click where you're going,
arrow and page up your way there, or get there via search.

Of course, there is also goto-line, bookmarks and all manner of other
ways in which to move about the document.

All of those are rather situational. Goto-line is mainly useful if
your broken editor doesn't have working scrollbars, or if your broken
IDE or lack of an IDE means you can't just click on the compiler's
warning and error messages to jump directly to the associated source
line. (Eclipse goes this one better: you can walk through a stack
traceback with a code window jumping to each line in the chain of
calls, all with just one arrow press or mouse click per transition.
Useful for seeing the exact path the code took that led to that
nuisance of an NPE. Add in the ability to inspect the local variable
values in each stack frame just by hovering over their identifiers in
said code window and it's very easy to post-mortem your NPEs (and
other RuntimeException crashes) to find out where the null snuck in
from (or whatever). This can probably be rigged somehow in emacs, but
it probably takes a PhD to set it up, rocket science to install it as
a prepackaged add-on of some sort, and merely a month of additional
training to just plain use it. It can probably also be done in vi, but
only three people in the world could pull it off, and one of them has
Lou Gehrig's disease and is a plane ride away, one of them is too busy
solving 11-dimensional math problems in the name of particle physics,
and one of them is actually participating in this discussion, but I
can't be bothered wasting a year or so on it when there are other
demands on his time and he likes Eclipse just fine anyway. ;))

[insult deleted]

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

Regardless, "English (U.K.)" tells you
a hell of a lot more than "Fundamental", whatever THAT means.

I don't see how. I certainly don't know what it means - see above.

Perhaps you should read the documentation?

Having a mother is an embarrasment to you? If I had known, I wouldn't
have brought it up.

Non-sequitur.

Bull. You won't just magically produce the words just by going to type
them and out they come;

Well, to some of us, touch typing may seem like a type of magic but I
can assure you it is not.

More non-sequiturs. I was talking about typing at a search prompt to
go very quickly to a specific place that happens not to be currently
in view. It requires either precognition, channeling, spirit-
possession, something else equally paranormal, or else you remembering
a sufficiently-long exact sequence of characters that occurs at the
destination.

In most circumstances where most people perform long-range navigation
inside of a text document, using search instead of a scrollbar to find
their destination is like driving instead of walking -- when the
destination is at the other end of a short footpath but sticking to
drivable roads takes you around a fairly long loop, and of course
requires getting into the car, starting the engine, carefully backing
out of the driveway, and all that jazz before you even get going at
any kind of speed. Probably by the time you're cruising at ten times
walking speed around that loop the walker's already all the way to the
destination waiting impatiently for you. :P

you must know what words to type first,
dip***. Unless, of course, you've ALREADY got them memorized, because
you memorized the whole damn document, in which case I rest my *other*
case. :P

Again, you are projecting the shortcomings of search dialogs onto
incremental search.

I'm doing nothing of the sort. Incremental search just means that you
know you've missed as soon as you hit the first character that makes
it a miss, and that you can still use it as a broader search without
redoing the search, albeit a broader search that will take many, many
hits of "next match" to get you where you're going.

See above. Walking's faster to just get around your own block. A
couple of mouse clicks is faster than several keystrokes (C-s query)
followed by several more keystrokes (next-match, next-match, next-
match...)

First:
* If there are no matches, you go nowhere.

With incremental search you tend to go /somewhere/ regardless.

See below.

* If there are too many matches, you go slowly.

In this case, you type more characters.

See above.

Incremental search doesn't change this much; if you try a long query
and get it wrong it will behave as if it were a short query ending
where the first wrong character is.

The beauty of incremental search is that you get to try out both the
short search terms and the long ones since you see the matches come up
as you type. If the short term gets you there, excellent, you're
done. If not, you keep typing until you're happy. If you have typed a
bit (typically 6-10 chars) and you still don't have it, often you'll
start "next match"-ing to get to it.

And in those cases, you've now exceeded the amount of time taken by a
Windows user with a mouse and proficiency with the scrollbar UI.

And if you don't have a precise memory for the exact wording
throughout the document, those cases will be numerous enough to make
search navigation slower *on average*, to boot.

If your knowledge of the document is this incomplete, you might want
to use grep or somesuch instead. Or just try with king first and then
monarch, of course.

"Grep or somesuch", as in launching an external command, would be even
slower and more awkward than repeatedly retyping the query with
various guesses.

Well, maybe not. If, as you indicated above, you'd have to edit the
query *blind*...

Ultimately, you tend to have two possibilities: lots of false
positives, or lots of typing and memorization of the destination
required; one or the other. If you know roughly where you are going a
quick scrollbar scroll in a GUI app will get you there much faster
than either slogging through false positives or typing a long enough
query to avoid same.

In this case, goto-line is even faster.

No it isn't. If I want to go to a spot roughly 1/3 of the way down the
document, I could do one of five things:
* Scroll to the 1/3 mark and wiggle the view around a bit to spot the
target. Time taken: about 1 second.
* Remember the exact wording there and type it into a search. Time
taken: 1-2 seconds.
* Not remember the exact wording there and nonetheless use search.
Time taken: 5-15 seconds.
* Read a number at the bottom of the screen, mentally divide it by
three, and type it into something. Time taken: 10-30 seconds.
* Hold down pgup or pgdn until almost there, then tap the key until
there. Time taken: depends on how far it is.

Pgup/dn is fastest if it's right nearby. Scrolling is second-fastest.
Search is about as fast if you know enough about the text where you're
going. Mentally dividing a number by three is actually the slowest
method there except in cases where the document is really long and the
current position is really far from the 1/3 point, where pgup/pgdn
becomes the slowest method.

That's in a case where the arithmetic is simple. I can visually
position the scrollbar to a point that "seems right" or where I
remember seeing it before that's actually not well approximated until
you're using fractions with a fairly large denominator and oddball
numerator, like 5/17. Then coming up with a close-enough line number
would take whole minutes and probably be faster done by actually
launching and using a calculator app than by doing it mentally.

Ouch.

Go to line is only really of use if you actually know the line number,
or one in the neighborhood. I can think of only two scenarios where
this is at all likely:

1. Compiler error messages. Then go to line is a poor cousin to jump-
to-error or similar IDE-type functionality. At least you only have to
memorize a number from one place and type it into another place
though; no more arithmetic required.
2. You have been editing the file with an editor that displays line
numbers to the left of every line, and developed an association
between line numbers and parts of the document. This is almost on a
par with scrollbar UI, except that a) you need to type in short
sequences instead of just click-click, for a small increase in the
number of input events needed, and b) line numbers at the left takes
up more screen real estate than a typical scrollbar at the right, at
least if they are into the triple digits or more.

To top it off, the most usual circumstance for editing with line
numbers displayed is editing code, and then once again IDE-type
navigation capabilities would serve you far better.

You're in an orchard. Alone. You have a brand-new basket in good
condition. You pick three apples and put them in the empty basket,
then immediately turn to pick seven more and put those in the same
basket. You don't slice, dice, or otherwise adulterate any of them
either; just pluck them and add them to the basket. Oh, and the basket
is carefully kept right-way-up the whole time.

But in the real world, you cannot actually /know/ that you are
alone.

Ludicrous. Have you ever seen an orchard that provided much
opportunity for concealment? The trees tend to be sparsely spaced and
have thin trunks to boot.

Nor can you ever have complete certainty as to the condition of
the basket.

How about "it's nearly new, and it's worked fine for a few days and
looks sturdy". You know the basket is in the deepest part of the
bathtub curve then, right after the infant mortality period ended and
long before it starts to get aged and damaged by time and wear. Nor
are we putting ludicrous weights in them -- they're apples, not
plutonium bomb cores*. :P

* a) densest thing I can think of that might fit in such a basket; b)
as an extra added bonus feature will noise-pollute ECHELON and its ilk
so I'm also doing my civil duty to help preserve freedom of speech and
privacy rights online by participating in the constant low-grade DDoS
of some of the Bush administration's questionable domestic and
international spying apparatus.

[insults deleted]

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

a) In prose documents, it is much more common to know roughly where
things are than to know precisely what those things are, character-for-
character. At least for a normal human being.

Do you manage to scare away many people with your attempts to force
them into arguing that they are not human beings?

Non-sequitur. I'm just qualifying it because I know there may well be
a few exceptions. You have previously implied yourself to be one of
these -- an *ab*normal human being, but still presumably a human
being.

b) If you don't get it exactly right with a scrollbar, you're in the
neighborhood and a bit of skimming should find you your target in
short order.

You are already dangerously close to busting my awkwardness-meter.

Oh, come off it. It's like using a hand grenade instead of a bullet**:
a near miss is as good as a hit with the one, while only an actual hit
is as good as a hit with the other.

** Eat this too, ECHELON!

This also applies to click navigation within the visible pane. A miss
is as good as a mile with search, but a sloppy click that's a
character or two off from the actual target just means you're almost
there; a couple of arrow key presses later and you are there. It's
more robust precisely because it's fuzzy, and degrades linearly with
imprecision; search breaks rather abruptly with imprecision, either
going nowhere (regular search) or quite slowly (incremental search,
typing until there's no matches, backspacing the last character from
the query to get back to the most refined one that had matches, and
then using next-match repeatedly). With incremental search, each
greater degree of imprecision causes another sharp drop in speed, and
it's not linear either but by a factor -- in a typical corpus of
natural-language text one will find that any given character sequence
occurs a fraction as often as its one-character-shorter prefix, so
shorter queries will tend to have exponentially more hits than longer
queries, meaning that the speed falls off exponentially instead of
linearly with imprecision with incremental search. And as noted, with
regular search it drops directly to zero at some point.

Scrolling is robust. Clicking is robust. Search is brittle, especially
normal search but even incremental search. It's finicky. It's fiddly.
It's ... *awkward*.

Yeah, I know. More of the word you hate ("awkward") and more
mathematics, which you also hate, probably because you never were any
good at it. Well, c'est la vie. :P

The facts remain. The mouse based navigation methods are far more
tolerant of imprecision; and for the vast majority of computer users,
tolerance of imprecision translates directly into ease of use.

Not ease of training, mind you, but day-to-day ease of use.

Mind you, one thing that's gotten glossed over in all of this is that
mouse skills do develop as you use the thing routinely. Eventually you
can be very fast and precise with a mouse, and until then you can
still get around adequately because of that same tolerance of
imprecision, so
a) Your complaints about mice being fiddly and awkward are a training
issue;
b) Your complaints about mice being fiddly and awkward neglect to
consider the mode of use of "click sloppily and fine tune by
keyboard"; and
c) The tolerance of imprecision here improves ease of training AND
ease of use, the former because you can train on the fly while
actually getting work done instead of dedicating some otherwise-
unproductive time to said training. That makes the training
essentially happen "for free". Literally, if you're on the job, since
time is money in such a context, although these days most people
develop mousing skills well before entering the workforce.

Or, the more common case, you type enough letters for the search to be
sufficiently unique, and you get there within a couple of matches.

No, that is not the more common case, unless you're very good at
remembering exact wording and phrasing from all over your document.

These people should learn emacs.

That's the core of it isn't it? Your arrogant belief that the tools
you prefer (and are, perhaps, unusually equipped to use well) should
be used by everyone else as well. Despite the clear signal the market
is sending that says "You're wrong, Bent!"

What are you blithering about here? You won't be able to just hit
"next match" and keep going. You'll have to hit whatever it is you do
to start a search (was it C-s in emacs?) and either retype the query
or pull it from some history if it has one...

And you wonder why I assume that you have little experience with
emacs?

???

You detailed the exact keys above and they were more or less as I
expected: C-s to start a new search, another C-s to suck the last
query out of the history, and so forth.

Your "highly efficient" GUI tools may require you to jump hoops like
that - emacs does not.

My highly efficient GUI tools let me edit the document without exiting
an in-progress search, so no, they do not require me to jump hoops
like that - but emacs does.

C-s C-s will repeat the previous search and after pressing the second
of those two, you will already be at the next match.

Unless you were to the left of the hit you edited near instead of to
the right, which should happen about 50% of the time on average. Then
the first hit to the right of the cursor will be the one you already
dealt with, and you will need to hit next match to proceed to the next
un-dealt-with one.

For example if you were finding all occurrences of "foobar" in some
list and putting an X to the left of each instance (for whatever
reason; stuff analogous to this can and does come up from time to
time) you go C-s foobar and get to the first occurrence; I hit ctrl-F
foobar enter and get to the first occurrence.

You then cancel the search, hit left a few times, type the X and maybe
also some bksp/del action, C-s C-s to do a fresh search for "foobar",
and it matches the first "foobar" again as it's the next match after
the cursor position. Then hit next match to go to the second. Of
course you could also hit down-arrow before C-s C-s or something, but
the net result is the same number of keystrokes.

I, meanwhile, cancel nothing. I click right by the spot where the X is
to go, type the X and maybe also some bksp/del action, and F3 to
advance to the second "foobar" occurrence. Arrow left, X and maybe
bksp/del, F3. Wash, rinse, repeat. Each time I input only one
keystroke related to the search UI, F3, while you enter three, either
down C-s C-s or C-s C-s next-match. Both of us enter the same number
of keystrokes to make the actual edit at each match (except that I
enter one mouse click instead of several arrow keys, but need to reach
for the mouse, for the first one, to get focus to the document from
the search dialog).

What of the dialog possibly getting in the way? Well, instead of
clicking by the first X spot, I can hit esc and then arrow there.
Dialog goes away, and F3 still works because once you've done one
search in a session, F3 always looks for further matches in the last
one performed. These never-ending searches are far more convenient
than your never-deselected selections, I'd warrant!

(Some apps have F3 find the next match from the cursor position rather
than from the previous match. In these cases I need F3 F3 to jump to
the next match after adding the X. I still save keystrokes, and also
avoid chording other than for the one C-f at the start. To top it off,
this variation is even handier sometimes as I may want to occasionally
jump to an occurrence of "foo" over the next several hours and a
single search for "foo" early in the session essentially binds "jump
to next 'foo' after current cursor position" to the key F3.)

And all of that is leaving aside my earlier criticisms of auto-
submitted queries that you don't get an opportunity to modify first,
which first arose in the context of pasting in a query and which seem
to be applicable again here. Albeit that in the specific use-case
currently under discussion there's no need to modify the query.

So if you can't get a victory, you're going to be happy with
not-entirely-a-resounding-defeat?

I never said anything of the sort.

Most people respond to cognitive dissonance by merging the two
conflicting ideas in some manner. It takes a truly resilient mind to
just automatically cast off the newest of them and then go merrily on
- stagnation be damned!

Non-sequitur.

[implied insult deleted]

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

Eh? That sounds especially awkward -- actually launching an external
process to search the file you're editing and pipe the results back
into the editor.

It would have been, but modern computer systems actually hide most of
that complexity from you and - it just happens! You should try one
some time.

*** off. I saw the digressing branch of this thread that discusses
this "feature" in greater detail. It turns out you have to type a
whole shitload of obscure and fiddly command line switches, plus the
path and filename of the very document you're editing, which strikes
me as nearly as appalling a lack of automation as using goto line
instead of jump to error or a scrollbar or whatever.

Not to mention fiddly, awkward, slow, typing-intensive, and so on and
so forth.

And then you get the cruddy primitive equivalent of a new window with
the results, which you have to close after reading, and then you need
to go find them in the first window to do anything at any of the
matches. Sounds like memorization time again...

But then, there's no escaping that navigating around a document that
you know absolutely nothing about (even though you were, apparently,
editing it at the time) /is/ going to be something of a difficult
undertaking.

Strawman. We're not discussing "a document that you know absolutely
nothing about"; we're discussing "a document that you know
approximately everything about", combined with the fact that
imprecision degrades search-based navigation much more badly than it
does scrollbar-based navigation. Your laughable suggession to rely on
search and even on "goto line" would only be all that workable for "a
document that you know everything about, perfectly and exactly", which
is a damned rare document indeed. And EVEN THEN there is more time
spent making input gestures doing those things than there is using the
scrollbar!

You're damned, Bent. Trapped inescapably. Doomed. Painted into a
corner. Euchred.

[snip irrelevancies]

Bull. That it doesn't seem complex to *you* doesn't mean that it
*isn't* would be a better way of putting it.

It would be a nonsensical way of putting because obviously it /does/
seem complex to you.

But the key difference is: it actually IS complex.

To you.

No, no, a thousand times NO!

Let me spell it out for you.

F3 is simple. It seems simple to me. It seems simple to you.
C-x M-foo Baz-<space> quux-<esc> etc. is complex. It seems complex to
me. It seems simple to you.

F3 is simple because nobody finds it complex, except perhaps complete
computer n00bs that are using a keyboard with an F3 key for the very
first time.
C-x M-foo and so forth is complex because everyone finds it complex
except for a handful of specially-trained individuals.

In another sense, it's complex simply because it is larger and takes
longer to describe. The technical term for this sort of "complex" is
"Kolmogorov complexity".

You seem to be denying the very idea of something having an objective
"simple" or "complex" state in addition to the various subjective
perceptions by various people. If that is in fact what you are doing,
then you are too irrational to continue to have a discussion with.

Ah, but in that case, /everything/ to do with computers is
complex.

Bull***. F3 is shorter, sweeter, and simpler than that thing you
wrote. To a lesser extent to C-s C-s, as it's one fewer keystroke and
involves no chords. It will take less effort to think up when the time
comes to use it, and less effort to enter. It is also atomic instead
of a composition of elements. In every single respect that matters it
is simpler than C-s C-s and VASTLY simpler than that other thing.

Eh -- how do you get a literal space into a command then? Escape it
somehow? What a pain!

It would be, except commands don't use space. Wow! The brains of those
people! They should become computer programmers or something!

Bull***. Space is what separates the tokens on the command line,
moron. How do you get the space between the local-s<space> and the
foobar-b<space> or whatever the *** they were then?

You CANNOT bind space to autocompletion on a command prompt without
losing the ability to separate the input tokens in a natural way. This
is why autocompletion is normally bound to tab (in single-line input
contexts anyway).

It supports tab for the same function if you prefer that.

The problem isn't that; the problem is that it does NOT support simply
hitting the space bar to insert the space between the first token and
the second on your command line, so when you put "command args" you
need to do something funky after typing the D.

Indeed, messing around with crummy old-school apps has
me thinking constantly about how awful they are, presumably because I
have experienced the better alternative and so I notice it when faced
with something awkward!

It is quite apparent that you never took the effort to actually[snip]

It's not true.

I'm sure it is, nonetheless, quite apparent to you; the mental
syllogism no doubt going something like this: "Emacs isn't awkward to
use; this guy thinks it is; therefore this guy never took the effort
or surely he would no longer hold that opinion!"

You fail to consider that maybe, horror of horrors, somewhere out
there in the world, there exists someone who did take the effort and
did indeed hold, afterward, the opinion that emacs is awkward and a
pain in the neck to try to use.

So you refuse to accept it. You'll call me a liar sooner than accept
that such a thing might have ever happened. I don't know what level of
evidence would convince you, but the answer probably lies somewhere
between "signed affidavits and video documentation" or even "a peer-
reviewed article in /Nature/ titled /First observation of an
individual who spent some time learning to use emacs and afterward
held the opinion that it was awkward/ and "no evidence at all will
EVER be convincing".

This attitude of yours is clearly irrational, so we're done here.

Except, perhaps, that you shouldn't slam it unless you've tried it :-)

There it is again. You simply cannot accept the very concept of
someone slamming it who HAS tried it, so in your mind the very fact
that someone's slamming it "proves" that they haven't. :P

Again, you keep assuming that searching has to be something so awkward
as a "command"...

Well, it *is*. You yourself described it: you hit ctrl+S (or some
such), type a query, etc.

Except...[insult deleted]

Well, is C-s a "command" or is it not? For that matter, isn't this the
worst case yet of your hair splitting? At least it can't go on much
longer. Splitting these hairs much finer will run up against the
fundamental limitations and discrete nature of quantum physics. :P

Well, of course there's no "modal input dialog" with no window system.
Instead there's that "mini-buffer" as you called it.

Indeed.

Which is just a cruftier and more primitive version of the same
concept. More hair-splitting! Perhaps you should get a job as a
cosmetician or something. :P

I don't see how search can be "comparable to cursor movement"; you
have to do something special to perform a search and type a query, and
do something special to end the search.

Nothing more special that C-s and then typing the query. An emacs user
doesn't consider this "special".

It's still not mere cursor movement; it involves entering some actual
text for one thing. That's working at a higher level than just
navigation; it involves working with the content, and it involves
typing stuff someplace.

Next match and (with this
incremental search) refining the query are a little like hitting page
down or whatever, but you have to a) put the editor into a different
state and b) type stuff first.

As if hitting C-s is very taxing.

It's more taxing than doing absolutely nothing, which is all you need
to do to navigate normally. (At least, unless you're using vi. :P)

The web is largely picture-driven and incremental search is generally
not very good at locating graphics, and especially not at finding
"pictures that I don't know are there but might want to click or look
at when I see them".

This is another strawman argument. You seem to be becoming rather fond
of these, for some reason. In any event, my experiences with the not-
very-revolutionariness of incremental search in Firefox involve long
largely-text-oriented documents such as long pages full of blog
postings.

We weren't talking about GUI conventions though. We were talking about
the selection behavior in emacs, in a manner independent of a) what
version (so it could be the text-mode original) or b) what key
bindings.

And where in Webster's can I find a description of the mandated
behaviour of text highlighting in modern GUI software?

Non-sequitur.

Bull***. Highlighting marks something to be operated upon.

No, something to draw the user's attention towards.

No, something to be operated upon needs to be highlighted, so that the
user has visual feedback regarding the scope and consequences of the
operation if and when one is performed. Anything else is senselessly
brittle and error-prone. Not to mention non-standard.

This sort of glosses over the fact that there are no text-mode-only
versions of Word -- even Word for MS-DOS was graphical, although it
didn't come in a window on a desktop with other windows open
simultaneously.

So, now, /not/ working in a text display is a feature?

It certainly is. A graphics display provides for a much richer UI with
much more bandwidth available for communicating state to the user, not
to mention in the specific case of word processing it lets you
actually see the document with all of its formatting, instead of typed-
manuscript-style.

So some open-source-software FTP site has a graphical port of emacs.
Big whoop-de-do. There are graphical ports all over the place; I
believe I mentioned running into one written in Java one time.

Of course, the rest of the world will tend to know that ftp.gnu.org is
/the/ place for /the/ emacs so, well, the hole is getting deeper.

This is laughable. The rest of the world doesn't even know that emacs
exists, by and large. And there is no /the/ emacs. You're a hypocrite,
Bent. One of your earlier attacks was "Which emacs are you talking
about? There are many!" and now you're saying "There is one true emacs
and all the others are false idols", while cherry-picking which one is
the "one true emacs" to suit whatever argument you're presently trying
to make -- exactly the same thing you earlier accused me of doing. :P

No, if you search for other words. Words like "and" or "the" will have
dozens of hits per page. Well, at least ONE dozen in your cramped
80x24 box of characters, more with a decent monitor and either a
graphical port or an actually decent editor.

Anyone that cares will also, by this time, realise that your attempt
at a swipe at emacs is hopelessly marooned in a mental image of emacs
that is stuck back in 1985.

This pointless non-sequitur is not only BS, but also completely
unconnected with the issue of search and word frequency.

The paragraph of mine quoted above is very simple to understand. You
obviously cannot, because if you could you would agree with me that
for prose documents scrollbar usually beats search, yet you do not.

It may beat dialog-box based search, of course.

It beats the weird *** in emacs, too. Postulating the best case of a)
user proficiency with the crufty emacs interface and b) perfect
recollection of the exact character sequences in the document, it will
STILL take more time to type in the fucking query than it takes to get
there by scrollbar, unless the query used is short enough that instead
it takes more time to reach the target via "next match" tapping than
it takes to get there by scrollbar. The only exceptions will be highly
situational or outright contrived, e.g. a document deliberately salted
with a unique three-character sequence at a specific point to use to
reach it quickly via search (contrived) or happening to have a short-
but-unique string in one spot "naturally" (highly situational). Those
will merely not actually be slower; they won't be faster either
though.

Sorry.

You lose.
.