Re: Great SWT Program

In article <0061527e-5786-49fd-8a19-bb761a36abf5@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<nebulous99@xxxxxxxxx> wrote:
On Nov 13, 6:19 am, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
It's only unobvious because you're not trained in the use of
emacs.

Something tells me that it won't ever be obvious to most people.

Of course not - most people will probably never be trained in emacs.

And at any rate, the summary of the techincal steps of that
command is still more understandable than "move mouse to 223,633 -
right-click and hold - move mouse to 230,742 - release right button".

When stated that way, perhaps, but mouse movement to a visible object
on the screen "comes naturally", while that sort of arcane command-
line sort of thing does not. It didn't even seem to be just a command
line; it seemed to involve a mix of command line and hotkey type
input.

It involved command auto-completion, this is probably what threw you
off.

[insults and various BS 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.

Yes, /the/ language. What "emacs language"? The localization being
discussed is the English-language localization, is it not?

It is not.

Then this whole discussion is pointless, as the only experience I've
had has been with the English version.

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

That much is certain. What it is is unusable. What little feedback the
UI does provide is completely unreliable. :P

In much the same way, of course, that a Lexus is completely incapable
of transporting people from one place to the other. It must be,
because I never actually tried it.

Bull***. You can't trust backspace to delete the character left of
the insertion point. You can't trust esc to escape from things. You
can't trust cut to limit its activity to only the highlighted portion
of the document. You can't trust the undo key to behave in a simple
and obvious manner. You can't even trust the app to insert your typing
at the insertion point instead of someplace else, based on one of your
more recent postings.

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.

And that's assuming you HAVE learned the key
bindings for these things, so that you don't find it odd that ctrl-X
doesn't cut and ctrl-Z doesn't undo. This is more than skin deep
brokenness we're talking about.

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

The next WHAT? Word? Where? Are you claiming it can read the user's
mind? Because that makes no sense and I flatly disbelieve it.

The next word that starts with "ex".

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.

What rules are those, pray tell?

DON'T LIE TO THE USER! If it says "escape" it must escape. If it says
"this is what will be cut" then it mustn't cut anything else. Etc. JEE-
ZUS! How fucking hard can it possibly be for you to understand???

The lies you speak of only exist inside your head. For those of us who
bother to actually learn the tools that we use before doing anything
serious with them, no lies are involved.

[more BS snippage]

But sometimes it works (e.g. in Firefox to switch tabs); if it works
in a given application it works consistently. And most apps just use
multiple top-level windows, which submit to alt-tab 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.

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. You do need some training to
truly harness its full potential, however.

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.

Text typed
going somewhere other than the insertion point is an even more
blatantly wrong behavior than cut not deleting the highlighted text
and ONLY the highlighted text.

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

You keep trying to force your own learned GUI conventions onto my
descriptions of emacs features. This is at the crux of the
misunderstanding.

Wrong. This is not some "learned GUI convention". This is a basic law
of computer interfaces, which is that you don't visually lie to the
user about where the insertion point really is!

Failure to comprehend what is being said does not mean that you are
being lied to though. It just means that you have some learning to do.

That's a "convention"
in much the way the law against murder is a "convention". :P

I expect that it's a convention in much the same way that GenCon is
one.

If what you're saying *now* is true, this search is actually worse in
some respects than bog-standard Windoze ones (besides the awkward
interface, which training might help with). What if you want to make
some change near many or all occurrences of some particular term? This
is easy to do with a typical Windows tool. With your emacs as you've
described it you'll have to launch a new search and type the query
over and over again for each instance you need to do an edit near.
What a pain in the ass!

It would be if this were at all factual.

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. If you want to continue
to previous search, you can do that without typing in the search term
once more.

None of which can quickly make precise selections in two-dimensional
space, unlike a 2D analog input device of some kind, whether mouse,
joystick, thumb stick (like Thinkpad laptops have), trackball,
trackpad, or touchscreen.

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.

Your idea of "useful" is both missing useful information and
gratuitously cryptic and unintelligible.

To you, yes.

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.

* - The tooltip now displays "Language: French (France)". Heh.

And I will go with pretty and efficient. So there!

It's just too bad that such an option doesn't currently exist.

It bloody well does, and I use such tools every fucking day, asswipe!

It is generally a good sign that people who feel they need to use
expletives to get their message across full well know that their
reasoning alone is altogether insufficient to convince anyone.

You will start the search while on the first endpoint so this isn't an
issue.

And if you don't, for whatever reason?

If you don't what?

Start the search on the first endpoint, numbskull!

Does your mother know that you use this sort of language in public?

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.

And since you can't scroll in text-mode without moving the
insertion point with e.g. page down (or page up) ...

It's difficult to answer this question since it is based on altogether
faulty premises. However, if you want to establish a region without
using incremental search, you can mark the start of the region with
C-<space>.

Bull*** -- not if we make some basic assumptions, such as that you do
these things immediately after one another and the basket doesn't have
large holes in the bottom.

Exactly - in order for your mathematical approach to hold in the real
world, you need to make an incredible number of detailed assumptions
about the situation.

No, only a few basic common-sense ones, ***.

Ooohh, you've got me frightened now. How will I ever be able to
survive such a verbal flogging?

You appear to insist on using mathematics to model complex human
behaviour. There exist no usable mathematical models for the human
psyche, so your attempt is doomed to fail before it even reaches the
drawing board.

It takes an equally incredible amount of luck for
such a complicated set of assumptions to actually hold in any given
sitation.

Bull. Really, how often does your basket spontaneously develop huge
holes while your back is momentarily turned?

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.

Of course it isn't - they do altogether different things. It's your
love for using the scrollbar as a search tool that is puzzling.

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.

So, to navigate familiar documents, or small
enough ones, and search to find stuff in large, unfamiliar documents
such as Web pages over a certain length. Same as nearly everybody
else, weird idiot-savants notwithstanding.

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

And, by the same token, if using Word and breathing air are mutually
exclusive - I'll take the air any day. Luckily for both of us, our
assumptions of mutual exclusivity do not hold.

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?

It would seem that the inefficiency of the tools that you use has
caused you to come to /expect/ searching to be a complicated,
time-consuming process. 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.

Nice try twisting my words around. But the scrollbar lets you get to
anything whose position you know approximately. The more
approximately, the more approximately it gets you there. Search on the
other hand is all-or-nothing: if you know some of the text at the
destination precisely, you can get there; if you don't, due to a
single different spelling or word choice than you remember, you go
nowhere. The shorter the query, the more false positives and the
slower a slog through them it is to get to your destination. The
longer the query, the more typing of query text you need to do, and
the greater the risk that you'll go exactly nowhere because it doesn't
actually exactly match anything in the document. Neither beats
scrolling if you know roughly where your destination is, which is
normally the case without any special memorization.

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.

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.

In mathematics, a contradiction such as this would prompt the
mathematician to go back and re-examine his initial assumptions.

In Twisted Maths, however, other rules apply.

Unless you are discussing editing code, whose structured nature
and rearrangeability does make the latter more the norm -- with code,
you know you're looking for void foo() but not where it is in the
file, because it doesn't matter if it's declared first or last among
all the methods of the class, but it does matter what its name is, to
the compiler; versus with natural-language prose where the order of
text is more important than the exact wording, so it's OK to replace
"the king was killed by the lion" with "the lion killed the king" but
you can't go putting chapter 17 before chapter 3 without completely
scrambling the narrative.

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.

So it seems that search might make more sense with long source files,
but with almost anything else (short source files and plain text)
you'll want to go with scrolling.

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

Where is the complexity?

I'll quote some complexity back to you: "M-x local-s<space><space> e
insert-k<space><space><enter>"

That this seems complex to you doesn't mean that it /is/ complex, of
course.

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.

I can only conclude that your tools do not provide
auto-completion functionality and for this I pity you.

How is "auto-completion functionality" at all relevant here? It was
not under discussion. The complexity of some arcane command unrelated
to auto-completion was. (As I recall, it had something to do with
making temporary key bindings that evaporate when you close your
current document, or something like that, instead.)

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

Then you're sitting too damn close to the screen.

Or perhaps I actually like to have large windows. Apparantly, this is
another feature that is not supported by your super-duper GUI-magic.

I have a plenty big enough screen and usually maximize text editing
windows, and I don't have this problem. I wonder why you do?

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

Then you evidently use something other than enter to submit the
search, and I claim victory on another point you were trying to refute
earlier.

Which one was that?

I'd said that enter wasn't always the key used to submit things typed
at prompts, and you'd claimed that it was. Now you've indicated that
it can't possibly always be the case, because you said that paste into
search didn't immediately launch the search, yet enter was not needed
to launch the search either, meaning that paste into search may be
followed by some key that is not enter to submit the query and begin
the search.

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

[assorted bull*** and pointless attempts at sophistry deleted]

I prefer assorted chocolates. :P

Bah. It's cotton-based paper all the way if you ask me!

It does nothing of the sort, because it's completely bogus. It's a
matter of convention

Windows UI convention, certainly. There are other conventions.

No, English-speaking-world convention.

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

You misunderstand the issue. We're not talking about keybindings that
are different from the Windows norm (or a steering wheel on the
"wrong" side of the car). We're talking about fundamental problems
with the UI behavior

These are only problems to you because the first paradigm you learned
was a different one.

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. An application will
highlight text /to bring it to the attention of the user/, whatever it
was that made the application think the user wanted it brought to his
attention. Some times it will be because the user may want to see
which text is in a selection. Other times it will be because the user
may want to see his search hits. Other times still it will be because
the user may want to see where all the costs are going, etc.

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.

Of course, emacs demonstrably has all of this also so you're digging
yourself a really big hole here.

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. The
emacs you can download from ftp.gnu.org today (and for the last couple
of decades) is a native graphical application.

Luckily, I need neither. I can just search regardless of document
order or of exact phrases used. So long as I hit a word that /is/
used, I'm there.

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.

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.

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