Re: Great SWT Program

In article <1193628608.132320.287710@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<bbound@xxxxxxxxx> wrote:
On Oct 27, 10:49 am, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
You should lodge your complaint with the Usenet Frequent Posting
Arbitration Council.

No. YOU should let this rest. It's not like you're the one under
attack here.

The attack/defend portion of this thread doesn't interest me all that
much. I consider it background noise.

You could just let this drop quietly and go on about your
life without any negative consequences. Unfortunately you are not
giving me the same choice.

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?

What was this system designed for use by?

People who bother to train in their tools before putting them to
professional use.

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. If you had a tool that could be a hammer, pliers, crowbar
/and/ also perform all of the functions of the entire Black&Decker
catalogue, wouldn't it seem reasonable if you had to do some training
with it before you could put this wonder-tool to its fullest use?

A computer? Humans just
aren't that good with either a) perfect memory recall or b) getting
long fiddly sequences of anything exactly right in one try.

Some humans, perhaps.

NEARLY ALL HUMANS.

Perhaps. We're largely only talking a very small subset of humans here
though: technically inclined, computer-savvy, and largely programming
knowledgable people. Nearly all humans are not in this group so I'd
say you might be close to the truth.

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.

We are not talking about vi. We are talking about emacs, and in emacs,
the R and T keys need to just insert into the document. Binding them
to something else will make those letters untypable.

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. And if I /should/
develop the need to enter text after all, I'll just reestablish the
default key bindings and be merrily editing away.

Why would it need to be unique?

SO THAT THE SEARCH SELECTS EXACTLY AND ONLY WHAT YOU WANT IT TO!!!
JESUS!

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.

Why do you keep on doing this?! First you talk about the
virtues of using lots of fiddly typing instead of one mouse click to
make a selection. Now you seem to assume a completely different goal,
go to the first occurrence of <insert something here> rather than
select a specific occurrence.

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.

Pick one goal to discuss please. When I
show how your tools' awkward means of achieving it is inferior to my
tools' straightforward way of doing it, acquiesce to that fact instead
of explaining in an ever-so-reasonable tone how your tools' method
perfectly achieves some other, significantly different goal.

My tool is still doing the same thing: finding the occurrence that you
are actually looking for.

I've discussed using search as a shortcut to navigation before, and
why it sucks: a) you're limited to destinations that are "sufficiently
unique", which in a not-too-repetitive document admittedly all of them
are, but often only with a long and specific search query

Experience shows that this is generally not the case.

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. In this (somewhat rare) case, you
wouldn't use incremental search any more than you would use standard
search dialogs.

In fact, that they are
unusable to nearly all of the human population of the planet means
that they are distinctly inferior than methods that would be slower
*for you* but are actually possible and reasonably fast *for
everyone*.

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.

So bloody what? The object of the game is for
everyone to be productive, not for anyone to set a speed record.

I'm not so sure about that. My employer has me log hours spent on each
project, and /does/ care how big those numbers are.

If
you're very productive with unusual tools nobody else could use
because you yourself have very strange capabilities, good for you! But
you're in no position to be claiming that everyone else and their
tools sucks. (...)

Well, everything is relative I suppose.

I recall stories of secretaries and the like who were transitioning
from DOS-based tools (for booking, or distibuting merchandise, or
managing customers, etc.) to Windows-based tools, and they would
remark that the new tools were slow and cumbersome. Often it turned
out that these secretaries had learned the various keyboard commands
of the old tools by heart and could easily get from "input new
customer address" over to "process supplier invoices" by pressing
"keqndfgdgh" or whatever in quick succession whileas with the new GUI,
there was all sorts of mouse navigation and clicking, and missing, and
re-clicking and other sorts of confusion going on.

Based upon this, I conclude that you don't need to be a savant to
learn some rather obscure tools and memorize command sequences. You
only need to be interested, and it may need to be an important part of
your job.

If you get it wrong, you refine it on the fly.

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.

