Re: Great SWT Program

In article <1194730838.672688.213270@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<bbound@xxxxxxxxx> wrote:
On Nov 7, 8:05 am, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
If it's something you intend to use a lot, you'll persist it in your
.emacs file or somewhere else of your choosing.

Special bindings for editing a single file? Besides, what would they
actually be associated with? The file name I suppose?

That is something you would want to decide on a case-by-case basis.

M-x local-s<space><space> e insert-k<space><space><enter>

Ooo ... kay? That is definitely cryptic and unobvious and I don't
think any amount of man page reading over any amount of time is likely
to make it obvious that this is supposed to do, or easy to
remember. :P

It's certainly easy to /do/, which is rather the point. It's
interpreted by a computer and not by a human, so it being hard to
interpret is irrelevant.

There's obviously a whole damn language in there with very odd syntax
rules, semantically significant whitespace, and semantically
significant line noise.

This is a statement based on fundamental lack of knowledge as to what
is actually going on with the above command.

Even if that were the case, then you'd just use the scrollbar. I don't
see the conflict here.

Text-mode tools were the things under discussion, remember?

I am discussing emacs, which does support a scrollbar when running in
windowed mode.

I don't know why you'd want to make a graphical port of a graphical
program. It seems like a strangely masochistic sort of activity.

I'm talking about a graphical port of emacs, a text-mode application.

This appears to be based on a fundamentally flawed understanding of
what emacs is.

I don't know why, but you seem to be persistently using terms
differently from the rest of us.
buffer -> document

Close I suppose, but not quite.

emacs -> graphical port of emacs

The code base that is used for emacs these days is graphical - and has
been for the last couple of decades.

??? -> emacs

I rarely use three question marks in a row so I don't know what this
is supposed to mean.

C-x -> Ctrl+x

Yes.

M-x -> I'm not sure; alt x? Not that it matters.

Meta-x

If you're familiar with the software, you won't expect it to cut
something just because it's highlighted.

You're not making sense. Highlighted means "this is the selection",

It does not. All it means is "this is highlighed because I want to
draw your attention to it".

which means "this is what cut, copy, and the like should operate upon
if used right now". That's a fundamental part of the language.

Not /the/ language, but /a/ language. And it's not the emacs language.

Using
it incorrectly is just as damaging and trouble-causing as using
English words incorrectly;

People don't mind it very much that I use English words incorrectly
while speaking Norwegian. Likewise, the words of the Windows language
are largely uninteresting when working with emacs.

[meaningless hyperbole snipped]

You can configure emacs to highlight the selection if you really must
have this sort of visual feedback. This has no impact on what gets cut
or not - it's just decoration.

It's NOT "just decoration", it is a key piece of communication between
the software and the user.

It's unnecessary clutter. I /know/ what I started doing two seconds
ago - there is not need to scream it out at me.

That you can configure it to tell the truth
doesn't absolve it of being, apparently BY DEFAULT, configured to lie
to the user, or even of being capable of being configured to mislead
the user at all.

It's not going to mislead an educated user.

I never did such a thing. I believe it is you who have become overly
indoctrinated with the "if it's inversed, then it's a selection"
paradigm. This doesn't hold in all software, and it certainly doesn't
hold in emacs.

Misusing visual highlighting to mean the wrong thing

It is not the "wrong" thing. It /would/ be wrong in a typical Windows
app, but that's not what emacs is.

So C-w is not "cut" anymore? Now what is it instead?? :P

[snip long and complicated stuff]

See? This is completely unusable software. Nothing works in a stable
way; everything has weird special cases; there's no way to get
anything done without spending more of your time RTFM than actually
doing your fucking job. :P

Training is a one-off cost that will pay off hundredfold throughout a
career. It is therefore irrelevant to the discussion.

And yet, despite the mindboggling complexity put in its way by the
very forces of the universe, it does.

"ex" does not match to the end of "extend" unless you completely
redefine the matching rules so that "e" in the query matches "n" in
the target and "x" in the query matches "d". :P

You still do not understand how C-w works in incremental search. This
lack of comprehension is in itself rather damning for the criticism
you attempt to direct at it further above.

C-w made it complete the word that was started with the "ex".

Complete WHAT word? There are a ton of dictionary words that start
with "ex", including, for example, "examine" as well as "extend". It
can't know which one of those you want to search for, nevermind if you
don't want any word that it has in its dictionary at all...

The next one, of course.

Nothing in your postings has convinced me of anything except that that
software is even harder to use than I'd originally suspected, and
requires some sort of oddball talent with memorization to use
effectively.

