Re: Great SWT Program

In article <f9a37fe5-ca22-4274-9177-11826cc22d7f@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<reckoning54@xxxxxxxxx> wrote:
On Jan 8, 6:35 am, b...@xxxxxxxxxxx (The King of all Liars) wrote:
[snip]

Error: post too long. Do not post anything over 100 lines again.

Don't worry, it will dawn upon you eventually.

I have no problem with reading long documents. I do have a problem
with being held at proverbial gunpoint and forced to read, and respond
at length to, long documents I'd rather never have seen in the first
place.

You are the only one who is forcing you to do this: you are your own
prisoner.

(snip repeat of Twisted's ill-advised self defense policy)


You failed to shut up. You are therefore a liar. In fact you are the
King of all Liars.

Another inscrutable conclusion from the land of the Twisted, I see :-)

(Speaking of lies, how did you convince your news posting software to
lie and claim that you only took 22 minutes to compose this
monstrosity? Or do you actually get that big a speed boost by simply
trimming quoted material and spewing nonsense without even thinking
about it, thereby saving the time normally spent thinking and
considering one's responses? It would explain a great deal if all your
posts are rattled out without a single thought ever entering your
empty little head!)

I shall leave this as an exercise for the Twisted.

I certainly use emacs a lot, but that was not what we were discussing.

We were discussing what you use as NNTP client.

And also what I am using to actually write the posts.

You imply that it's
emacs,

It certainly does /one/ of those two tasks.

then claim that it's not

It does not do the other one.

, then claim that it is, then claim
that it's not, all the while continuing to imply that it is ...

Meanwhile, you fail to understand how the two tasks could ever be
separate at all.

Hrm, no answer.

Of course not: you deleted it in your reply.

No. I deleted something, but it was not an answer.

Well, you certainly found it embarrassing enough that you concluded it
was necessary to remove it from your reply.

The emacs mini-buffer also provides functionality that is
[irrelevant]

Compare status bars with status bars and other things with their
equivalents, please.

They aren't equivalents. This remains your single most serious problem
wrt to understanding what is going on in emacs.

You have repeatedly conceded in the past that the enter key can do
different things in different modes in Windows apps. Emacs is no
different.

YES, IT IS. Enter in a multi-line input box in Windows apps ALWAYS
inserts a newline, without fail.

Not necessarily, no. If, for instance, you have a multi-line list
input within a dialog then enter might move you to the next line after
editing the first one, or it might fire the default button.

It's a standard so graven in stone
that they considered it too obvious to explicitly include in the CUA
standard. :P

Ah, another admission that this isn't actually in the standard. Please
keep them coming! :-)

Enter in a single-line input box will often submit something or
otherwise do something. This also happens in emacs (and at command
lines, which are basically single-line input boxes), and I don't
complain that it breaks standards there. It's when hitting enter in
the big rectangular array of letters in the window of a text editor
does not behave as a normal computer user expects it to do in that
circumstance that a red flag gets raised.

Well, for a "normal" Twisted user, sure.

I am referring to the abnormal behavior, in emacs, of C-x, C-v, C-c,
shift-ins, ctrl-ins, and ctrl-del, idiot.

Not to mention the abnormal behavior, in emacs, of selections.

There is nothing abnormal with any of those in emacs, of course.

They are awkward to use primarily because they are incredibly less
efficient than what emacs is.

Bull***. They are awkward to use when you are currently trained on a
different UI pattern. It's quite symmetrical.

This doesn't actually bother the several hundred million computer
users that are mental savants, you see. And, no, it is unlikely that
the entire software development world will start writing their UIs
just to humour yourself.

If what you said were true, I'd find them awkward to use and keep
moaning and asking if anyone knew of an alternative.

Of course not. You do not expect an efficient UI because you are so
inefficient in the first place that such a UI won't actually do
anything for you.

Everyone would
find them awkward to use. Nobody does, except for people like you that
have trained extensively on crap like emacs. In fact, everyone trained
extensively on emacs finds emacs less awkward and Windows apps more
awkward, and everyone trained extensively on Windows apps finds emacs
more awkward and Windows apps less awkward.

And, of course, people who are trained extensively on both tend to
find Windows apps to be the more awkward. Which is rather the point.

It's quite clearly
perfectly symmetrical.

Sure, the irrelevant cases may be symmetrical. While that may be very
pretty and so appeal to you it still has no place in this debate.

There's one or more Windows ports, but they suffer from the
deficiencies of emacs in general AND the deficiencies of non-native
ported software. In particular, they are not (native) Windows apps.
Even if you count them as "Windows apps", as I said before Windows
apps are easy to learn "for the most part". Ports of emacs being among
the exceptions implied by that "for the most part".

The parts of emacs that you need to do the tasks that Notepad lets you
do are as easily accessible in modern Windows Emacses as they are in
Notepad.

And equally hard to *un*learn, no doubt.

If you don't use it for a while, it unlearns itself eventually.

How long does it take to fully detox?

Are you on the drugs again now? At least you're thinking the Right
Thoughts this time. Good luck to you with getting detoxed!

For people who need something more powerful than the little thing with
a wooden handle and funny-shaped metal head, however, training may
very well be in order.

Irrelevant. That's comparing text editors and IDEs, or text editors
and word processors, or text editors and spreadsheets, or whatever
(depending on the needs).

No, it's comparing text editors and emacs.

Carpenters with nails to hammer in use a
hammer. Naturally, the smart ones use other tools for different jobs,
such as screwing in screws. But for hammering in (and removing) nails,
a plain old normal hammer suffices and requires little training. A
fancied-up one with no obvious way to hit or yank a nail but six
thousand dials, knobs, and switches, an AC adapter to power it,
batteries in the handle in need of constant replacement, and a 500-
page manual won't see much uptake.

Nor would emacs, but that isn't the point either. For those few that
/do/ need the power tool, the power tool is obviously the tool to
learn.

Most likely, you're thinking of things like a carpenter's hammer
versus a jackhammer versus a sledgehammer etc.; in which case your
recommending emacs for general-purpose use by the population at large
is, *at best*, comparable to recommending that carpenters everywhere
start hammering in nails with a pneumatic jackhammer.

You need to learn to recognize it when your "analogies" break down.
Hint: this happened immediately above.

