Re: Great SWT Program

On Oct 31, 8:02 pm, Lars Enderin <lars.ende...@xxxxxxxxx> wrote:
If all you want to do is write email, you don't need emacs, but of
course you can use emacs as an email client if you wish. Using emacs for
plain text editing does not require more training than using Notepad.

Bull! No normal GUI; no easy way to access the help or most other
functionality; normal command inputs just don't do the expected; the
old problem of focus being in the document window only when the help
is either not open, or open to "help on switching windows"...

There's nothing elitist about observing that there are things that
only savants can do, particularly given that most savants are
significantly crippled in other areas.

Only that your assumptions about needing to be a savant to use emacs are
[insult deleted]

You lie! Not only is your insult wrong, but I noted earlier that the
way Bent describes navigation depends on exact memorization of the
entire text of a document.

Personally, I prefer the computer to do all the memorization while I
just tell it what to do. :P

Too bad you'll pay for this in nutty behavior when you go to edit a
text file "normally" sometime afterward and the rebinding is still in
effect because you forgot to remove it.

That's easy to avoid.

No, forgetting to change a setting back after changing it is not easy
to avoid, again unless you're a savant of some sort. This is why
normal human beings use one set of configuration settings and leave it
alone; temporary changes have a bad habit of not being as temporary as
intended. :P

Sure it is. If you type it wrong, it goes nowhere. The in-page search
in Firefox seems to be similar to what you describe, and if I mistype
something that's in a long page, it will jump down to some matching
part of the prefix and bleep and say no matches. For example, if I
type "misyype" instead of "mistype" it will highlight something
starting with "mis", such as "misery", somewhere on the page and
complain when the first "y" is hit.

So you hit Delete a few times till only "mis" remains, then you correct
the search term and go on searching.

Correct it how? Try each letter after the 's'? You'll have tried 25
when you get around to the 'y'. What a colossal waste of time versus
just scrolling there?

If you are in that situation, you can always use brute force - Page
Down, etc, and look for patterns. Search only works if you know what you
are searching for. Regexp search is another possibility.

It only works if you know EXACTLY what you're searching for, and that
is the problem.

Using search to select stuff is particularly dumb. Since searching
selects the match, you need the match to be what you want to select.
This is going to be annoying if it's very long, and probably just
plain impossible if it's more than one line long.

You can usually narrow it down to a few matches.

Which isn't good enough. Suppose I want to search to select a lengthy
paragraph. If I type a piece of the beginning, a) I may have more than
one match with the wrong one selected, and b) even if the right
paragraph is reached (e.g. the match is unique) only the beginning is
selected, instead of the whole thing, and I have to select the rest by
other means.

As described by Bent, you fix the first point (usually by C-SPC). It's
called a mark. Some commands mark the start of search automatically.
It's also easy to switch (current) point and mark with C-x C-x.

Sounds like making a selection is a bunch of extra work. Special
commands have to be used to anchor each endpoint? Won't navigating in
the meantime deselect everything, as navigating tends to do?

Well, if the original search term was insufficient, you have to type
some more characters. What's the problem with that?

The problem is that us Windows users can navigate easily and freely
inside of a document with NO TYPING AT ALL and no guesswork or
memorization, AND in a fraction of the time, so all of this is an
amazingly elaborate argument over a crutch-like instrument that might
come in handy one day if your mouse goes on the fritz. Me, I'd prefer
to have a spare mouse lying about, because the alternative sounds like
torture. :P

By the time Bent's done typing his query and arriving *maybe* where he
wants to go, I'm already there and well on my way to completing the
next step in whatever my task is.

If it works, it works beautifully. If you don't know what you are
searching for, you have to look at the text and try to find it, just as
you would have to do with your tools.

No, with my tools I can get there by scrolling with the mouse and
scrollbar, or scroll wheel. He's stuck hitting page up sixty thousand
times. :P

My claim is that it's at best equivalent to other tools in what you
can do, and inferior in how easily you can learn to do it.

I agree with Bent on all counts.

Unsurprising. No doubt more in order to disagree with me than for any
other reason. :P

[insults deleted]

*** you, you liar. None of the nasty things you said about me are
true.

If you get it wrong, you need only return to the first correct match of
some substring at the beginning of the search string, modify the rest,
and go on searching. If the first match is not the correct one, just
find the next, etc.

If you get it wrong there's a painstaking process of trial and error,
and guessing line numbers is similar, versus the precision and speed
of flick the mouse, you're there.

If the selection is invisible (not high-lighted) it's not vulnerable.

The phantom selection that isn't. Pray tell, if you can't interact
with it at all, just what good is it?

I routinely use "kill-region" (C-w) + undo to copy a piece of text,
which I can then use somewhere else.

So doing tasks efficiently in emacs requires living dangerously? Why
-- cut and paste but no copy?

It being different from everything else in the known universe might
have something to do with it.

