Re: Great SWT Program

In article <1193881687.388630.8630@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<bbound@xxxxxxxxx> wrote:

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

C-w will cut the region. M-w will just copy it without killing
anything.

Is seems somewhat common for emacs users to use C-w C-_ to copy the
region (this actually does a "cut region" then an "undo") but the
proper command is M-w. If anything, this further reinforces the idea
that emacs users have full confidence in their undo buffer.

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.

backspace will take you to the previous match.

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?

You may have heard of computer mice. They've been all the rage the
last, oh, 20 years.

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.

On the contrary, most selections in Unix are highlighted. It's just
keyboard-driven regions in emacs that may not be so far in this debate
(you can configure it to highlight those also, of course).

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.

And, of course, easy to find in the menus. How clueless would you have
to be not to be able to find the "File->Open File..." menu option
etc.?

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.

Unless, of course, you use tab-tab to get file lists.

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

There's plenty of menus in my emacs, and a number of them also have
button bars.

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

And in emacs, of course, the status bar.

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.

So what is your actual point?

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

In a 3-point font? No thanks.

So make it an 8-point one if that's what you want.

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.

If commands are too complicated for you, don't use them.

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.

Make up your mind. Either it has help or it does not.

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.

People will generally only learn those things that are useful to
them. Paste into search isn't overly useful when you already have
incremental search since you are no longer forced to have long,
complete, accurate search terms.

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.

I suppose it might have been if yours had been an accurate description
of the situation.

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.

It may not make sense but in the wonderful world of emacs, even the
impossible becomes trivial :-)

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.

The mini-buffer uses the standard paste command (C-y). It's
incremental search that does not, because C-y is bound to something
eminently more useful when searching.

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