Doubtful. They probably have a nice slick modern computer interface,
except for small stations with poor budgets, which will have a bunch
of VCRs and tapes and some kooky filing scheme for the latter, plus a
cable-splitter with an eight-way switch somewhere. :P

And, of course, a million functions that they need to be trained to
use.

Nonsense. Insert tape, put eight-way switch in proper position, push
play.

I see. So we can add "TV stations" to the list of Twisted's
incompetencies.

I didn't say anything about sound studio professionals, idiot. I was
discussing users of mp3 players.

[insult deleted] I am recommending emacs for professional users?

You were recommending emacs for "everyone who edits text much",
***!

No, "a lot".

YES, IT IS!

Hint: when you feel the need to shout, it's because you're wrong and
on some level you are aware of it.

Must I spell it out?

Well, at least spelling is one thing that you are proving reasonably
competent at.

* Is the user interface intuitive?
Failed: emacs' broken backspace behavior alone is sufficient to
torpedo it in this category.

Emacs users tend to prefer usefulness to newbieproofness.

* Is it easy to perform easy operations?
Failed: emacs requires two weeks of training+ before you can
become productive at all.

Of course not. For anything that Notepad does (except log file
support, as noted earlier), you can access all relevant functionality
from the menu bar.

* Does the software give sensible error messages?
No. No Unix software gives sensible error messages.

Argumentation from prejudice now? Who do you think you are going to
convince with this?

* Do widgets behave as expected?

The widgets do, of course, but emacs rarely uses the widgets of the
windowing system. Most notably you will see them in the main
application window decorations, and you will also be able to get
native file dialogs.

* Is the software well-documented?
Unix-heritage software in general ranges from undocumented, to
(...)

Argumentation from prejudice got shot down about 14 lines ago. Try
again.

* Is the user-interface self-explanatory/self-documenting?
No unix text-mode tool qualifies here either;

Ditto.

+ Bent himself gave the figure of two weeks for the duration
of emacs training for the basic use of emacs in an earlier
post. This estimate is, if anything, overly optimistic.

Again, your idea of "basic use" is different from mine. For
Notepad-level use, you just use the menu bar as you are used to in
other Windows apps. You'll be up to speed within seconds using those.

Two weeks of training lets you use a number of emacs' more powerful
features, including a great many that you have repeatedly expressed
are so amazing they must necessarily be impossible.

Liar. King of all Liars. See above. You try to claim that emacs is
"usable" for everyone now simply because they slapped a GUI on some
port or another.

It has all the menu items that you need for basic use so if you know
how to use a Windows menu bar, well, there you are.

There's alsohttp://www.useit.com/alertbox/and the Unix Hater's
Handbook and a whole host of other references that agree with my more
general points and, fairly often, specifically with my criticisms of
emacs and/or my criticisms of vi.

[accuses be of bias]

Who is be?

These contain factual information.

Even if they do, that still does not mean they are unbiased.

As near as I can figure, modern
Unixes have mostly fixed some of the areas of reliability problems the
latter documented. The usability problems, on the other hand, appear
to have hardly improved;

Apparently, these people never tried OSX. Of course, they wouldn't,
because they are obviously biased and OSX would completely sink their
arguments.

on the text-mode side they are more or less
unchanged, and on the graphical side we now have crawling horrors like
CUPS.

In the meanwhile, CUPS works just fine for those who have not made it
their job to actively hate it.

[calls me a liar]

No, you're the liar, King of all Liars.

I really thought you were going to do something more original with
this than just make it another piece of boilerplate.

But that's just me I suppose: ever the optimist . . .

(Something having been tweaked since then is irrelevant; it's the era
of origination. The only modern stuff with origins that old seem to be
the mouse and keyboard. Modern UI paradigms seem to date back to the
late 80s or so.)

So you hate IPv6 too then.

More putting words in my mouth? I never said this. I never implied it,
either. I haven't been discussing wire protocols at all; I've been
discussing UI.

You've been trying to convince us that the era of origination is the
final gauge as to how good something is. I'm just piercing that
balloon for you.

* IDE-type features (use something designed for the job, like
NetBeans);

[snip pointless aside]

We are discussing its use AS A TEXT EDITOR.

I am discussing all of emacs' different use cases. That you want to
limit it so that you may better defend your ludicrous claims is
understandable but I am not going to get away with this.

If someone needs an IDE
they can get one with a proper UI like Eclipse;

Or emacs, of course, if they prefer that.

if they don't they can
use a text editor.

Like, e.g., emacs.

In neither case do they "need" emacs to get the
functionality they need.

Of course not. They may, however, find that emacs is the better choice
by far in a great many cases such as this.

* Features for dealing with tabular data or other oddly-formatted,
non-
code data (use something designed for that job, like a spread***);

[snip pointless aside]

This is ridiculous. I'm pointing out that emacs provides *nothing*
that is a) useful and b) impossible to get by using modern tools with
nice Windows-type CUA-compliant UIs.

Again, that is entirely beside the point. Emacs lets you do a great
many things very efficiently and within the same UI. This increases
your efficiency considerably compared to having to obtain and run
multiple different apps to achieve the same set of capabilities.

It may be that no Windows *text
editor* provides all of this crap, but it is not true that Windows
software in general fails to provide any of it that's actually needed.

My main argument concerns itself with efficiency, not with presence or
lack of capability.

Except the modern replacement is more often than not considerably less
convenient and much less efficient than the emacs method.

No, it is not. It may *seem* that way to someone untrained in the new
method, of course, but it isn't really.

I am sure it might, but you are veering off on a tangent again here.

It's just different, and in
some cases *more* efficient but different, and it takes some getting
used to, that's all.

Windows apps generally don't "take some getting used to" since they
all behave pretty much the same.

Such as emacs :-)

No. Emacs lacks a "just as easy to use UI".

For basic text editing, emacs is quite easy even for the beginner.

Balderdash. See all the stuff I wrote above AND earlier in this
thread.

Which, of course, remains as erroneous as ever.

Certainly, you can throw everything but the kitchen sink into one big
steaming pile and have a bloated feeping creature.

I wouldn't recomment this though.

Then why have you been recommending it to "everyone who edits text
much"?