Emacs key bindings precede DOS and Windows' key bindings.

In other words, they have an excuse -- they didn't break the standard
because no standard had established itself yet. That doesn't make them
not nonstandard and awkward, though.

I had no problem with learning CUA keys despite having used emacs for decades
before I saw DOS or Windows..

That might have something to do with the fact that CUA keys make
sense. It helps, too, that they're the same across a truly enormous
number of applications instead of confined to one.

(There is also a history of marks, which you can use to revisit old
places in the document.)

So much for a simple model for selections it seems. The novice won't
know if he's coming or going ... or what chunk of the document will go
away if he hits cut or delete. :P

You simply navigate outside the selection with some key, maybe a down
arrow. You can also use the mouse and click.

??? I thought you'd implied that once you set one endpoint you're
always at the other of a selection between the two. Moving down would
then just extend the blasted thing a line, or shrink it a line,
depending.

As for a mouse click, anyone inputting a mouse click to emacs remotely
via a VT220 or whatever terminal and posting the video to YouTube as
proof wins a prize.

There's nothing blind about it. Unmarked selections are not in the way
if you want to do something else. They are simply discarded.

The phantom selection that isn't, once again. If a tree doesn't fall
in the forest, but nobody's there to not hear it, does it make a
sound? :P

What is this, a text editor or a Zen meditation tool?

You *cannot* clobber an unmarked selection. Typing will not overwrite
it. If you want to replace a selection (unmarked or not), type C-w, and
it will disappear (but can be recalled). Then you can type anything in
its place.

Lovely, so your invisible phantom selection can still be accidentally
destroyed. Meaning nobody will dare to hit Ctrl+w for fear of the
consequences. Combined with a history of past selections, it sounds
like *anything* could disappear, and not even near the current
insertion point.

Undo in emacs is smarter than that. You can undo the last undo by e g
typing a space, then hit undo twice, etc.

Eh. Worse than useless. Undo undoes undos means only one undo level.
Sane apps have many undo levels and separate undo and redo commands.
And none can cope with a "branch": do X, undo X, do Y -> X can't be
gotten back now, and do X, do Y, undo Y, undo X -> Y can't be gotten
back without also redoing X. There IS NO way to get around these
issues with undo, because the change Y may depend on the change X in
some way. The most sophisticated possibility would record undoable
changes as diffs and allow you to *try* to apply some of the patches
out of order, but the results would not be dependable. *Could* not be.

No, it isn't. I wouldn't want to try to navigate a web page using
solely Firefox's search -- I'd need to memorize the whole thing
precisely in order to find any given spot reliably. Maybe such
memorization comes easily to you, but it doesn't for the vast majority
of human beings.

[insult deleted]

Liar!

It's very easy to go back one step when searching incrementally.

I'm talking about "next match", the function that is bound to F3 in a
typical Windoze app and to Christ alone knows what in emacs. It has no
"previous match" correspondent to go in the other direction,
typically, so if you miss your stop, you have to wait for the next
bus, so to speak.

(There's an exception when the route is familiar. But how often do you
have the entire text of a document you're working on memorized,
character for character exactly? And just in case -- how often does an
ordinary human being?)

Overworked analogy again.

???

I can only assume that whatever you said is some feeble attempt to
rebut my most damning point against emacs. A failed attempt. It
doesn't even make sense. Nothing in the paragraph you quoted is even
an analogy. The issue is memorization, and I don't see you weaseling
out of that one until they invent a good fuzzy-matching search that
knows thesaurus synonyms and can recognize reordered sentences. I'm
guessing that the problem of implementing the search in question is AI-
complete.

Neither will a search if there's matches on the other side of the one
you're interested in and you are using next match as a "randomized
page up" to navigate.

Certainly, if you wish, but usually this is a less efficient solution.

Only if you've memorized the whole document down to the last letter,
period, comma, and digit.

Doesn't follow.

Does too.

More guesswork, this time with numbers.

You need to remember something to find it.

You need to remember an exact four-digit number to find it. In fact,
instead of knowing the exact text of the whole document precisely, now
you need to know exactly what line number goes with each important
fact. This isn't gonna happen unless you give up the leftmost five
characters (1/16 of the screen real-estate!) to displaying line
numbers for every line and spend hours poring over the whole fucking
document. Lovely. Just lovely.

Me: Scroll to approximate area; then make more precise small movements
to get the destination in view and stop there.

We can do that too, it that's what it takes.