So you press C-space and then use C-s for an incremental search
towards the end of the region.

That's like clicking at one end of the intended selection and then
clicking at the other. You wind up at the other end of the selection,
with no selection. With a GUI you SHIFT-click the other end. Your C-s
just ... goes to the other end. I'm assuming that holding down shift
as well won't help any here either.

Luckily, emacs has an altogether more sane manner of defining the
beginning and end of the selection. 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.

In fact I'm not even clear on how you can make selections at all with
text-mode software. Is there even a visual highlight?

If you want to have one, yes. It is often enabled by default on emacs
variants that are intended for the general population.

Half the useful
things you can do with selections (such as move them with a drag
gesture) won't work. The rest (e.g. cut, copy, paste) no doubt don't
use any normal or easily remembered key to activate (e.g. ctrl-X for
cut).

I'm not sure why C-w would be inherently more difficult to memorize
than c-x.

I can't think of any way to extend selections that won't be less
natural and more troublesome than just doing any navigation command,
except with a modifier key held down ... which clearly rules out
extending selections by means of search. (And where would it extend to
anyway? The first match? The last?)

The selection always extends from the last mark you set.

This is easy with shift-
arrows in a Windoze app, and easier with a shift-click if it's very
far.

Easy, it is not, nor convenient. Possible, yes.

Maybe not for someone who hasn't put in the minimal effort needed to
learn basic GUI manipulation.

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.

(Minimal effort that actually pays off
in MORE THAN ONE APPLICATION at that -- in fact almost ALL of them.
Whereas anything you learn in something like emacs just trips you up
and has to be unlearned when using anything that isn't emacs, such as
any Windows app, vi, this IDE, that mail software...)

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.

Incremental search forward is C-s. And emacs, unlike your much vaunted
GUI editors, doesn't suddenly decide to forget where the start of your
region is just because your finger slipped on the Shift key midway
through the Shift-arrowkey procedure.

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.

Once you have C-s'd your way to
the region endpoint, emacs will still remember where you were when you
started and you can proceed right on to making region commands.

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.

Try to type, and it replaces the whole selection.

Also, the default is to not replace the current selection when you
type.

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.

You cannot actually do this without considering its general position
relative to your start point.

I can do this with a flick of the eye and a flick of the wrist. I can
do it in mere milliseconds, in other words, if the destination is on
the screen.

If this is the case, then there would be no reason not to use the
navigation keys in emacs either.

Indeed, I'd have to look at one end
point and decide how long a chunk starting there was needed to be
unique, then hit page up a few times, then ctrl+f, then type what I'd
memorized, hit enter, and pray.

You could if you wanted to complicate matters over-much.

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.

You would press C-s and then type enough of the target text for it to
be reasonably unique, and possibly press C-s a couple more times to
skip false positives.

That jumps to the endpoint. I assume you want to *select* to the end
point.

There is no practical difference in emacs.

(snipped rants)

Of course, this only works if "chunk" is unique enough to specify
exactly and only where you want it to go. If there's other occurrences
of the word "chunk", you're screwed.

Or perhaps I just have to press C-r a couple more times to skip the
false positives. Not entirely unlike the "Find Next" button that you
may be familiar with.

This is the equivalent of going where you're going with a page up key
that goes an effectively random distance each time it's used.

Random doesn't matter, what matters is that it's reliably taking you
towards your goal. Or would you say that binary search is also useless
because it gives you basically useless hits the first couple of
iterations?

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.

Or use the mouse, if you can.

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

Search is for finding something when you remember WHAT it is but not
WHERE it is. Using it to find something when you remember WHERE it is,
and especially when you may not remember exactly WHAT it is (letter
for letter and word for word), is just plain stupid. Mouse or even
page-up is superior there, the latter just because it's predictable
how fast it goes.

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.