You mean - why did you create this straw man and why do you think that
attacking it time and time again is going to convince anyone?

My claim was that people who edit text a lot can benefit from learning
emacs. I have since had to refine it as I originally made the
erroneous assumption that your vocabulary would be that of an IT
professional. I now tend to talk about professionals who edit text a
lot, or I point out that your "a lot" is a drop in the ocean compared
to the "a lot" of an /actual/ computer programmer.

Meanwhile, I can
install only what I need in the way of tools narrowly specialized for
specific tasks, masters of one trade instead of jacks of all. With a
nice modern standards-compliant UI on each.

Since disk space [snip remainder of irrelevant digression][nonsense
and implied insults deleted]

Wrong, and none of the nasty things that you have said or implied
about me are at all true.

Meanwhile, what I said above has gone unaddressed (and thus
unopposed).

You only think that it went unaddressed, presumably because of your
lack of understanding of very basic computer theory.

(Why on Earth would I need to alt-tab between them all? If I'm doing
job X I'll use the tool optimized for job X. If I'm later doing job Y
I'll use the tool optimized for job Y. When doing job X I won't mind
the lack of "job Y features" in the "job X tool", and vice versa.)

Meanwhile, I switch back and forth as I see fit.

So do I. If I have both jobs on the go then I will switch back and
forth if I need to. Yes, using alt-tab -- got a particular problem
with that keypress? You'll have to do something to switch back and
forth too, only it won't be as easy or as pretty, no doubt.

Ah, so you /do/ alt-tab between them. Well, then I suppose you are in
the best position to answer your own question above: "why on Earth
would I need to alt-tab between them all".

And, moreover, considering your inefficient tools and typing
style

My tools and typing style are quite efficient, TYVM.

In your mind they are, I am sure.

Your opinion of
them (an ignorant opinion, at that, since you obviously know very
little about either) does not change the facts.

You have revealed their shortcomings repeatedly in this thread. Every
time that you revealed some new little fact about your typing style, I
have found myself in initial disbelief that a "programmer" would be so
untrained in the basic tools of his trade. Of course, a while back it
became clear that you aren't actually a programmer after all and so
this particular bit of cognitive dissonance resolved itself quite
nicely :-)

It's not an emacs-replacement yet however.

No single application needs to be.

Perhaps not, but the eclipse team is clearly wanting this to happen.
Those of us who appreciate powerful tools can only hope that they will
succeed.

As I've already explained to Arse and Andreass, you are lying when you
mutate the quoted material in that way.

No, I am reminding readers of the context of the debate.

You're basically claiming that
I quoted something that I did not actually quote

Considering your "quoting" style it becomes necessary to reinsert the
context that you choose to hide.

, and therefore
telling a lie about me. And in the typical case, where the quoted
thing is furthermore misattributed or completely fabricated, the
dishonesty on your part is even worse, of course.

And now you're off on a tangent again.

I've been criticizing emacs for this very thing since the start of
this goddamn thread.

And yet you fail to remember that I agreed to the need for training
early on. It's almost as if you /want/ me to disagree with you: even
when I agree on something, you keep pretending that I do not.

If you didn't realize it, then your reading
comprehension skills are even worse than I originally thought.

When one of the first things I wrote in this thread was that emacs
requires some training, perhaps that would be exactly because I
realized that you would consider this a problem.

But then, logic was never your strong side.

I don't respond well to threats.

I have yet to see you respond particularly well to anything at all.
One single good response from you might give me enough of a shock to
induce a heart attack and since we know how dearly you want that to
happen - one can only conclude that writing good responses is just
completely beyond your capabilities.

But you're not doing that. You're misattributing things to me that I
never said. That is certainly extremely dishonest.

No, I am reinserting my own text - not text that you wrote.

Complex and counterintuitive to you perhaps

To any of those hundreds of millions of people.

That you have invented.

So, now I've somehow "invented" the entire population of the developed
world?

No, you have invented a few hundred million people that need emacs.
You see, there are unlikely to be that many. In the real world anyway.

Why you would invent them for Twisted-world is an intriguing question
though. Perhaps you are desperate for some make-believe people you can
pester and who won't answer back? :-)

I guess that makes me God. In Bent-world, that is. So, if I am
the God of Bent-world, does that mean I can destroy it in fire and
brimstone now and then will this thread finally end?

You could certainly try and then we will soon know.

A distinction in his use of it, but no distinction in WHAT IT IS as
far as the editor is concerned: a text file. He expects a compiler to
treat valid source differently from a shopping list. He expects the
jpeg decoder to understand neither. He expects Notepad or any other
text editor to treat them similarly, even if perhaps providing some
sort of syntax highlighting or other features when it detects a Java
source file.

[several nasty insults deleted; does not actually address the content
of the paragraph above]

Bent's capitulation on this point noted for the record. Point:
Twisted.

Ah, I can see I was being too technical for you again. Well, you must
learn to expect that sort of thing in cjlp I'm afraid.

Most immediately, he may want <Tab> to do different
things in source files than in text files.

Nonsense. Tab inserted at start of line tends to insert an eight-space-
wide tab in both. Which is exactly what I expect and what I want. In
both.

You might, but other users may not. Not least of all because Sun's
coding conventions specify different behaviour in Java source files.

He also wants a different
compiler to run when pressing the "Build" shortcut in a Java source
file than in a C source file.

Now you're discussing IDE features, rather than text-editing features.

In an application framework, the distinction between the two isn't
necessarily very clear.

Even so, this is a far cry from enter not inserting a newline in one
of the two file types, which would actually be comparable to the
behavior originally at issue.

Nevertheless, it is an example of a feature that sinks your claim.

Of course you seem to take an authoritarian view that whatever the
software does is automatically correct, and automatically standards-
compliant, because correct is defined to be what the software does and
the software's behavior is considered standard by definition, even if
it's a "standard" adhered to by only the one piece of software, or
even only adhered to by that one piece part-time.

Not as such, no.

Backpedaling noted for the record.

Again, when I distance myself from the claims that you have invented
for me that is not "backpedaling". It might be more accurately
referred to as "de-kooking" :-)

I, of course, take a user-centered view and prefer software that does
not force the user to "think different" and contort himself to jump
through its hoops, nor gives users any "my way or the highway"
attitude.

