Re: Great SWT Program
nebulous99@gmail.com skrev:
On Oct 29, 7:30 am, b...@pvv.ntnu.no (Bent C Dalager) wrote:
I'm not entirely sure how that works. I can to an extent follow your
reasoning that you need to respond to attacks against you but, surely,
you /could/, if you wanted to, lay the technical points to rest while
using your energies on defending against direct insults? If you would
rather we not discuss it, why do you insist on continuing e.g. the
incremental search debate?
Because people keep saying things so as to suggest that I'm some sort
of clueless nincompoop, or simply wrong. If I remained silent, it
might be taken by some as indicating assent, when in fact I plead not
guilty to all of those charges.
That might make sense if we were talking a nuclear power reactor or
something of the sort. But we're talking about a TEXT EDITOR. Making
that complicated enough to be unusable to newbies is as stupid as
making something like, say, a hammer or a pair of scissors require
elaborate button-pushing and knob-twiddling after first reading a 600-
page manual to use effectively.
Most people who use it would contend that emacs is more than just a
text editor.
Regardless, if you need to do all this elaborate extra work just to
use the basic text-editing functionality, then there is a problem. I
have no problem with needing to faff around with the help and deal
with complication of the UI *when using some more advanced feature*. I
expect something close to rocket science trying to use such a thing as
an IDE, but not when trying to use it to compose an email.
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.
As for whether the rest of humanity would be /incapable/ of learning
emacs if they really wanted to, well, I'm not enough of an elitist to
make or support such a claim. I think humans in general are quite
capable of the things that happen to interest them.
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
completely wrong.
If I don't need to type them, though, it hardly matters. I might have
opened a file solely for the purpose of reformatting it without
altering any text, in which case temporarily rebinding normal keys to
do reformatting operations is eminently sensible.
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.
This is only necessary with primitive search tools, i.e., search tools
where you need to get the target text exactly right the first
time. This is not necessary with incremental search.
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.
It would only find "mistype" if the first "mis" word on the page was
"mistype".
Of course the real problem is if it's the destination that contains
the typo, or you simply don't remember exactly what it says at the
destination at all -- synonyms, variant spellings (e.g. "color" vs.
"colour"), you could paraphrase it but don't know it word-for-word,
etc.; and of course, that it goes to the first occurrence of "mistype"
and selects it, and maybe you want the third occurrence, or the ninety-
seventh, or something. You need to add context to narrow it down,
unless you want to hit F3 (or something) 96 times.
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.
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.
Search finding the endpoints presents a similar difficulty. First all
of the above issues, but once you reach the desired match, you then
need to find the other endpoint. Of course, there's no way to do this
as a selection-extending jump; indeed, it will just select the
occurrence of the query that occurs at that endpoint. Now you need to
extend it back to the other endpoint. Back to square two, I suppose.
So it seems you might (if you were a masochist) use search to reach
one endpoint, but then it's shift-arrows or equivalent to extend the
selection to the other. If the selection is huge, this presents a
problem.
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.
Us mouse users, of course, have already gone on to do several other
things *after* having done whatever we wanted that selection for, by
now...
As I have pointed out previously, if the first occurrence is not what
you want, you can happily type e.g. C-s to get the next occurrence. Or
else you can type more of the search term in order to make it more
unique.
MORE typing! You just LOVE typing don't you? And you still haven't
Well, if the original search term was insufficient, you have to type
some more characters. What's the problem with that?
dealt with the selection extension issue. How do you grow the
selection to the second endpoint after reaching the first? It seems
you need either a shift-click or umpteen shift-arrows here.
No, experience shows that this generally IS the case. I don't
routinely have whole documents memorized exactly so that I can jump to
any part precisely;
If you remember so little of what you're trying to get to that you
can't think of any sensible search strings, then you're left to find
other strategies for locating it.
We're not talking about using search for search though, we're talking
about using search for navigation. That requires knowing an exact and
sufficiently long sequence of characters located at the intended
destination. You may be able to paraphrase what's there, but are you
SURE you remember it word-for-word? And are you SURE none of those
words is misspelled, and therefore not a match to your correctly-
spelled query?
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.
I don't see this being very useful, to be honest, until we have
ubiquitous speech recognition and a fuzzy-match engine, so you can say
a query at it. THAT would be useful, since it's hands-free and faster
and less annoying than a whole bunch of typing.
We touched upon something similar above: perhaps the emacs interface
is only for the very few. I am not convinced, but let's say that it is
- then my claim is that for these few, emacs is superior to other
tools.
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.
If you get it wrong, you fumble around for ten minutes before you go
anywhere, and then end up somewhere other than where you really wanted
to be, you mean.
If I had meant that, chances are I would have written it.
Of course not, because you want to present as positive a case for
emacs as possible, and so will gloss over or entirely omit negatives
that I, of course, will pounce on and gleefully describe in
excruciating detail.
Since your understanding of emacs is so limited, mostly wrong, and
biased, your scenarios lack credibility.
Luckily, emacs has an altogether more sane manner of defining the
beginning and end of the selection.
Why do I have the idea that you're about to describe something insane?
In a nutshell, emacs will remember
where the search originally started and use this as the start point.
An experienced emacs user will typically wonder what the shift-fetish
is all about.
An experienced windoze user wonders what the search fetish is all
about. So to extend a selection you HAVE to do a search, starting at
one endpoint, and land exactly on the other endpoint? (Get it wrong
and you need to return to the first endpoint and try again.)
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.
Searches selecting the hit, rather than everything from the insertion
point at time of search to the hit, seems more natural.
If you want to have one, yes. It is often enabled by default on emacs
variants that are intended for the general population.
Meaning Real Emacs Users do everything blind, I'm guessing. Hardly
conducive to speed. Fumbling in the dark never is, nor does
catastrophically mangling your document because you forgot a selection
was active, nothing in the UI made this evident, and you typed a
single letter intending to insert it at the cursor only to clobber a
huge invisibly-selected chunk of document.
If the selection is invisible (not high-lighted) it's not vulnerable.
You only replace a high-lighted selection by typing. You can always find
the other endpoint with C-x C-x, anyway. If you accidentally overwrite a
selection, you can always undo it (not by C-z, though, usually by C-_).
Talk about "modes" causing problems; now you have an invisible mode
that makes the difference between "k" meaning "insert the lowercase
letter K at the cursor" and "delete this huge chunk of the document".
Even if you can instantly recover with an undo command, this sort of
thing will a) scare the living bejesus out of you and b) waste time
whenever it happens.
I routinely use "kill-region" (C-w) + undo to copy a piece of text,
which I can then use somewhere else.
I'm not sure why C-w would be inherently more difficult to memorize
than c-x.
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. I had no
problem with learning CUA keys despite having used emacs for decades
before I saw DOS or Windows..
The selection always extends from the last mark you set.
Whatever. See above.
(There is also a history of marks, which you can use to revisit old
places in the document.)
Shift-based selection is much too fragile - one single slip of a key
and your entire selection is gone. And there is no good way to extend
the selection from the begin point - you can only extend it from the
end point.
What are you blithering about now? Your tool just lets you create a
selection by going to one endpoint and performing a search that lands
on the other, according to your own description above. Mine lets me
anchor one endpoint and move the other arbitrarily using any common
navigation command (except search). At the same time, it has the
wonderful feature that selections are fragile: it's very easy to get
rid of one, and hard to select by mistake, which supports what you do
99.7% of the time (normal typing to insert stuff). When you need to
select, you just remember not to let go of shift until you're done.
Simple, nuh? And no danger of unexpectedly selecting stuff or
selections hanging around unwanted, and then you go to type something
and you clobber half your document, or shit like that.
You haven't yet explained how you get rid of a selection in emacs so
you can get back to normal editing. I suppose you start a search that
finds nothing, thus setting one endpoint to where you were at the time
and the other to the same place because the search went nowhere? Plus
there's probably some arcane key combination to do it too. Of course,
us Windoze users can just click or arrow without shift held down to
deselect stuff.
You simply navigate outside the selection with some key, maybe a down
arrow. You can also use the mouse and click.
I don't think I ever advocated /not/ learning modern GUI standards. Of
course, as you have pointed out yourself, they are so easy to learn
there's no reason not to.
And once you have, there's no reason to learn emacs or vi or any of
that shit, because you can use something sane instead and if you do
you basically ALREADY KNOW HOW, aside from application-specific
details. But a lot of commonplace commands and actions are thoroughly
standardized.
Well, the alternative is that emacs has selections hang around and
cause problems unexpectedly.
Selections aren't intelligent agents so they're unlikely to be up to
mischief when you're not looking. That must be /children/ you are
thinking about.
See above. Since typing replaces any selection, you do not want things
to be selected 99.7% of the time, and you want to be able to quickly
and easily get rid of selections you no longer need. The
"unexpectedly" part is based on the suspicion that (at least by
default) selections are invisible, which in turn is based on the
observation that the major challenge normally presented by a unix
terminal-mode UI is generally of the "do this simple task ... but do
it blindfolded" variety. :P
There's nothing blind about it. Unmarked selections are not in the way
if you want to do something else. They are simply discarded.
I wouldn't want regular navigation to keep moving a selection endpoint
around without being able to simply unselect. Imagine editing a
document and highlighting some stuff to copy ... and now it's stuck
like that! You arrow around and it extends or contracts the selection.
You click somewhere, and it selects between the start of the original
selection and where you just clicked. You do all the things you might
normally do to get rid of the selection so you can get back to editing
and it stubbornly hangs around. You click at the end of the document
and it selects from wherever the earlier start point was to the end of
the document.
This would be why the traditional way of emacs is to not show the
selection.
That's ludicrous. The problem isn't the highlight uglifying the
screen; it's the very existence of the selection when your next action
requires there to be none, such as when you go to simply insert some
text and want to just insert it rather than replace something with it.
An invisible selection just means you'll think it's safe to just type,
and clobber a chunk of your document unexpectedly when the invisibly-
selected material is replaced by your typing.
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.
Also, the default is to not replace the current selection when you
type.
Well, that's just plain *strange*.
Something could wreck the undo buffer or
the clipboard, especially if I leave it in such a fragile state and
come back to it later and do some other work.
It doesn't take long to become confident of the robustness of emacs'
undo buffer.
Interesting that you don't mention the clipboard. In practise both are
going to be fragile.
Clipboard: you forget you had something important squirreled away
there, do something that involves cut or copy, and boom!
Undo buffer: you forget you intended to undo something, and do
something elaborate. Then remember. Now you can't undo the something
without having to undo the something elaborate first, then undo the
something, and then do the something elaborate all over again. The
something elaborate may have been six dozen tiny changes in separate
parts of a file so that the changes can't all be copied to the
clipboard, or you may not want to clobber the clipboard either.
(Copying from the start of the first change to the end of the last
might include part of the stuff affected by what you intend to undo,
which would mean pasting it back would partially redo what you
undid...)
Undo in emacs is smarter than that. You can undo the last undo by e g
typing a space, then hit undo twice, etc.
Ouch!
If this is the case, then there would be no reason not to use the
navigation keys in emacs either.
Even then, one click is faster than a few up/down arrows and a few
dozen left/right arrows. (The quick exceptions being e.g. the start
and end of the current line, thanks to home/end, and a few others.)
I use the mouse when it is quicker than arrow keys, forward word,
searching, etc.
Your method is just as complicated. It's basically the exact same
thing, except that the key bindings are all strange.
Incremental search makes all the difference in the world. Your
proposed method is unworkable whileas with incremental search it's
extremely convenient.
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.
Wrong assumptions.
That jumps to the endpoint. I assume you want to *select* to the end
point.
There is no practical difference in emacs.
There'd better be, because you don't want a) everything you do to
change the selection when trying to preserve a selection exactly OR b)
nothing to be able to easily deselect the selection when you want to
do something with nothing selected.
Random doesn't matter, what matters is that it's reliably taking you
towards your goal.
Except that if you jump a fixed amount you find your goal at a
predictable time and know when to slow down and start skimming to
avoid overshooting. If you jump a variable amount your next jump might
go to (or past, if it's not directly hit) the goal, even if it's the
third. Basically you need to be familiar with exactly where every
match is in the document, in advance, or else go slowly to each
succeeding match carefully making sure it's not your destination, to
avoid accidentally overshooting and having to loop all the way back
around.
It's very easy to go back one step when searching incrementally.
It's the difference between driving somewhere that's ten blocks away,
so you know you're there after the tenth intersection and have a nice
big windshield to see forward out of and notice any recognizable
landmarks, and going there by bus where it's an unknown number of
irregularly separated bus stops away and you have a cramped little
side window to peer out of, and that gives you a view of more dirt
than outside scenery. Better glue your face to that window and keep an
eye out for your stop, because you don't want to miss it and have to
walk back a long way from some later stop!
Windoze users drive to where they are going; emacs users apparently
take the bus. We all know what that means: it's cheaper, slower, more
awkward, and you have to squint through a dirty side-facing window the
whole way without stopping paying constant attention or you'll miss
your stop. :)
(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.
You
might as well just use plain page-up. It's more predictable and less
typing.
The only drawback, of course, being that it won't halt when you get to
where you actually wanted to go.
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.
If you remember where it is, but have no idea what's actually there,
then sure. Of course, then I'd rather use M-g <linenumber> to jump
there instantly.
More guesswork, this time with numbers.
You need to remember something to find it.
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.
You: Play warmer-colder with line numbers. Maybe amounts to the same
thing, but instead of getting instant feedback and moving the way
you'd run and walk around, you have to type in numbers, jump, do some
math, type in numbers, jump...
No, as I explained earlier, the designers of YOUR tools are relying on
search as a crutch because the old-style text terminals didn't have
what is actually an /efficient/ way of going about things. It's
fiddlier, harder, more typing, and more thinking, and it just plain
doesn't work if you don't know EXACTLY, word for word, what is at the
destination. (And it STILL doesn't work if one of those words happens
to be misspelled there.)
But if this were actually the case, one would have expected mouse and
navigation keys to have outcompeted incremental search long ago.
That is precisely what happened, almost twenty years ago; applications
like emacs that require its use to navigate are now only used by a
proportionately tiny group of word-memorization savants like you these
days. You just won't admit it.
You keep harping on the supposed savants. You don't need to be one to
use emacs.
I doubt you will be able to find many emacs users who are not familiar
with modern GUI standards.
Funny that I've stumbled on one already then (blmblm).
If you are sufficiently clueless as to what you're working with, you
completely fail to come up with a decent search term - then you have
different, more serious problems to work with though.
Apparently people who don't have all documents they will ever edit
memorized word-for-word so they can recite an exact copy in their
sleep are clueless in your opinion. How fortunate that your opinion is
not widely held. The only amount of "cluelessness" needed for your
navigation ideas to completely fail is if someone can *paraphrase* the
entire thing on demand, from cover to cover, itself an impressive
feat, but they're damned if they can remember the *exact* wording they
used six months ago when they wrote section 3.17 or whatever. They
know it says that the frobulus service must be started for the
frobnicator to work, but did they write "The frobulus service must be
started for the frobnicator to work", or "Before using the
frobnicator, make sure the frobulus service is started", or "frobulus
must be running in Services Manager to use frobnicator", or ...
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.
(easy), by guessing and typing line numbers and playing warmer-colder
(fairly easy but tedious), or by hunting through every match for
"frobulus" or "frobnicator" (just as slow and risks overshooting if
you don't recognize the right section instantly on sight, or else
slower still without overshoot risk by reading a bit before each hit
of F3). If you remember that it's in section 3.17 you can also search
for "3.17", though "2.3.17" and "1.3.17" and other such matches may
exist.
The nice thing about emacs, of course, is that the stuff you can do
with any old editor (open files, type text, navigate around the
document, etc.) are just as easy with emacs as it is with notepad -
even for the beginner.
This is the most astonishingly brazen line of bull that I can recall
having seen in the entire year of 2007 thus far.
Try a modern emacs and use the beginner's guide/introduction. You will
be up and running in an hour or less.
The notepad user doesn't have this luxury - he is
stuck with the basic commands for the rest of his life.
I often don't use notepad. I have a couple of other text editors with
specific additional features, but normal GUI/CUA for the basics, plus
an IDE and some other shit installed. I use an appropriately
specialized tool for each job. For example my mailreader knows about
mail headers and has an address book feature, and normal GUI/CUA for
basic editing. I think it even knows about ROT13, though that's more-
or-less useless without having proper nntp service.
And if the tool requires you to do everything in the dark by memory,
then something is *very* wrong.
In this case, you might try adjusting your screen so as to help
illuminate the room.
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.
It is not. What confuses people (plural) is the use of your particular
local brand of newspeak without first explaining that with some words
you don't mean what the OED establishes as standard.
I tend to expect some basic relevant literacy of cljp denizens.
Yes, and I don't recall "incremental search" occurring as any kind of
specialized Java terminology.
What? As near as I can tell from the way these tools are described,
you have to do a lot of things blind, including all long-range
navigation, unless you do them slow instead (e.g. page-up times
seventy-four).
I can easily see where my cursor is, if that is what you mean.
But you can't easily travel instantly to an arbitrary part of the
document. You have to know exactly what it says there, word for word,
character for character. If it says "colour" and you thought it said
"color" and you can't just go for "colo" (e.g. because the query
continues: "colour monitor" or "color monitor"), you're screwed.
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 can't see where you are proportionally in the document, or how big
this document is, at a glance.
Yes you can. A vertical scrollbar shows the relative position. The
current position is shown both as a number vs the full document size and
as a percentage.
You can't see lots of things. You can see only the text within a few
lines of the current cursor position and nothing else at all, while
the interface makes navigation depend on exact knowledge of text
elsewhere in the document.
Search is not the only means of navigation! The current window may show
100 lines or more.
In short, you're out of control and as blind as a bat.
It's a wonder you can get anything done. I'm just glad if it's
limiting how frequently you do usenet and post more of this stuff by
slowing you down -- not that you are aware of being slowed down, due
to subjective illusions I've already explained adequately. :P
This is an inevitable problem with any tool that requires you to type
your command at some primitive sort of command line.
All emacs buffers have memory, and if you run the emacs shell then, of
course, you have a command history also.
This doesn't make much sense. Document windows have a memory. This
doesn't matter in a discussion of prompts/input fields/whatever you
call them over there in wackyland. Nor does some other application you
can run, whether it's a shell or something else.
There is a command history in emacs. You can go back to some old command
and reissue it, possibly after editing it.
GUI tools do better here too: they support cut,
copy, and paste *universally*, including in input fields in search
dialogs and similar places. I rarely actually type something from a
document into a search; I usually paste it in instead after copying it
from someplace else.
C-s M-y in emacs.
It supports pasting into prompts? Huh. With a weird and arcane key
combination that probably isn't the same as paste-into-document, and
is twice as much typing as ctrl+V to boot.
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.
You type *something* to specify it.
Its name perhaps. Like "grep".
That's two more inputs than <click> <click> and you need to spell it
correctly. :P
If that becomes a pain, we use the history feature.
See above. Your shell may very well have a history feature. An "Enter
file name: _" prompt in a text mode application is what we were
discussing instead, however.
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.
If I don't, I will make whatever changes are necessary before
re-issuing it.
If those prompts had history and full editability this would be a
nonissue. If. A proper shell prompt provides such functionality. A
"Please enter file name:" prompt in a text-mode app is another matter,
especially when half the time those prompts don't even support
arrowing back and changing something in the middle, only backspacing
back and retyping from the point of the change on.
Emacs commands are saved in the history, including arguments, and are
fully editable.
If you have followed the debate, you will have noticed that I
advocated using a document window to edit complex commands that you
may want to refine iteratively.
And how the hell do you get those commands to execute then? They have
to be entered into a prompt somewhere to actually execute them. The
prompt surely won't support paste, and that seems to leave copying
them manually from the document window. Lets you avoid forgetting/
misspelling something perhaps, but it doesn't save you any typing.
Of course the command mini-buffer supports paste!
We have the luxury of choosing which to use, as best befits the task
at hand.
Except for one niggling problem: if you type a command in the document
window and hit enter, all you get is the command in the document
window, followed by a newline character. If the intent was to actually
LAUNCH the command you'll just have to go type it somewhere else where
hitting enter means "do it!" rather than "new line".
Which you do by pasting it into the command buffer, or if the command is
written in elisp, you simply execute it with an M-x command.