With what, some kind of "accelerating and decelerating page up" key?
That doesn't sound very easy to use to me. Windows apps of course give
you a scrollbar with many nifty features. The little bit you drag (the
"thumb") has a height representing the proportion of the visible
portion to the full document, giving you an idea of the document size
(e.g. that this posting I'm responding to is way too fucking long).
Its position indicates your proportional position in the document.
Click and drag it and the document whizzes by; drag slower when you
are close to where you're going. It's like your accelerating and
decelerating page up key, except that you can see what the *** you're
doing and where the hell you are in relation to the whole document. In
fact the latter, and the document's size, ALL THE TIME and not just
when scrolling. Handy! Jump around with no memorized numbers OR
memorized text. You can also click the arrows for up- and down-arrow
like effects and between the draggable tab and these arrows for page-
up and page-down like effects, but I use these less since the keyboard
works just as well for that.

You keep harping on the supposed savants. You don't need to be one to
use emacs.

No, you just need to be one to use it and be productive instead of
frustrated.

Now you could probably find this if you only had a booleanesque
search: "frobulus" NEAR "frobnicator", say (assuming this is the only
area mentioning both). Otherwise you can find the section by scrolling

If the need arises, you can use regexp search.

Regexp search doesn't provide, by my understanding, anything like X
NEAR Y searches. In fact most boolean-type searches don't even provide
NEAR, which would be one of the most useful features if they did.
Regexp searches also require studying the help for each one unless
you're a rocket scientist.

Try a modern emacs and use the beginner's guide/introduction. You will
be up and running in an hour or less.

Try Notepad. You will be up and running in a second or less.

Even your "hour" figure is generous; it assumes that you can read some
hotkey related instruction once and it will stick in your memory just
like that. This is false for most human beings. I'd describe the
exceptions, but you seem to have some sort of objection to my using a
certain six-letter S-word...

Without such memorization feats, you'll be referring back to that
tutorial for weeks, and if it's not easy to switch between it and the
document you're working on before you've solidly memorized at least
the panel-switching keys, perhaps months. And getting next to nothing
done in all of that time.

The software makes you do everything in the dark by memory. Had you
forgotten? Or are you like one of those savants that can play chess
blindfolded and can see the actual state of the board in his head, all
32 pieces and exactly where each one is, unerringly? If so you might
not have even *noticed* this property of unix software. :P

The above is your distorted view of unix and emacs. No relation to reality.

Every relation to reality. Just look!

Windows: Select stuff and it's visibly highlighted.
Unix (console mode stuff): Invisible selections commonplace.
Windows: Commands like search are easy to find in the menus.
Unix: Something like / or Ctrl+S may be bound to search; hit keys at
random until one of them does something useful.
Windows: When you need to specify a file, you get a visual file
chooser that lets you browse the directory tree and directory
listings.
Unix: When you need to specify a file, you get a prompt saying "Enter
filename:" to type at. If you don't know the exact path and name, or
misspell it, you're screwed.
Windows: Available commands are generally easy to discover by menu-
browsing and similarly.
Unix: All you see is a document to work on, or even just a prompt of
some sort. Nothing else is displayed. Even if there's help, you have
to guess what will display it (?, Ctrl+H, or one of a bunch of others,
even F1 once in a blue moon).
Windows: Useful status information like document size, place in
document, etc. tends to be shown via scrollbars, status lines, etc.
Unix: All you see is a document, or even just a prompt

This isn't 100% universal -- there are bad Windows apps and good Unix
console-type apps (and graphical ports of same). But the pattern
definitely exists.

You can't see what's selected to know what will be cut or copied,
replaced by paste, etc.

It won't be destroyed unless it's visible!

You said earlier that the "cut" command would nuke it even if it
wasn't. Make up your damn mind!

Yes you can. A vertical scrollbar shows the relative position.

In what application? I thought we were discussing emacs?

Search is not the only means of navigation! The current window may show
100 lines or more.

In a 3-point font? No thanks.

There is a command history in emacs. You can go back to some old command
and reissue it, possibly after editing it.

Editing commands? Now it is sounding excessively complicated.

Because C-s C-y includes the current line in the search string, pasting
must be done with a different key than the normal C-y. This is a special
case, which I must admit I did not know of.

There's the other issue: functionality is not discoverable and the
help blows chunks. This is evidenced by even purportedly knowledgeable
people missing on how to do things like paste into a prompt. A Windoze
user has no such issue: you give the input field in question the focus
and hit Ctrl+V.

The M-x grep command prompts for arguments - search string and file(s).
After execution, you get a buffer with matching lines. You can choose
one of these matches and instantly have the document in a buffer. "Next
match" is a simple key combination.

Eh -- there's a command when editing a text file to interpret the line
with the insertion point as a file path and open it? What a mess. All
because they couldn't implement a decent file chooser, not that anyone
likely could back in the good old VT100 days. Hardware capabilities
just weren't there yet to make such a feature work on anything but
high end SGI workstations.

Emacs commands are saved in the history, including arguments, and are
fully editable.

??? At a one-line prompt? The equivalent of a one-line input field in
a Windows dialog box? This makes no sense. There isn't *room* for the
drop-down or any other useful visual feature anyway.

Of course the command mini-buffer supports paste!

Not using the normal paste command. But you just said you'd just heard
about a special case "paste into prompt" command. :P What a mess.


.

Quantcast