Indeed. Emacs is highly configurable for this exact reason.

This is nonsense.

Of course not. Practically every aspect of emacs is configurable by
the user.

Your emacs forces users to jump through its hoops
and unlearn and relearn even the most basic things,

Not at all - if the user prefers to use his old shortcuts etc. he can
configure emacs to do so.

such as what to
expect enter or backspace to do in various sorts of text input areas.

He can easily disable those features that he finds he has some
religious issue with, of course.

Nothing you've said indicates that these deep-seated UI flaws are at
all "configurable".

Of course not. I am not here to tutor you on emacs.

Even if they are, reconfiguring them requires
performing rocket science in the broken-as-designed unreconfigured UI
it has out of the box!

Because Twisted just really /really/ hates the menu bar.

Emacs is an outmoded, archaic POS with delusions of grandeur. Just
admit it and get on with your life instead of perpetuating this
pointless debate.

I do not find it pointless at all.

Emacs is written for ease of use, not ease of learning.

Nonsense. It's actually written for neither. Which would be easier to
use?

In general, emacs.

A backspace key that works as expected, or a backspace key that needs
extra presses sometimes?

You're off on a tangent again.

Separate keys for undo and redo, or a single key that moves sometimes
backwards through the undo history and sometimes forwards according to
some complex rule needing memorization?

You need to realize that "complex" in Twisted-world is considered
"normal" in the real world.

Selections that you can actually see, or selections that you have to
keep mental track of because of a lack of visual feedback about their
state?

If you want selections to be visible all the time, you configure them
to be so, of course.

I could go on, but I trust that three counterexamples are (two more
than) enough to torpedo your latest ridiculous claim.

Well, two of them were completely unrelated to emacs and the third is
easily configured to your liking so I'm afraid you were firing duds
again.

There is certainly no distinction
between "buffers" and "documents".

There most certainly is.

Not.

[insult deleted]

Looks like Bent's decided to stop arguing with me and start calling me
names again.

Because in Twisted-world, most valid arguments are of the type "Not."
"Too." "Not." "Too." "Not." "Too." etc.

In the real world we realize that when one participant is reduced to
just writing "Not." and nothing else, that in itself implies that he
has run out of defenses.

Did the user perform an action, an effect of which was for something
new to be open in the text editor?

Such as, say, a dialog?

Users don't care where it came from. They did
something that made the text editor sprout a new window with
particular content.

Possibly, yes.

Glad that's settled, then.

Again, there is nothing to settle here unless, again, the five of you
were having an internal disagreement over this one.

That's "opening something in the text editor",
even if indirectly.

"Something opened" is different from "I opened something". What you
get when you run a grep is comparable to a Windows dialog.

Yet if I'm the one who performed the UI action that made "something
open" then "I opened something", of course.

Of course not - you didn't explicitly ask for something to open.

Not that it matters anyway. When what opens turns out to be a dialog,
you do not actually expect it to behave as a regular editor window.

This sort of pronouns and causality stuff should be obvious, though,
to anyone who even passed kindergarten, never mind first grade. That
you have trouble with this stuff is a very bad sign, Bent.

And how many languages do you know? :-)

They expect hitting enter in the block of text in the main part of
a text editor to insert a newline.

It might help if you think of the grep buffer as a dialog box.

Nonsense. The grep buffer is an open document in the main editor
window. It is, indeed, quite clearly displayed as such.

As I said: it might help if you think of the grep buffer as a dialog
box.

Right now you are just embarrassing yourself.

It is, of course, entirely consistent in its handling of this.

Nonsense. You yourself said or implied all three of:
* Enter sometimes inserts a newline and sometimes does not in the
big block of text in the emacs window. Only subtle and cryptic
cues indicate which will be the case at any given time.

Yeah, subtle and cryptic clues such as the software telling you
exactly what is going on.

* Grep search can be done in two ways from within emacs.

Much more than two, I am sure.

* One way results in wonky enter key behavior and one does not,
so even "whether it's grep results" does not predict the
key's behavior.

If you run grep from emacs, it will always give you a grep buffer. The
only way to avoid this is to be explicitly trying to avoid it by
e.g. loading the results from a previously generated file.

This is about as crufty and inconsistent as it gets, folks!

So why did you add these features to your VanillaEmacs?

Of course it's not. It's *deterministic*, and in principle
*predictable* (given extensive training), but that's not the same
thing as *consistent*, not by a long shot.

Except, of course, that it is.

Your saying it does not make it so, King of all Liars.

It's *deterministic*, and in principle *predictable* (given extensive
training), but it's *not* consistent.

You repeating it doesn't make it any less bogus, of course.

[irrelevant quibbling over hypothetical details deleted]

Always, when confronted by a logically-unassailable argument, Bent
either does this or resorts to a pure ad-hominem argumentation style.

[insult deleted]

And there's the ad-hominem, right on cue.

Here's another hint: if you /do/ insist on taking any disagreement as
a personal insult, get used to seeing what you would then consider ad
hom attacks.

NO. IT'S WHAT *YOU*'RE DOING THAT IS RIDICULOUS, FUCKWAD!

[some irrelevant tangent about juice]

Bent's implicit admission of guilt has been noted for the record.

I am curious now: what record is this? Or is it a virtual record of
some sort?

(See half my posts to this thread for discussions of emacs' lack of
internal consistency.)

[nonsense deleted]

See above re: emacs' lack of UI consistency.

Which is still in error of course.

No, actually, it's quite common to find *modern* software that does
*not* second guess the user. If the user says "frog", either it jumps
or it pops up a dialog and asks "how high", and does not assume
sometimes that though the user said "frog" he *really* meant
"cheetah". :P

This, of course, /is/ second-guessing the user. Why on Earth would it
assume that a user saying "frog" actually wants it to jump? Wouldn't
he then have said "jump" instead?

I want the mechanics of operating the UI to be simple and predictable
-- the more so the more complex the task I'm doing, as I especially
want simple and predictable building blocks the bigger the thing I'm
building with them.

Emacs gives you this[snip]

The hell it does. Simple and predictable building blocks would include
single, separate, non-overloaded bindings for these:
* Undo
* Redo
* Backspace
* Enter
at a bare minimum.