It /does/ require such exotic mnemotic talents as "remember what you
started doing two seconds ago" and "manage to keep track of what
you're trying to do for more than two breaths at a time". Presumably
this /could/ be taxing for the ADHD generation I suppose, but then
these are unlikely to become programmers in the first place.

Training is unnecessary. People can use my preferred tools quite
efficiently with a minimum of training.

It has become abundantly clear over the course of the discussion that
the only reason you hold this belief is that you are horribly
inefficient in the first place. When you actually need to move your
hands about to type letters - and don't even see why this would slow
you down - you have more fundamental issues to resolve before the
emacs user interface is going to do anything for you. Of course the
mouse seems like an efficient tool for you - indeed, using the mouse
to type on an on-screen keyboard would probably be about as good for
you as your actual typing style is.

That people cannot use your
preferred tools AT ALL without a considerable amount of training is a
problem with your tools, not a problem with people.

It is something to overcome, certainly. But it is far from an
insurmountable task.

False positives are not a problem. That are easily skipped in search
of the true positive.

Except that skipping them a) takes extra time (which becomes a problem
if there are very many)

If there are very many, you typically either refine your search or
else adapt a different strategy.

and b) screws with the behavior of backspace,
as I recall you claiming.

Your failure to understand the backspace function doesn't make that
function any less useful.

It's not as fast as flicking the scroll wheel or otherwise using the
fucking mouse.

Then you do that.

OK. I claim victory. End of thread.

Hey - I claim ice cream! Start of yumminess!

But by hypothesis "mon" was not enough. What now, wiseass?

C-s

Why not page up and save yourself some trouble? (Under the hypothesis
that occurrences of "mon" are too numerous to sift through the false
positives in a reasonable amount of time.)

Then you do M-v

It is certainly possible for a GUI to be poorly designed. But a well-
designed GUI beats the socks off any text-mode interface it's ever
been my displeasure to try to use.

This appears to be at the crux of the matter - you have tried to use
emacs, but you failed. This experience therefore holds very little in
the form of useful information.

Assuming there is a "the" other window. Usually there isn't because
most application developers like to put their application in a single
main window.

If there are sub-windows instead you use ctrl-tab in place of alt-tab.
There's usually also a Window menu in either case; see above.

MDI was discontinued by Microsoft a number of years back and Ctrl-Tab
has been an unreliable manner of switching between different documents
since.

And the example was of someone who did /not/ follow the expected
pattern of usage.

That's not my fault, and it's not the GUI's fault. At least someone
unfamiliar enough with the GUI not to follow the normal pattern of
usage still gets their work done, albeit more slowly;

Exactly.

someone
unfamiliar with the extremely complicated pattern of usage of emacs
(your latest examples read like stereo instructions!) will get nothing
at all accomplished.

They will be trained in its use of course.

It means you're overdue for today's dose of Thorazine, that's what it
means. :P

You really need to do something about that drug fetish of yours.

And you keep insisting that properly formatted source code is tabular
data, so the connection is obvious.

No, I do not; you're lying and putting words in my mouth here, which
is very rude. Don't do it again.

And now you're saying elephants /can/ actually jump. Prove it!

For proper formatting of source code you use two things: tab and your
IDE's auto-indent.

And, of course, C-x r k, C-x r t, C-x r y, etc.

I have already agreed that training to use emacs is non-trivial.

That's putting it mildly. It obviously takes years to master, to judge
by the arcane stereo-instruction stuff you've been posting lately.

Depending on what you mean by "master", of course. Truly mastering
emacs is probably a futile endeavour.

/Damn/, I'm fast.

*** you, liar.

You seem to be taking this very personally.

If I get too many false positives, I will tend to choose other means
of navigation.

OK, then. I claim victory. End of thread.

Yay, I claim platinum rings for everyone! Start of rejoicing!

The search query appears in the mini-buffer, but the cursor remains
with the search hits.

Then how the hell are you supposed to edit the search query?!

I described this earlier, but you failed to understand it.

I
thought that was the big advantage -- editing the search query on the
fly.

It is.

Now you're telling me that the insertion point will be in the
document, which just means you can edit the document before hitting
next match.

You cannot. You must terminate the search in order to start editing
the document.

Probably only for lack of having trained in something better.

Bull***! Keyboard only can't possibly be superior to multiple input
options,

Your keyboard typically has in the order of 100 different input
options.

and a thin drool of visual feedback can't possibly be
superior to rich and detailed visual feedback.

