Re: Great SWT Program

In article <2db369ee-1e46-40ee-b9fa-d5293c6b8416@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<twerpinator@xxxxxxxxx> wrote:
On Nov 15, 12:33 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. "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.

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

[irrelevancies deleted]

The irrelevant part, of course, being the explanation of why your
assumptions turned out wrong.

Your attempts to sweep these things under the rug are only convincing
yourself.

I don't really care about the localization. As far as I am aware, what
we have been discussing is independent of it.

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

I believed you did.

None of the above is in the least bit surprising or unwelcome for a
trained user, so whatever point you are trying to make is null and
void.

No. Nothing I have said is null and void.

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

It doesn't matter if a
trained user would be familiar with certain deceptive behaviors such
that they would no longer be fooled by them; the behaviors remain
deceptive all the same.

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

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.

If you have learned the keybindings, it's a pretty safe bet you've
learned the behaviour associated with them also.

The point is that the behaviors that are normal should all be invoked
by some key binding, and fundamental things like selection should
behave as normal, albeit with different keys hit to do things with it.

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

That is clearly not the case. Additional features = wonderful. Altered
keybindings = annoying. Violating the normal semantics of clipboard,
selection, and the like = dreadful.

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.

Editing keys not behaving
consistently (e.g. doing different things at different times in text
input areas, or doing different things in different text input areas)
= dreadful.

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.

(Non-editing doing different things in different places is
acceptable; enter, up, down, pageup, and pagedown behaving differently
in single-line input fields is acceptable so long as they do something
sensible, e.g. enter submits a command or query or filename or
whatever, and they behave normally in multi-line text areas.)

What is sensible and not sensible is entirely learned. 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.

There is no "next word" when one is already at the end of the text,
e.g. after having typed "ex" into the search prompt so that the only
thing in there is "ex" and there's no "next word".

It completes the hit that your cursor is currently at.

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.

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

No.

Make up your mind! They can't
both have focus simultaneously or all hell would break loose.

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

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

And most apps just use
multiple top-level windows, which submit to window switching.

I find that "most apps" do not.

That's because you are mostly using wacky text-mode apps that wouldn't
know "window switching" if it conked them on the head.

You can tell my window managers that. They would shake their virtual
heads in disbelief.

But you're using terminal type software inside an xterm and *** like
that.

That happens.

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.

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.

Or just use native GUI apps and the
window manager's switch windows command like you're supposed to; it is
the 21st century now after all.

This, of course, I do quite often.

You're not going to truly master Word either so you better stop using
it.

You don't NEED to to be reasonably productive with it, unlike some
other software that I could name.

Of course, you don't with emacs either.

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.

Your cursor remains in the document, and serves to mark your current
hit. The text you type appears in the mini-buffer at the bottom of the
app so you can tell what it is you're searching for.

So it DOES lie sometimes about where text will be inserted!

Only if your idea about where text has to go is sufficiently damaged.

What the *** is that supposed to mean?

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.

That is even more
fundamental than the behavior of the selection. It is non-negotiable.

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.

[rant snipped]
But your text-
based *** really seems to take the cake.

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

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.

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 :-)

You really need to stop pretending that emacs uses a native Windows
set of GUI paradigms.

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.

[insults and irrelevancies deleted]

Why is it always "irrelevant" when an argument shows up that you are
incapable of even /pretending/ to refute?

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.

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. In a /proper/ text editor
anyway.

You mean in the same way that Word displays "English (U.K.)" in the
status bar? (*) What is that? The language that the current document
is written in? The keyboard layout that is being used? The
localization language for the GUI components? The language used for
the dictionary? There is no way to tell - all you can really say about
it is that something, somehwere, is probably in British English.

It's probably all of the above.

It demonstrably is not.

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.

[insults deleted]

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

Except, of course, that no such memorization is required.

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.

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.

It's difficult to answer this question since it is based on [insult deleted]

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

Another irrefutable argument, eh? :-)

I was doing nothing of the kind. I was using mathematics to model
simple arithmetic. Here is what happens when you navigate with search.

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

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

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

In this case, you type more characters.

Second:
* If your query is shorter, there will tend to be many matches; if
longer, fewer matches.

It follows that long queries will take you to your destination quickly
if you remember a long enough fragment of the text that's there, but
will take you nowhere if you don't, or if you don't get it exactly
right. Short queries require you to remember less about the text at
your destination, but will tend to have you slogging through numerous
false positives along the way.

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.

Of course you won't know what
other character to try there instead. You won't even be sure which
character is wrong; if you might be looking for "king" or "monarch"
and type "king" you'll get king hits but not the "monarch" you're
actually looking for, and it's actually the first character that's
wrong (needs to be "m" instead of "k").

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.

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.

(...)
Even then, an IDE like
Eclipse provides special-purpose search tools for code navigation, and
Eclipse even integrates these into the scrollbars so that you can
combine the two in various ways...

"Goto definition" and suchlike is certainly excellent functionality.

How often do baskets spontaneously have stuff stolen from them by
enterprising pickpockets while people's backs are turned? Often enough
to be of relevance.

Do I really need to be painfully exact with every element of the
hypothesis then?

Yes, you /must/ if you insist on using mathematics to solve
it. Mathematics do not take kindly to sloppiness.

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. Nor can you ever have complete certainty as to the condition of
the basket. Your equations might work out fine in e.g. a computer
game, but in the real world they will run into some serious
inaccuracies.

If, after this, the number in there is anything other than ten, you
suspect that you must be in the Matrix, because otherwise conservation
of matter seems to be violated. :P