Of course not - just because you cannot imagine how a UI with a single
undo-button and mode-dependant backspace and enter would work doesn't
mean that they are not simple and predictable.

My point is that it is more natural than any alternative for the
typical computer user due to past experience.

Which makes it not natural but learned.

and only a minuscule fraction of the total computer-
using population.

This, of course, is entirely beside the point.

No, it IS the point. You recommend they all use emacs.

I recommend that all of a minuscule fraction of the total
computer-using population use emacs? How horrible of me.

You recommend
incorrectly. I am here to correct you. Until you *stay* corrected.

With the average lifespan of my nation, this should take you about 50
years before I stop responding.

Nonsense. Only in Bent-world does only "very few people" send e-mail,
post news, post to web forums, post blog comments or have their own
blog, write homework or work-work documents of various sorts, edit
Wikipedia, compose and print letters by computer to send via snail-
mail, or do much of anything else involving text.

Your "a lot" is a computer programmer's "very little", I'm afraid.

Only in Bent-world
do the vast majority of computer users listen to and watch media, play
games, surf the web reading but not submitting anything, and maybe
fiddle with spreadsheets too, but do nothing else whatsoever.

And now you are inventing claims for me again. Of course, I don't
begrudge you all the fun you are probably having with that but I still
feel that I need to point it out when it happens.

It's quite relevant to putting you in perspective and demonstrating
that you don't speak for or represent much of anybody, nor are you a
representative sample of much of anybody.

Didn't you just get through whining about how much you hate ad-hominem
attacks? Well, here a mirror: (look five lines up) :-)

The only such groups with
any voice or influence at all are the nasty violent ones. What do you
think your chances are of convincing anyone of anything? Your
ambitions and certainties are laughable in light of these numbers. The
text-editing population of the world outvotes you by a factor of ten
thousand or more.

They do not

YES, THEY DO. See above.

Of course, you probably wish that they do.

Really? Do you see half of them using emacs? No. None of them? Almost
none? Yep -- almost none. Looks like the vast majority do agree with
me, if only implicitly.

[implied insult deleted] there is a difference between not having an
opinion about something and being against that same thing.

1. It would be in more widespread use if it weren't detested, as I
tried to explain before.

As you tried to assert before, anyway. And you are wrong because the
only way you could be correct was if people in general had an informed
opinion about emacs and not only do they not have this but they have
not even heard about it at all. They therefore do not detest it, they
simply have no opinion on it.

Similarly, while most people in the world have not expressed that
Twisted is a swell guy, this does not mean that they hate Twisted, it
only means they never heard of him and so have no opinion on the
matter.

They certainly won't benefit from emacs.

Most of them probably won't, no.

Glad that's settled, then.

Man, (men?) you have some serious internal issues there. Sure, I can
confirm to you all - Twisted, Bbound, Twerpinator, Reckoning54 and
even Nebulous - that most people will not, in all likelihood, benefit
from using emacs.

You /really/ need to be careful with those straw men you're building -
they are confusing yourselves no end!

(Also evidenced by his
earlier 180-degree switch to erroneously claiming that emacs' UI is
consistent.) Point: Twisted.

[erroneously claims that emacs' UI is consistent]

180-degree switch confirmed.

I never claimed that emacs is not consistent, of course, so either you
have invented some new claim for me again or else you think that I am
referring to the VanillaEmacs of your own design (which I am quite
sure is exactly as inconsistent as you were capable of making it).

Bent-world is not the real world.

If you turn this into a chant and repeat it often enough, perhaps you
will be able to hang on to your delusions :-)

Bollocks. Really cheap Dell *** may be that unreliable. Properly
constructed ones that are a smidgen more expensive, and not running
Windows, should do fine.

Not really.

YES, REALLY.

You really don't know much about uptime and nines do you? Here, I'll
do you a favour:
http://en.wikipedia.org/wiki/Uptime

At that point your main reliability issues are a)
a buggy update installed on all of them simultaneously, b) a security
breach, or c) an externally-originating network or power failure.

Or a hardware failure, of course.

Rare with modern hardware. Much rarer than just 10 years ago.

But not rare enough for use cases where multiple nines are needed.

And, of course, occassionally, "make these changes: . . ."

Copy config file over, make changes, copy back.

/If/ you don't care about the system crashing, sure. [rest of
nonsense deleted]

If copying files crashes the system, then you have bigger problems and
making the configuration changes can wait until those are fixed.

No, again you are betraying your ignorance of the uptimes
required. /Nothing/ can wait until /anything/ in such a system: it
/must/ be up /all the time/ or else there is hell to pay.

You'll have downtime when upgrading and migrating anyway.

This is largely unacceptable, of course.

And you'll have downtime when you have hardware problems or other
maintenance needs anyway.

Again, in a system of this caliber - no, you don't.

An upgrade may be opportunistically
performed when such a downtime happens anyway, and if scheduled
instead is still just one more, once-every-few-years, brief additional
downtime.

Your gung-ho attitude would quickly get you fired from such an
operation.

Colour VT100 is easily observed in virtual[snip!]

In other words, in an imaginary world.

[insult deleted]

Emulators that don't faithfully emulate what they are named after are
of no relevance to anything here, of course.

VT100 is of relevance, of course, since that is what was being
discussed. Your attempt to reduce also /this/ term to meaninglessness
long since proved your inability to defend your position and so I am
quite happy to leave this particular subthread where it is. Your
credibility on the issue has been damaged beyond repair anyway at this
point.

Show me a real, physical VT100 that has a full-color display and then
we can talk further about this. Until then, your fiction is of little
interest to me.

[insult deleted; does not exhibit such a VT100]

OK. You concede this point. Noted for the record.

I certainly concede that you are backpedaling frantically in order to
hide the impossibility of your original position.

But it does to display a proper GUI, of course.

[puts words in my mouth] colour and underlining

Don't ever put words in my mouth again.

[lies and puts more words in my mouth]

I HAVE NOT, LIAR.

What, not the king of all liars anymore? But you promised I would be!

Show me a real, physical VT100 displaying blue underlined clickable
links and I'll capitulate this point. Until then, I will not.

[irrational nonsense deleted]

I'll take that as a refusal, and therefore as a capitulation by Bent
on this point.