Detailed doesn't hold a candle to useful though.

There are a number of ways to define the start point of a
selection. The most direct is C-<space>.

Ugh ... ugly.

I will go with ugly and efficient over pretty and inefficient any day.

Whenever you start an incremental search, the start-point (a.k.a the
mark) is reset to the start of that search.

So much for selecting using search to find the second endpoint, then,
if doing so will disturb the position of the first endpoint.

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


Hah. I call your puny mathematics and raise you fiteen years of
experience in the field.

Mathematics is unassailable.

When used properly, perhaps.

If you claim to have "experience in the
field" that contradicts it then I claim you're lying. Same as if you
claimed that your experience was that if you had five apples in a
basket, and threw in three more, then counted them, there tended to be
seven.

In the real world, of course, this can easily happen.

The more you write, the more convinced I am that I don't want to go
near it ever again. I won't even touch it with a ten-foot SCSI cable
now. Not emacs, anyway.

Strangely, I do not consider this to be a problem :-)

And, of course, we all know that all JBuilder is ever used for is
reading source code - never to write it.

I wouldn't know, not that any of this is relevant; JBuilder was never
under discussion. Changing the subject; how cheap.

How convenient it would be for you if you were permitted to just
black-list all the GUI software out there that contradicts your
ludicrous assertions. Unfortunately for you, however, JBuilder shall
remain a beacon of truth in your campaign to claim that incremental
search is useless for editing documents.

Of course, if I had never had the fortune to come across
emacs I never would have known what I was missing and might have been
in your camp on this issue.

More evidence that it's dangerously addictive. Like cocaine it
apparently makes people feel like they're Superman -- even while
actually slowly weakening them.

What /is/ it with all the drug references? Do you look around your
apartment every time you need a metaphor and just pick the first thing
that your eyes land upon?

That may be it of course - I may just be blessed by lady luck, that's
why I find incremental search so excellent.

More likely you're just plain nuts.

I do /like/ nuts, does that count?

Indeed. Most of the time, I don't actually know /where/, exactly,
something is in the document (but you apparantly do? Do you memorize
all your documents?)

I normally have a fairly good idea of where, proportionally, each
thing is within the document, yes.

I prefer to use a tool that does /not/ require me to memorize the
documents that I work on.

and so incremental search lets me go there from
just know approximately what is being said there.

I've just explained for the umpteenth time why that doesn't work when
it's really only "approximately" known.

Your explanation was strangely empty in the face of me having
successfully done this exact thing for fifteen years. You might as
well have explained to me how it is mathematically impossible that I
could ever have walked up a flight of stairs.

I touch type. I don't take "several seconds" to type a simple search
term.

We're talking a complex query, plus a bunch of weird extra chords, not
simply typing "ant" into a box or something.

Where is the complexity?

Bull***; I work plenty fast enough to begin with. I'm slowed down by
interfaces that make me reach for the help every five minutes, or do a
ton of typing to get anything done when it takes less time to left-
click once than it does to type four or five words and some control
sequences.

I also used to live in blissful ignorance back when I was programming
on the Commodore 64. I had the fortune to revisit it a couple of years
ago, and ran straight into the brick wall of realising that the C64's
default editor had no history, no scrollback, no selections, no
cut/copy/paste, no insert/overwrite mode (as such) and was altogether
a complete pain to edit text with.

Back in the day, of course, I didn't realise this and so I was quite
happy with it.


[insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

Yay me!

There is such a thing as information overload. Some things, you simply
do not /need/ the GUI to be shouting out at you, because you /already
know them/.

You find GUIs to be "shouting"? How strange. Have you discussed this
with your therapist?

What, you mean M-x doctor ?

Yes, I understand some people find percentages to be difficult.

They don't have to! It's still far faster and less mentally-burdensome
to visually assess a scrollbar than it is to compute mental arithmetic
-- even when that arithmetic is fifth-grade easy.

The scroll bar is more difficult because it covers a lot more space on
the screen that you will need to move your eyes across before you can
accurately assess how far down the knob is. The percentage holds that
information directly for you to read.

[insults deleted]

None of the nasty things that you have said or implied about me are at
all true.

Wheeee!

Pressing <enter> terminated the search. When the search is terminated,
of course, the hits are no longer highlighted.

So much for no easy deselection.

Deselection is entirely unnecessary. Adding the need to actually
deselect something is just overly burdening the user with
administrating state handling he doesn't need.

That's not an "extra" step, it's a necessary one.

For you perhaps. Not for me.

Never wanted to paste, modify, *then* submit?

It hasn't really come up. If it ever does, I'll think about it at that
point.

Are you saying that
if you paste into an emacs search prompt, it immediately does the
search and won't let you paste something in and edit it and *then*
search?

No.

Then an enter keypress is necessary to submit the search after all.

No.

[insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

I'm running out of joyous celebrations here . . .

But they will. Or are you such a language chauvinist that you deny
other nations the right to localize their fuel gauges?

WE'RE NOT TALKING LOCALIZATION, FUCKWAD, WE'RE TALKING TWO SUPPOSEDLY
ENGLISH-LANGUAGE LOCALIZATIONS ONE OF WHICH HAPPENS TO LIE TO THE
USER.

That may be what you're talking about. I, on the other hand, am
discussing emacs.

Or maybe with the steering wheel on the right side of the car, eh?

NOT A VALID COMPARISON.

Heh, no, of course not, because if you accepted it you would have to
accept that it blows your argument completely out of the water.

No. I am sorry, but the visible highlight and the thing that actually
gets cut being completely unrelated is completely unnatural and
abnormal.

/If/ your indoctrination comes from Windows, yes.

NO. ALWAYS. INHERENTLY ABNORMAL.

You seem to be projecting again. You need to understand that the MMI
paradigms you have been taught are only /one set/ of many possible
sets of MMI paradigms. Just because these are the ones you have been
taught does not mean that all others are inherently wrong.

No, we're talking about learning the interface.

One that lies? No thanks.

The lies only exist inside your head.

I have repeatedly agreed that GUI /could/, in a perfect universe, be
as convenient and efficient as I find emacs to be. But, again, in
practice they turn out not to be.

In practice they turn out to be quite good a lot of the time, and
moreover, actually usable by people that are not memorization savants
too.

"Quite good" just doesn't cut it anymore when you've seen "excellent".

What evidence would you require in order to prove that I do, indeed,
believe that?

Nothing will convince me of much of the BS you've been posting lately,
simply because it appears to violate the laws of physics more often
than not.

Or was it mathematics?

Then you do not touch type. Touch typing is all about holding the
hands still while only moving the fingers.

How awkward. You'll propably strain something, too.

This must be why touch typing is such a niche skill.

No, wait, it isn't . . .

No, actually it isn't. Someone less experienced than I might actually
read that and believe you. :P

If it is not, then you have just codemned the entire GUI standard that
you are spending so much time championing. If Files->Open File... is
/not/ easy to find for a mouse-fiddler, then Notepad is equally
byzantine to the beginner.

??? Non-sequitur. We were discussing learning all of those arcane
things in emacs, not using Windows and Notepad.

So let me try to explain again: if using File->Open File... is
impossibly difficult in emacs, then it would be equally impossible in
Notepad. Yet you praise Notepad for being so easy to use because it
has friendly helpful menus.

And yet, despite the utter impossibility, I keep posting to this
thread.

Memorization savant, or just plain liar; at this point I hardly care
which.

It must be very difficult to have the universe conspire against you
like this at every other turn . . .

I find emacs to be entirely consistent. Highlights, search, paste and
C-g all work the same every time I try them.

And C-w, C-y, M-y, undo(!), and backspace(!!) don't. And none of them
are consistent with *other apps*. Any other apps. At all.

I find that the work the same every time I use them.

memorize the whole document being worked on so that you can use search
for long-range navigation, and suchlike.

The only person in the world who thinks he needs to memorize documents
in order to work on them, is you.

I work on documents every day without exact memorization.

And yet, further up, you admitted to the opposite since you /have/ to
memorize them in order to use your preferred
jump-to-where-I-know-it-is type of navigation.

YOU are the
one who implicitly claims to memorize whole documents exactly, by
claiming to primarily navigate using methods that are not very
efficient unless you have.

Ah, no, I am the one who you claim has to memorize documents in order
to work on them. I never made such a claim.

But analogies are your bread and butter! The very core of your being!

Only ones that actually make sense.

You have yet to make one of that caliber though.

Ah, you mean, "only appear when the software thinks you need them" -
which turns out to mostly show them when you don't want them, or hide
them when you do need them.

I never claimed that GUI apps could not be badly designed. That's
hardly a valid condemnation of the whole idea of a GUI app, though.

I do not condemn the idea of a GUI app. In fact, seeing as emacs is
one that would hardly make a lot of sense.

[insults and BS deleted]

None of the nasty things that you have said or implied about me are at
all true.

And there was much rejoicing :-)

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

Quantcast