Re: Great SWT Program

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.

[irrelevancies deleted]

I note that this includes your previous pet argument that
Windows-style selection is somehow the only true form of selection. I
can only conclude that this line has been discontinued.

??

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?

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

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.
That is clearly not the case. Additional features = wonderful. Altered
keybindings = annoying. Violating the normal semantics of clipboard,
selection, and the like = dreadful. 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. (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.)

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?

Which is it? Either you're editing in the document proper or you're
editing the query at the search prompt. Make up your mind! They can't
both have focus simultaneously or all hell would break loose.

The lies you speak of only exist inside your head. [further continuation of insult deleted]

I am not a mental case. None of the nasty things that you have said or
implied about me are at all true.

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. Each such software will have its own idiosyncratic and awkward
MDI-switching, or none at all (single document only). 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. 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. (Clunky ports of terminal-mode apps
don't count. This includes anything that does its own weird MDI-like
thing with a grid of text characters rather than presenting actual
freaking windows for each document that you can drag around and resize
and the like.)

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.

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. That is even more
fundamental than the behavior of the selection. It is non-negotiable.
I've never ever seen a Windoze app, no matter how buggy or badly
designed, that lied to me about where my typing would go by showing
the blinking line in one location and adding my typing at another, and
I doubt I ever will. It would be such a flagrant violation of common
sense, never mind Windows-specific interface standards, that nobody
sane would ever program such behavior. I've seen all kinds of
brokenness with GUI apps but never anything that broken, and I've even
seen some screwy selection-handling behavior in my time. But your text-
based *** really seems to take the cake.

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.

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.

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

[insults and irrelevancies deleted]

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

It IS factual. You just said it yourself: you have to end the search
to edit stuff, which means if you want to edit near N occurrences of
"foo", you need to do N searches for "foo" instead of just one. My
tools only require me to do one. Beat that!

If you want to do search/replace, you do that.

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

When I write text, I typically don't care about selecting pixels in 2D
space. I care about writing text.

But when you want to quickly jump to somewhere else in the document,
which will be easier? Spot where you want to go and click there, or
count lines and columns and hit arrow keys dozens of times, or read
several words of what's there and then type it all into a search
prompt? I know which will be fastest...

Since neither of those are relevant to the debate, I don't know why
you keep bringing them up.

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.

TO ANYONE. It was clearly not self-explanatory in the way that status
information in WELL-DESIGNED applications is.

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. Regardless, "English (U.K.)" tells you
a hell of a lot more than "Fundamental", whatever THAT means.

[insults deleted]

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

For example, the
second endpoint may not be visible, so you need to scroll down (or up)
to see it to memorize a few words there to use as the second search
query.

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

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.

You appear to insist on using mathematics to model complex human
behaviour.

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.
* If there are too many matches, you go slowly.

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

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. Scrollbar is faster than search. Period. Unless
you don't know the approximate location of your destination.

I find that with a familiar prose document, I much more readily know
the approximate place within the file where something is than remember
the exact wording used there. With an unfamiliar document obviously
scrolling and skimming with short documents or search with long
documents is called for. With code, given that the ordering of
elements tends to be less important except within individual function/
method bodies but there's no need to worry about synonyms or other
ambiguities, search is sometimes better, particularly with a long
source file whose exact layout slips your mind. 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...

[insult deleted]

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?

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.

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

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

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. 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).
The latter is closer in speed to page-upping than scrollbar-using. The
former has a speed of precisely zero. In short, you aren't going to be
getting there nearly as fast.

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.

Or else you use manual linear search to find what you're looking
for. Hardly much better, although sometimes necessary, I agree.

??

That's mainly a last resort for large, unfamiliar documents where the
obvious search query (or queries) doesn't work. Although a quick skim
of a short document is likely to be as fast as breaking out the search
prompt and typing a bunch of stuff, then submitting it and wading
through the hits.

But they do: you just said earlier that if you want to edit near each
of N occurrences of "foo" you need to do N searches for "foo" instead
of just one. Are you now claiming that this statement of yours was in
error?

[insult deleted]

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

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.

But I've explained all of that several times and you just don't get it
for some reason, so I hold out little hope that you will suddenly get
it this time around. Your brain clearly just does not work the way
most peoples' does, if you find it hard to remember even approximately
what is in your document in what order, yet easy to remember fairly
long exact phrases at each and every possible spot you'll ever want to
edit.

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

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


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

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.

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. 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. It's as simple, objectively, as the
most complex it's perceived to be by a person of normal intelligence.
Obviously.

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

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!

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.

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.

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

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. It has its niche uses, and that's that. (Firefox's,
BTW, is modeless and has no dialog box; it brings up a bar at the
bottom of the browser window instead with a one-line text field. In
other words, a lot like your emacs and its "mini-buffer", except that
you can actually switch the focus between the web page and the search
bar in a natural way. Also, Firefox does not lie about where your
typing will go/where the focus is, although it doesn't matter so much
since the Web page itself will be read-only.)

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.

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. That's
nigh-universal ... except, apparently, for emacs. (And old software
running on primitive-enough hardware that there's no way to highlight
anything, perhaps.)

Denying reality is also not going to convince anyone. Emacs
demonstrably does have a menu bar and it also demonstrably does have a
File menu.

Graphical ports of it, yes.

In exactly the same way that only graphical ports of Word have File
menu.

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

All of what? The terminal emulator implements those features, or the
frontend of a graphical port, which for the typical unix text-mode app
amounts to a terminal emulator with bells on such as application-
specific menus and menu items.

The hole is getting deeper with every sentence that you write.

What the *** is that supposed to mean?

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.

That's silly, except perhaps when editing code. With typical prose,
though, merely "hitting a word that is used" will leave you with a
funky variation on the theme of "getting there via page-up" where you
use "next match" instead and go about the same speed.

Perhaps if you search for "and" or "the", but you soon learn not to.

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.

Code lets you depend more on exact phrases (since if it's at all
different the program won't compile) but not order; prose lets you
depend on order (since if it's at all different the narrative is
euchred) but not exact wording.

These are concepts any seven-year-old with some computer programming
exposure (Logo or BASIC or something) should be able to grasp. That
you apparently cannot frankly boggles the mind.

"Apparent", of course, is in the eye (and mind) of the beholder.

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