Yeah, we know how much you like to invent capitulations by now - no
need to say it explicitly.

There is no "VT100 protocol". There is a terminal emulation.

If you specify the "vt100" terminal, you will get protocols suitable
for the vt100 terminal.

Protocols called "sending raw ASCII down a serial line" equally
suitable for a bunch of other terminal types, including raw teletype.

No, not those protocols. /Actual/ VT100 protocols.

The data sent *using* the protocol may differ in the escape codes used
in that data. This is rather like how HTML and XHTML are not quite the
same, and depending on the browser a server might send a GIF or PNG
version of the same image, and things like that, all over HTTP.

Ah, so now you actually /do/ concede that VT100 supports colours and
underlining, albeit you do so in a roundabout fashion. Excellent. You
can call the different parts of the protocol what you like then - I
don't particularly care. I've had more than enough encounters with the
Twisted dictionary already.

Nonsense. Show me a physical VT100 displaying many colors at a time
and we'll talk. Until then, shut up.

Twisted, of course, has never heard of virtual terminals and so he
thinks that a terminal must necessarily be a physical device.

For this, the world pities him. And laughs a bit when he's not
looking. :-)

Note for the record: Bent capitulated on this point too.

Hey hey - you are being very inventive today :-)

There is a raw-ASCII-over-serial-hardware protocol. But that's not
what you were claiming existed. You are confusing things, analogously
to confusing HTML and GIF and JPEG with the HTTP protocol used to
transfer them all.

As I said above, I don't really care what sort of eccentric names you
choose to give the protocols in question. I only note that you are no
longer arguing against colour support in them and so I'm happy.

See above. What you can do by UNfaithfully emulating an ARCHAIC
display technology is apropos of nothing in this day and age.

It is, of course, apropos of whether or not you can have colour and
underlining in a VT100 virtual terminal, which was the claim you
originally attacked. Well, in the real world it is anyway.

Making your software present an interface through an emulated VT100
instead of your perfectly good nVidia GeForce 7800GT and then, because
a real VT100 (and thus a faithful emulation of a VT100) is too crummy
and limited, hacking both the software and the emulator to remove some
of those limitations, is rather like removing the engine from your
car, putting it in neutral, and taking turns to push it, then deciding
that that's too slow and hitching a team of horses to its tow-ring to
pull it (backwards!) through the streets. :P

Tsk tsk - still haven't learned to vet your analogies before posting I
see?

(And, yes, the VT100 emulator /can/ use a GeForce card for display
even if this /might/ be impossible in Twisted-world.)

Emacs has full support for true type fonts, of course.

It doesn't seem to have full support for dialog boxes.

It certainly supports dialog boxes. They are largely not desired,
however.

Nonsense. And nonsense.

You would know of course, not having touched an emacs since the 80s
and all.

Not even the
graphical versions you keep changing the subject to.

[snip nonsense]

Will M-x find-file?

Will it snip nonsense? Probably not - it will generally open a file.

Will anything else, for that matter?

Sure, the Delete key, for instance, would if used correctly.

Search won't
pop up a proper search dialog.

Search will hopefully give you i-search in all emacs distributions but
who knows.

If everything that could have been had
been upgraded to use modern UI paradigms

We intend to prefer efficiency.

, the mini-buffer would be
absent from a GUIfied emacs, or at least turned into a toolbar-type
poppable element like the Firefox search bar.

Ditto.

That first Mac was a beginning, but it was black-and-
white, with an early prototypical GUI lacking numerous features of
modern GUIs.

Nevertheless, that was when it began.

It was a prototype with only a *partial* implementation of a modern
GUI.

It was a consumer product. The Twisted dictionary notwithstanding.

One key element missing from this early prototype (one of many) being
color, as it just so happens.

Colour isn't a particularly important part of the modern Windows UI
standards anyway so it hardly matters.

Go away and don't come back until you have actually passed third-grade
reading comprehension.

That literally took zero time.

Calling that a protocol is like calling HTML (not HTTP, HTML) a
protocol, idiot.

HTML is more properly referred to as a markup language.

Exactly. Thank you for making my point for me.

Well, you seemed incapable so /someone/ had to do it.

If you define a "protocol" by "how a physical VT100 interpreted thus-
and-such" then obviously that protocol can specify, at most, shades of
grey.

No, the protocol can specify colours.

NO, IT CANNOT. See above, numbskull. If you define it as a "protocol"
whose specification is the reference implementation is a physical
VT100, then you find that every "color code" specifies a shade of grey
(or green or whatever) -- i.e. specifies luminance only.

I don't particularly care if you call it a carrot patch - the central
point is whether it is capable of specifying colours, which it is. As
you now seem to have stopped arguing against this original point of
contention, I can only conclude that we are in agreement on this.

It certainly doesn't delete characters when it's not supposed to.

And it sometimes doesn't delete characters when it is.

It always deletes characters when it's supposed to of course.