What is actually the case is that the designers of your tools are
relying on the mouse as a crutch to avoid having to implement what
would actually be an /efficient/ way of going about things.

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. Not
only is incremental search still around - it's even being implemented
in what is otherwise standard GUI software.

I am lucky
enough to have the best of both worlds: I can use the mouse if I feel
like it, or I can use an efficient keyboard-based interface if that
seems more opportune.

No, I'M the one with the best of both worlds, because I can use
something that is natural to use and requires little training for each
additional application, instead of starting over from scratch with
every one of them, and I can do what I want to do as fast as is
reasonably necessary, given that the object is to do the job well, not
to set a speed record.

I doubt you will be able to find many emacs users who are not familiar
with modern GUI standards.

Haste makes waste. Racing through the job as
fast as physically possible just leads to not thinking things through
and making mistakes, and then spending additional time to go back and
correct them.

Yes, I would not advise this.

You can happily use C-r/C-s to make searches across several megabytes
of text. This is common enough in actual usage that I can quite
happily recommend it.

It's useless, though, unless you have several megabytes of text
committed to memory word-for-word. There's maybe three thousand people
on the whole fucking planet that are even capable of that, and maybe
three that would actually prefer to have to do so to get a job done
than to use tools designed for the rest of us. :P

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.

I generally don't consider learning to be painful; your mileage may
vary.

I consider any time spent flipping through manuals and struggling to
make equipment work when I'd rather be already using it to get the job
*done* to be painful. Sometimes it's not avoidable -- sometimes the
job you are doing is inherently complicated and necessarily requires
complex and fiddly tools to do it with. But we were discussing text
editing here. If the tool used to do it is much more complex than a
typewriter to use for basic editing tasks, then something is wrong.

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. But then, as you grow more and more proficient
with the tool, the emacs user will say to himself "there must be an
easier way to do this particular thing" and if he investigates the
matter then more likely than not he will find that - yeah, there
is. And then he has learned one additional feature that he brings with
him into the future. The notepad user doesn't have this luxury - he is
stuck with the basic commands for the rest of his life.

And if the tool requires you to do everything in the dark by memory,
then something is *very* wrong.

In thise case, you might try adjusting your screen so as to help
illuminate the room.

I do apologise if the use of programming terminology in a programming
newsgroup is confusing to you.

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.

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.

This is an inevitable problem with any tool that requires you to type
your command at some primitive sort of command line. This was why I
found someone's suggesting of launching external commands from inside
an editor to be odd -- at least using a proper shell prompt you have
features like command history available that a specialized command
processor will provide, but a text editor that's trying to be a jack-
of-all-trades won't.

All emacs buffers have memory, and if you run the emacs shell then, of
course, you have a command history also.

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.

Much faster. Not only can I repeat with
variations by just editing what's in the box, I can also grab a search
term from somewhere. For instance if I see something weird in a Web
page I can select it, hit Ctrl+C, click the Google box in the top
right corner of the Firefox window, hit ctrl+V, and hit enter to
google it. I'll bet you have some browser that lets you do something
similar in ten or twenty keystrokes but requires all kinds of awkward
and specialized learned commands to do, instead of using highly
generic, system-wide commands that work the same everywhere.

There is web client support in emacs, but I tend to use Opera and
Firefox.

What are you blithering about? Stop trying to put words in my mouth. I
never said anything of the sort. In fact the only mention I even see
of the javadoc is this discussion, where you seem to be dithering in
some strange way for some reason. But a) the javadoc will be
reasonably comprehensive because Sun's javadocs generally are, and b)
clearly it's still awkward even for experienced programmers based on
the posts here.

The quality of Sun's javadoc is all over the place. Some of it is
good, some is bad and some is outright wrong.

The only way in which this could be achieved would be by going the way
of insanity and using macros of the form
#define BEGIN {
#define NOT !
and so forth.

BS. C code is far cleaner than e.g. old-style perl, or brain***, or
regexps. It has meaningful identifiers, if reasonably written, for
starters.