On the contrary - in the Matrix, your equations could actually work.

I don't. I use it as a navigation tool, when I already know where what
I'm looking for is.

Ergo, you need to memorize the documents so that you always know where
everything is. I prefer to avoid such a requirement.

This is getting ridiculous. You're going around in circles, idiot.

Someone really needs to start cataloguing the many fallacies that
litter your path. Of course, it would have to be a full-time position
:-)

This was already dealt with.

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?

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.

If you don't get it exactly right with a search, you go
nowhere (regular search) or slog through a large number of hits that
may not even include your target (emacs-style "incremental" search).

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.

Much more precision is needed with non-GUI tools in general, or you
just get error messages, uselessly broad result sets, silence, etc.;
this is unavoidable in some circumstances (e.g. programming) but just
gets in the way of getting work done decently quickly in others (e.g.
text editing). This extra precision requirement increases the amount
of work the user must do to get a given result, particularly the
amount of typing they must do. Because they are doing more they may
feel they are actually getting more done, but they aren't really. Thus
the seductive illusion of getting work done faster with these things
when the reality is the exact opposite.

These people should learn emacs.

Search in emacs is nothing of the sort. In the case you describe, you
would presumably /continue/ the previous search rather than start an
entirely new one.

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, then hit enter, THEN hit
next match.

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

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

That's several extra actions even if there's an easy-to-
access history of prior queries. If it starts with the last query
already populating the field, it's still C-s enter something-or-other
instead of only the latter. A minimum of two extra keystrokes.

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.

And, again, if for whatever reason you think the scrollbar is going to
get you to the target in the most efficient manner, there is no reason
not to use it.

Fine. Then let's end this discussion, now that you've apparently seen
the light.

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

[irrelevant and un-connected "response" to this deleted]

I guess you can't argue with something that unassailable and iron-
clad, eh?

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!

Once you understand why the "irrelevant" response above was indeed
relevant, you have taken the first step.

When this comes up and you don't want to skip a number of false
positives, you might want to use M-x grep instead. This will list all
the lines that hit e.g. "lion" in a separate buffer and will often
give you the context you need to quickly spot the desired line.

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.

And of course grep will not in general be seeing the
most up-to-date version of the document, in particular if you have
unsaved changes at the time. There's also the need to remember and
type in the entire path to the document. Even picking it from a file
chooser, should such a luxury be available in whatever graphical port,
would still be a pain, unless there's some way to specify that an
external command be launched on "the current document". Which I'd
think would end up being the mini-buffer for inputting the command
line into anyway, since that would be the one with the focus at the
time...

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.

If the file is only a couple of screenfuls long, I tend to use
pageup/pagedown to get around.

So do I, if my right hand is at the keyboard at the time; scroll wheel
if at the mouse.

I tend not to waste much time jockeying the mouse while I'm editing a
document, so I will tend to always use the keys.

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.

And as a result
people perceive it as such, except perhaps when they have a huge
amount of specialized knowledge relevant to whatever-it-is, in which
case it may *seem* simple. But it isn't ACTUALLY simple, or it would
not *seem* complex to anybody.

Ah, but in that case, /everything/ to do with computers is
complex. Accepting this for the sake of the argument, then, yes, that
command is just as complex as Word, Excel, etc.

That is what <space> does in the above command - it auto-completes the
command to the extent possible.

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!

There's a reason why this sort of thing is
normally bound to tab, a function key, or something else not normally
part of a well-formed command string.

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

Presumably because I have experienced the better alternative and so I
notice it when faced with something awkward.

Obviously not. The better alternative is what *I* use, and awkward is
what *you* use. 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
/learn/ those tools that you are slamming, so your experience is
hardly something we can draw any sort of conclusion from.

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

Again, you keep assuming that searching has to be something so awkward
as a "command" that needs to be "submitted" in order for things to
start happening.

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

Except the "etc." that you seem to expect (hitting enter or whatever)
doesn't exist, and this keeps throwing you off.

When you use emacs, incremental search becomes as
ingrained into the navigation experience as to be comparable to cursor
movement rather than to modal input dialog awkwardness.

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

Indeed.

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

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.

With firefox I have an "incremental search" to try out here, too, and
I can tell you that it's a moderate improvement over normal search but
not over scrolling when you know roughly where to scroll to. There's
nothing earth-shakingly revolutionary about it and I certainly don't
find myself preferring it to scrolling or page-down or whatever when
browsing the web.

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

No, English-speaking-world convention.

Where do you find the GUI conventions section in the latest Webster's
I wonder?

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?

FORGET THE KEYBINDINGS! If it were only keybindings, I'm sure people
could get used to the different ones. Keybindings are, ultimately,
fairly arbitrary after all, although consistency is certainly nice to
have there. But the aberrant behaviors described are completely
orthogonal to the matter of keybindings, and so you cannot use the
"keybindings are fairly arbitrary anyway" type of defense.

Highlighting is also fairly arbitrary anyway.

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

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

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?

No wonder you feel that less effeciency is a good thing - we're in
backwards-land!

Hey - we could make one that is even better - Word 2010: now also
doesn't work in a graphical windowing system!

Word was graphical from the start. The same cannot be
said of emacs. That graphical versions have been made (generally in
the form of a souped-up terminal emulation wrapping the core of the
editor, and hooking it in various ways to provide application-specific
menus and status information and the like) does not change this fact.

I agree that Word is the youngster in this.

The emacs you can download from ftp.gnu.org today (and for the last
couple of decades) is a native graphical application.

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.

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.

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.

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