(For example,
if the user has typed a character into an input field, has not deleted
it, and the UI is in such a state that another typed letter will be
inserted immediately to the right of that preexisting letter, then a
backspace keypress while the UI remains in that state must -- MUST, to
obey relevant standards

The Twisted UI Standards aren't actually relevant to anyone but you,
I'm afraid.

-- delete that same preexisting letter. This
standard is violated, and it's a very basic standard going back
numerous decades

You started Twisting standards /that/ long ago?

, even when there was a user-input
character to the left of where a new one would be inserted if typed,
dip***!

If it's not supposed to be deleted, then, of course, it isn't.

But in the circumstances described, it IS supposed to be deleted, of
course.

Some times, sure, but some times not.

[misquotes me]

Do not misquote me again. Your post contained supposed "quoted
material" that did not occur in the post that you followed up to nor
summarize material that did. That is incorrect. Stop being dishonest.

I must have reminded everyone about how the debate had played out
again. Yes, you find this embarrassing, I know. No, I will not stop
doing so when I feel like it.

You misquoted me in an extremely nasty and dishonest manner. Do not do
so ever again.

Well, in a way, I suppose that quoting your text /is/ nasty in a way -
what you write is really very embarrassing to you. But I tend to
think: if he didn't want people to read it, he wouldn't have posted it
in the first place. This /might/ be rationalization on my part
however, there isn't really much reason to believe that you actually
realize what you are doing to yourself.

I proved you wrong. Admit it.

Errr ... no?

foo
foob
foobar
foob
foobar

C-s foob C-s C-s and you're on the fourth line.

Backspace x3 (actual behavior, according to you) -> query is "foo" and
you're on the second line.

No, you're on the first line.

No, you're on the second.

In your VanilleEmacs, perhaps, but not in real emacs.

According to the way *you* described the behavior, the first backspace
moves you up a hit to line 3, the second to line 2, when you're at the
first "foob", and then backspace again removes the "b".

No, backspace works like one level of undo for the search process.

Also, you said
that backspace both deleting a character AND moving to a different hit
would be crufty when I suggested it do that

No. You described something else entirely.

, and you don't believe
that anything emacs does is crufty,

This seems to be another invention of yours.

from which I can infer that emacs
does not move to a different hit when backspace deletes a character,
so the backspace that removes the "b" leaves you on line two.

You are inferring things again.

The only way it can actually end up on line one is if you lied earlier
about one or another of the things above -- one of the three backspace
presses *must* behave inconsistently with your earlier descriptions
for that to happen.

Or else if you've misunderstood or forgotten the previous debate.

My guess would be that you lied when you implied that backspace
*either* moves you *or* deletes a character but does not do both at
once because that would be "crufty".

Guess again. No, please do, it is very entertaining :-)

[at the "foob" hit on the fourth line]
Type a letter "a" -> query is "fooba" and you're on the fifth line.
AFTER one hit of "fooba".

This would not be desirable.

Yet this is the behavior that you have described for emacs.

No.

When I
asked if it jumped back to the first hit or jumped ahead (staying put
if possible) to the next hit when you added a letter to the query, you
said that it did not jump back. And seemed to think this desirable.
Now you say it isn't.

The search sequence you proposed simply would not bring you to the
positions that you claimed. Of course, your description was somewhat
ambigous so who knows what you really meant. If you describe the
process in a clearer manner I shall address it in more detai.

The age of the copy I used is irrelevant if they haven't changed the
backspace behavior, or any of the other egregious behaviors I've
criticized, since then.

[does not claim that the backspace behavior has changed]
[implied insult deleted]

Your capitulation here is noted for the record. I trust "how long it's
been since I tried to use emacs" will no longer resurface in this
debate as provably irrelevant.

Since the last time you used emacs was in the 80s some time, you
really wouldn't know, would you? Those of us who like to stay a little
more current than that, however, know all too well that the ancient
nature of your emacs experience (as well as your poor memory) puts you
in a terrible position to take part in a debate such as this.

You would lose the hit history, yes.

And I've showed that you will lose access to some search results
anyway, modulo the ability to wrap.

Losing the access to search results isn't really relevant though -
it's the loss of the search history that would be annoying.

What are you babbling about now?

I've already explained to you that you lose your place in the hits
with the *existing* system when you can't edit the query without going
all the way back to the first hit first.

No, of course not. First of all you /can/ edit the query without going
back, by adding letters to it. Secondly, when you want to /remove/
letters from it, it is more often than not because you found you want
to search for something else in the first place and so you /want/ it
to move backwards in the process. In the few cases in which this is
not the case, you will instead do an <enter>C-s to start a new
i-search from wherever you were standing.

If you don't want the search history to be lost, then you want
backspace to delete the character to the left of the insertion point
IMMEDIATELY and leave you on the current hit (which is still a hit for
the newly-shortened query).

No, this generally wouldn't interact well with the start point of your
search in those cases where it was carefully chosen (and when we're
talking source files, those cases pop up all the time).

This is the sort of awkwardness that emacs avoids.

It's not awkward;

Well, technically, it is not because it doesn't exist. The point is
rather that it /would/ be awkward if it /did/ exist.

No, it would not.

Well, for sufficiently Twisted values of "would not", I suppose.

backspace behaving weird is awkward.

It certainly would be.

And it certainly actually is. The designers of emacs really screwed
the pooch in this case.

Ah, we're back to VanillaEmacs again. But ... "designers"? Who did you
get to help you? Bbound? Twerpinator? Perhaps that's why see Nebulous
so rarely these days?

And if not being on the first hit for an altered query is awkward,
then the add-one-more-letter behavior you've described is ALSO
awkward.

No, that is most useful.

I will keep hitting you with these until you yield and admit that the
current backspace behavior is a) awkward, b) *gratuitously* awkward,
and c) can be seriously improved upon in a manner comparable to one of
the ways I described.

Well, as I said, we're probably talking somewhere in the region of 50
years.

This is the sort of childish, gratuitously defiant, three-year-old
sort of mind we're dealing with here. Someone please stick a gun to
his folks' heads and make them put him back in school. He should not
be spamming usenet with long, off-topic posts at this hour on a school
morning! (His latest ludicrously-long post was posted at 6AMish on a
Tuesday, according to its headers.)

What is it - sour that you cannot get yourself out of your bed at such
ungodly hours? :-)

I am, of course, describing the emacs *you* have described.

No, you are not. You have taken the emacs I have described and then
you have inundated it with features of your own in an attempt to
"understand" how it might work.

I have
simply taken your descriptions of a) things that happen (e.g. when
backspace is hit) and b) things that *don't* happen (e.g. backspace
both moving to another hit *and* removing a character from the query
at the same time, which you said would be "crufty") and examined what
these descriptions say will happen to a concrete example.

Furthermore, you have invented a bunch of things that I never
described but that you have thought necessary in order to have a
functional application.

If that
example does not match up with the actual behavior of emacs, then your
descriptions were faulty.

I have certainly not described every single feature in excruciating
detail. As I said: I am not your tutor.

Take your pick, Bent. At least one of your descriptions, or emacs
itself, faulty.

My descriptions are insufficient as a design description for emacs,
which seems to be what you think they were meant as.

If you're now claiming that backspacing the "b" jumps you all the way
back to the first "foo", even if there were twelve "foo"s before the
first "foob"

That is what /real/ emacs does anyway.

That is inconsistent with your own earlier description of its
behavior.

No.

So either you were lying then or you are lying now.

Or else you misunderstood it. Again.

Furthermore, it is crufty by *your* standards of crufty.