Why would you want to have identifiers in regexps? Just to
gratuitously complicate the matter?

If you are doing nontrivial searches, there isn't any trivial way of
doing them. This basically /should/ have gone without saying.

99% of search needs are trivial searches. Turning searching into
rocket science to serve the 1% at the expense of the 99% is simply
foolish.

A rocket /would/ get you to work very very fast though.

It's a product of its times, and I'm sure it was decent in those
times. But now ... even updated with grafted-on GUI features its
graphical ports are playing catch-up and not doing a great job of it.
Nobody used to a real GUI app will mistake it for one when none of the
GUI stuff works quite right and a great deal cannot be done through
the GUI. Not that the GUI is broken, per se, but it does everything
quirkily and interprets common inputs with slightly different
semantics from a well-written native GUI application. Java
applications using AWT or Swing are no more native, but do better,
because the GUI was not some afterthought but was integral and
designed from the ground up to adhere to standards and to behave in
expected ways.

This is just a difference of perception though - you don't like emacs
because it's different. That's fine.

It's an editor so thoroughly *encrusted* with bells and whistles that
you will strangle on bell pulls and choke on whistles just trying to
use it for a plain ordinary editing job. You can't even see what the
*** you're doing through all the bells and whistles. Imagine taking a
perfectly nice PDA and physically attacking actual bells and whistles
all over its surface everywhere using Superglue, and then trying to
use it after allowing time for the glue to dry, and you have a first
approximation to trying to get anything useful done with emacs. Oh,
let's not forget taking the PDA's slim user manual and tearing out the
individual sheets, along with those from phone books, thick stereo
manuals, the huge manual that came with Photoshop 6.0, and printouts
of every page at Microsoft's Web site describing one of their QB584329-
style bug report and workaround entries, shuffling these, devising a
300-page index using some oddball variant of the Dewey-Decimal system,
and then binding the lot into a single 4000-page tome. Thus producing
the thing you have to consult for help when trying to operate the
souped-up PDA.

You shouldn't overextend your analogies. You might sprain something.

What the *** are you blathering about? The start of the line is
exactly where indents go BY DEFINITION

Oh well, call them tab stops if you like then. Whatever terminology
you choose, vertically arranging text that is in the middle of a line
is a well known need for text editors.

Not in any English prose or Java code that I have ever written, except
in the latter case in ways adequately (and far less painfully)
provided for by the auto-indent features of IDEs.

So you think the tab stops across the top of MS Word, OpenOffice
Write, etc., are just pretty decoration?

And yet, they cannot account for all the special cases in which only a
human can get the most readability out of a section of source code.

Of course. Only manually typing or deleting tabs, spaces, and newlines
can do that. If it is a special case too delicate to leave to
automation, then it is a special case too delicate to leave to
automation. That isn't going to change no matter what bells and
whistles your editor happens to have, unless these include artificial
general intelligence. :P

And this, of course, is when it's handy to have a powerful tool with
which to do the manual editing/reformatting job.

Not if you don't mind inefficiency in source code reading and
maintenance, no.

You may believe that but it simply isn't true. I don't encounter any
such inefficiencies using the much easier to use and more
sophisticated Eclipse.

Eclipse's editor is neat enough. It's certainly not an emacs, but it
gets the job done.

If you actually have to spend a considerable amount of time thinking
about whether to use "down one line" or "incremental search", I
suggest you are ready for retirement.

I don't -- it's a quick decision to either arrow to it or click it for
me. It is you who has to spend time making more complex and nuanced
decisions trying to micro-optimize, and ending up wasting more time
that way than you stand to save with the micro-optimizations.

I suggest that you 1) obviously not having tried and and 2) not being
me, really don't have enough information to be able to accurately
evaluate the issue.

Of
course, it's only a fraction of a second on each occasion but it adds
up and adds up and adds up...

Even if that were the case, adding a fraction of a second in order to
save dozens of seconds, or even minutes in more extreme cases, seems
oddly . . . desirable.