No. I really don't have standards of "crufty" as I do not use that
term except e.g. to throw it back in your face when you're being
inconsistent in its use.

Remember the exchange earlier?

Me: Why not have backspace delete the character to the left
*immediately*?
You: Because then you wouldn't be at the first hit.
Me: Why not have backspace delete the character to the left
*immediately*, *and* jump back to the first hit?
You: Have it *both* delete a character *and* move to a
different hit? How crufty!

Ah, I get it, you didn't understand the irony - is that it?
Heh. That's hilarious.

You see, you're the one who had difficulty internalizing the idea that
one single key could do multiple things at once and so when you
suggested that Backspace should do so I pointed out how crufty you
would find that to be.

Now you're claiming that it does this *anyway*. In fact, it clearly
has to either delete *and* move at the same time, which you called
crufty, or it has to sometimes not leave you at the first hit, which
you also called crufty. Looks like you get to take your pick of
cruftiness, Bent. :)

Yeah - you appear to be the crufty one in this case :-)

Get yourself a new irony subsystem already.

, then there's no reason for it not to do that immediately
if you hit backspace no matter how many "foob" hits you'd stepped
through, and have a different key perform the "previous match"
function.

Except it would be less useful.

No, it would not. It would be more useful*.

It is not clear how.

* Perhaps you're assuming that backspace is rebound to backspace
a character immediately, and nothing else is done, leaving no
"previous-match" command? Obviously there'd be some other key
bound to "previous-match" so this would not actually be a
problem**.

This is less convenient than having one single key to do both jobs
though.

** Perhaps you find it useful to have a "previous-match-if-there-
is-one-and-backspace-otherwise" binding. But there's no
reason not to have backspace simply backspace, and some other
key do *exactly* what backspace currently does in emacs!

Again, there is no need to add a gratuitous number of extra
keybindings for this. The current functionality works exceedingly well
and turns out to be exactly what people want.

Search for "foo", hit next-match three times to land at "foov", and
type "b", and you're on the last line, NOT the first hit for "foob".

Yes.

So much for typing a letter not suffering from the same "problem" you
claimed my proposed backspace behavior would have, then.

This isn't a problem of course, it is desired behaviour.

That's funny. When it would occur from my proposed change to backspace
behavior, it was "a problem".

That is because that was a backwards movement and in backwards
movement it /is/ a problem because it adversely affects the hit
history.

Yet when it will (and does) occur from
pre-existing emacs behavior, it not only "isn't a problem" but "is
desired behavior".

In the forward direction, there is no conflict with the hit history of
course so it's a non-issue. Moreover, it is desirable to have it the
way that it is because it's in the forward direction that you want to
be able to refine the search as you go.

Apparently, whether a behavior is "a problem" or
"desired behavior" to Bent depends less on what the behavior actually
*is* and more on a) whether emacs actually exhibits the behavior (in
which case it is "desired behavior")

This may, of course, /appear/ to be the case but that is coincidental:
emacs behaves in the manner that it does because it has been refined
towards perfection over several decades and so in very many cases it
proves that the most desirable behaviour just happens to be the
behaviour that emacs actually has. This means that in such cases, the
statement "emacs has it because it's the most desirable functionality"
is true but "it's the most desirable functionality because emacs has
it" is not.

or b) Twisted suggested it (in
which case it is "a problem").

Well, "it's stupid because Twisted suggested it" or "Twisted suggested
it because it's stupid" might both be true for all I care - it's not
really relevant.

Interesting. This gives considerable insight into the twerp's
psychology. Now if I only knew what shrink Bent was seeing I could
relay this fascinating information to him and thereby help him to
optimize Bent's treatment program. And maybe he'd finally be cured and
start leaving me alone.

Well, it is not /entirely/ abnormal (even if a little eccentric) for
people to be talking to themselves, but people /writing/ to themselves
and on /Usenet/ to boot - now /that/ is weird :-)

In i-search, having a combined "previous hit" and "delete last char"
key proves immensely useful.

If so, I have no objection to binding this to a key. OTHER than
backspace, which should simply "delete last char" with no questions
asked.

I don't really think the emacs dev team cares much what you do or do
not object to, I'm afraid. That being said, the source is available
and there's a wide range of configuration options even without it so I
am sure you can do such a change locally if you must.

There's no reason not to have a normally-behaving backspace AND a key
(some OTHER key) bound to the function that Bent claims is "immensely
useful".

Of course there is: convenience and efficiency are just two.

Then why not have C-s foob C-s C-s C-s backspace immediately leave you
with a query of "foo" and on the first hit for "foo"?

Because it would be less useful.

Useful but counter-intuitive and "wrong", standards-violating
behaviors are not actually all that useful, and are certainly not
desirable.

Useful often trumps "intuitive" in a professional setting, however.

Now imagine instead:

1) C-s foob C-s C-s C-s backspace immediately leaves you with a query
of "foo" and on the first hit for "foo"; and

Horrible.

2) C-s foob C-s C-s C-s XXX XXX XXX XXX goes to the fourth "foob" hit,
then backs up to the third, then the second, then the first, then
the first hit for "foo" with the query reduced to "foo".

Where "XXX" is replaced by the currently-unused binding of Bent's
choice, and more generally does *exactly* what backspace currently
does. "XXX" could even be DEL, since it seems you can't move left
inside of the query and use the DEL key for its normal job anyway.

Keyboards cannot be trusted to have the DEL key so this would be
unworkable even had the basic idea been a good one.

You objected to that before on
the grounds that backspace moving you AND deleting something at the
same time would be crufty.

I did not

Yes, you did.

No, you just missed the irony. Ah, the irony :-)

, so
being at "foov" above with a "foo" query and typing a "b" would put
you on line two instead of the last line.

This does not happen.

I know. I was just suggesting it as an alternative. But consistency
between modifying the query by deleting and modifying the query by
adding seems not to interest you much.

[nonsensical artsy-fartsy postmodernistic babble deleted]

You didn't even understand /this/? Oh well.

And meanwhile, in the real world, where facts are facts, the world is
not "socially constructed" but simply *is*, and Bent Dalager is a
raving loon ...

And trying to cover it up with wild speculations about the fabric of
the world. What is the Twisted coming to?

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