You shouldn't overextend your analogies. You might sprain something.
:-)

You shouldn't criticize me. Period.

Oooh - you shouldn't drink and drive. Comma.

Perhaps this is the reason we don't type the full path to the binary?

You type *something* to specify it.

Its name perhaps. Like "grep".

Over and over again.

If that becomes a pain, we use the history feature.

It really
seems you're insensitive to having to do six times as much typing to
get things done as I do, which I find very strange. It may feel faster
because of all of the activity, but it really isn't. It's rather how
it may seem faster to drive continually on back-country roads around
town to some place across town instead of going directly through the
middle of the city in stop-and-go traffic, only you find you arrive at
7:30 if you go straight there and it takes until eight if you go
around. You're more active more continually going around, so it feels
like you're getting more done, but in fact, a lot of what more you're
getting done is really just waste.

You shouldn't overextend your analogies. You might sprain something.

You must have missed the part where I explained how commands can be
re-issued.

And how often do you want to repeat the *exact same command* N times?
Really.

If I don't, I will make whatever changes are necessary before
re-issuing it.

I'm sorry, but if you're using emacs, then trying to get a window that
doesn't have "history and other features" is somewhat difficult.

We're not talking about a document window though. We're talking about
the equivalent of a GUI's one-line input field in a form somewhere.

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.

You're moving the goal posts again. The document windows may have all
sorts of nifty features, but that's not of much help when you're using
a command prompt instead of working in a document!

We have the luxury of choosing which to use, as best befits the task
at hand.

There is, of course, a shell /in/ emacs so your objections is academic
at best.

Ever heard the phrase "Jack of all trades, master of none"? A
specialist shell is clearly going to be superior to whatever launch-
external-command command might be found in some application that is
primarily something else, such as a text editor.

Perhaps, but sometimes good enough is good enough.

That's nonsense. Even if you could use two interactive apps at the
same time in terminal mode, you wouldn't be able to move data between
them very easily and certainly not with the precision control you get
with windows-style copy and paste. You can generate the data to paste
first, then decide where to put it, for example. With your tools you
have to go to where you want to put it and then generate it. If you
change your mind you then have to cut it and paste it elsewhere ... if
you even can; I take nothing for granted as definitely being
available, let alone in an easy or obvious way, in your tools. In
particular, you're stuffed if where the data goes depends on what it
is, and what it is isn't predictable in advance -- you launch some
process, it returns a result, and the result goes, say, in the
appropriate one of 26 sections labeled A-Z based on what letter it
starts with.

Results typically go to stdout and get read into emacs by way of
stdin.

Also, specifying everything in advance is problematical in many cases.
You do it essentially blind, rather than with ongoing feedback, which
can make things MUCH easier for some types of tasks. Especially if the
second parameter you input depends in some complex way on some complex
function of the first parameter. With my tools, I could use something
that runs interactively, and then I enter the first parameter, see the
thing that's a complex function of that parameter, decide on the
second, and type the second; you need to mentally compute the complex
function and enter both parameters, then hit enter and pray you didn't
get it wrong. Once again, in particular, you end up doing work the
computer should be doing (and indeed, that the computer ALSO does, so
there's duplication of effort too!).

If you're doing stuff this complex (building 3D-scenes for ray-tracing
perhaps) then, certainly, use a custom tool.

There is, of course, a development environment in emacs and you can,
of course, write as much lisp code as you desire. Moreover, you can
happily store such programs in whatever files you wish.

Yes, but every time you want to do much of anything? That's like
swatting a fly with a tactical nuke.

If all you want to do is swat a fly, then it would be unwise to start
a nuclear development programme for that purpose. So we generally
don't.

I do not attack you. I respond to you. There is a difference.

An attack is one type of response, and any response that suggests that
I'm either mad or an idiot certainly qualifies as an attack.

I do not consider that such types of response dominate my posts
however. They're more like seasoning.

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