Re: Great SWT Program



In article <c2e59c13-3395-49bb-a4ff-19786ef0a5d3@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
<twerpinator@xxxxxxxxx> wrote:
On Jan 2, 2:17 pm, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
[snip]

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

You need to upgrade your natural language neural subnets. Normal
people generally have no difficulty reading texts of >100 lines.

But mine HAS to be. Yours could be much shorter.

Certainly, since I don't have an obsession about these things

OK. Either prove it by shutting up or admit that you're lying.

I am not sufficiently insecure that I feel the need to prove anything
at all.

If you
post anything exceeding 100 lines either in response to this post, or
dated after any response you make to this post or to any post I posted
on or after Jan. 5, 2008, I will announce that you were indeed lying,
loudly and publicly, and make reference to this King of all Lies of
yours in every subsequent response to any post of yours by referring
to you as the King of all Liars.

That sounds like fun :-)

Your credibility will of course go
directly into the toilet. No, wait, it's already there. It will get
FLUSHED DOWN the fucking toilet.

Ah, keep dreaming.

Your sociopathic amusement at other peoples' expense is not
legitimate. If you lose such amusement, tough ***.

You can easily take it away from me you know. (Well, no, of course
/you/ can't, but a normal person would be able to.)

Perhaps if you greased it, your shift key would pop back out
immediately upon release.

He said, apropos of nothing.

I see you've gotten it fixed now. Happy to be of assistance!

I also explained that by "modern" I meant, in that context, anything
widespread since about 1995 or so.

You /eventually/ fell back to this tactic after you realized your
original position was untenable in the extreme. This impresses no one.

I don't, of course, except when professional needs necessitate it.

Which apparently is all the time.

No, only very occassionally.

Yet you end every single post with "powered by emacs". It certainly
sounds like you use it, if not "all the time", then at least more
often than "very occasionally". (Note spelling.)

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

Hrm, no answer.

Of course not: you deleted it in your reply.

No, only the mini-buffer, if permanently displayed even when not in
use.

Much like the status bar in modern GUI software.

The status bar is in use whenever it has salient information
displayed. It's more comparable to the emacs status bar than to the
emacs mini-buffer, buffoon.

The emacs mini-buffer also provides functionality that is often
displayed in the status bar in Windows apps. Of course, it does much
more than this.

The user of a text editor does want enter to insert a newline.

Often, perhaps, but not always.

YES, ALWAYS.

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.

Except for a handful of nutters like you -- a drop in an
ocean of tens or even hundreds of millions of people.

The hundreds of millions of people who use enter to close dialog
boxes, you mean?

It's completely alien to every kind of UI
standard

Of course not - it is only slightly different than the Windows UI.

*sputter* Baloney! Poppy***! Balloonjuice! BULL***!!

You may want to stay off the balloonjuice while reading Usenet.
Sputtering balloonjuice into your keyboard is not advisable and may,
among other things, cause your shift keys to become sticky and
disagreeable.

I've seen some whoppers in my time, but this ... why in God's name
even try, when nobody who has spent so much as five seconds fiddling
with trying to copy and paste in emacs is going to fail to see that
for exactly the crock of *** that it is?

Emacs has a menu bar just like other Windows apps and it has a button
bar just like other Windows apps. Using these, even a novice user can
use it for basic text editing purposes.

That you do not actually /know/ this doesn't, of course, change facts.

This is what would happen if you *succeeded* and they became
proficient with emacs, resulting in everything that ISN'T emacs
becoming hard for them to use, because of course only one of emacs and
everything else can be easy to use at a time.

There is, of course, nothing to prevent a proficient emacs user from
using other Windows apps.

Aside from that they will, as you and blmblm do, find them awkward to
use afterward, the same way they found emacs awkward to use
beforehand.

They are awkward to use primarily because they are incredibly less
efficient than what emacs is. This does not mean that they are
/difficult/ to use, just inefficient in comparison.

As you have said many times yourself,
Windows apps are remarkably easy to learn for the most part.

It's emacs that isn't.

It's a Windows app, so by your own statements it must be.

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

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

And I have repeatedly pointed out, ever since this thread began, that
the very notion of a text editor requiring training to use is
ludicrous.

Of course not.

Of course yes. It's exactly as ludicrous as a hammer, as in the little
thing with a wooden handle and a funny-shaped metal head used for
hitting nails or removing them, requiring extensive training.

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.

Given
lots of perfectly adequate normal hammers and one weird one that can
do the job as well but requires all kinds of extra complicated
training to learn to use, after which your brain's so gummed up that
normal hammers AND screwdrivers, saws, and other such tools are now
all awkward and difficult to use, any carpenter who values his time
and sanity is going to stick with normal hammers.

That must be why we never bothered making steam hammers of course. No,
wait, we /did/ make those.

What if your TV came with a remote control that had a 600
page manual and required special training to use?

I am sure professionals in TV stations have /exactly/ these sort of
sets around.

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. Which was the point.

Would you prefer
a normal iPod or an mp3 player with forty thousand knobs and switches
but no obvious "play", "pause", "next track", or "previous track"
buttons?

Sound studio professionals do not tend to use mp3 as source streams,
so [insult deleted]

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

And you still haven't figured out that I am recommending emacs for
professional users?

User friendliness is ADHERING TO THE FUCKING STANDARDS NEARLY EVERY
OTHER APP IN EXISTENCE DOES.

No, user friendliness is presenting a convenient user interface to the
user.

Same fucking thing, moron.

No.

Cite 1: http://en.wikipedia.org/wiki/Software_quality

Wow - a URL. This must be a first for you. How did it feel? :-)

Pay especial attention to the section "The User's Perspective". In
particular:

* Is the user interface intuitive?
* Is it easy to perform easy operations?
* Does the software give sensible error messages?
* Do widgets behave as expected?
* Is the software well documented?
* Is the user interface self-explanatory/ self-documenting?

Notice that those are six of the eight points in the original. Emacs
fails on every count, of course.

Again with the hatred for menu bars and button bars.

Most "old-school" unix software fails
on at least the "sensible error messages", "self-documenting", and
"easy to perform easy operations" counts. Most Windows ports of unix
software, particularly originally-non-graphical such software, fails
on "do widgets behave as expected".

This is a meaningless statement since "most old-school unix software"
cannot be quantified.

Next is http://catb.org/~esr/writings/cups-horror.html -- here's how
to screw up usability even when slapping a graphical front end onto a
unix tool. Happens all too often.

This is still not relevant to the point you are trying to make.

There's also http://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.

Because "the Unix Hater's Handbook" /must/ be the best place to find
unbiased information about Unix tools. In Twisted-world.

If you're going to continue to attack me, denigrate me, call me names,
and viciously slander me for disliking emacs and publicly explaining
why, then you have similar bones to pick with Wikipedia

You do not understand the nature of wikipedia, do you?

Lying about where the insertion point
really is and crap like that certainly does NOT qualify as "user
friendly".

[insult deleted]emacs doesn't lie to the user

I've pointed out several situations in which emacs' behavior will
mislead any normal computer user who tries to use it.

You have not "pointed them out" so much as you have imagined them.

(Experienced
emacs users will know about the gotchas and won't be fooled, but this
does not matter when you've been recommending that a much larger
audience of lay computer users take up emacs.)

I have not - that has always been /your/ claim.

(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. Nice to know.

The only advantage it ever had over Notepad was a larger file size
limit that 64K, and Notepad hasn't had that limit for years, since *at
least* the debut of Windoze XP. :P

Plus, of course, the several thousand other features it has and
notepad lacks.

Features that fall into five broad categories:
* Of no practical use (unless you're really concerned about that Mayan
doomsday clock counting down);

You're the only one with a Maya fetish here. You would do better to
keep it to yourself.

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

The emacs IDE features are, of course, designed for the job.

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

Emacs is, of course, designed for the job.

* Features totally orthogonal to text editing, such as NNTP client
functionality (use a real newsreader or whatever); and

Emacs does, of course, have a real newsreader.

* Features emacs users use for generic text editing tasks but which
are
obsolete in a modern UI, the larger goal of the user being served by
scrollbar, a mouse action, the clipboard, or similarly instead
(learn to use the modern replacement for the archaic interaction
method).

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

If I want something more powerful than Notepad, I will use any of
several editors that are more powerful than Notepad and have just as
easy to use UIs.

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.
/If/ you don't hate the menu bar anyway, so you have disqualified
yourself.

If I need a regexp search I've got a programmer-oriented editor, with
a normal GUI and adhering to all Windows UI norms, that has such a
feature.

Certainly, you can probably obtain and run 100+ different applications
each with its own narrow focus, and then alt-tab between them in order
to obtain something reminiscent to the power of emacs. I have no doubt
of this. Meanwhile, I have this in one single convenient package.

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.

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 is essentially free when considering the size of
emacs modules, this is not an actual issue in this day and age. Of
course, I know that you are still stuck in the 1980s so you may feel
different.

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

I have no use for emacs

Of course you don't - you don't actually edit text a lot.

Actually, I do.

No, you just /think/ that you do. And, moreover, considering your
inefficient tools and typing style you don't even have to type very
much at all for it to /feel/ like an awesome amount to you.

find yourself some useful, modern tools to take the
place of emacs.

If there was one, I would certainly investigate it. As it is, however,
emacs is the only alternative out there.

In Bent-world. Meanwhile, in the real world, Eclipse development
continues apace

It's not an emacs-replacement yet however.

, there are rumours of a new version of NetBeans in the
works

Ooh, yeah, vapourware! Let's use that instead!

, and all sorts of other tools -- spreadsheets, newsreaders,
various-featured text editors, word processors, and so forth -- are
waiting out there for those with the Google-fu to find them.

You mean you don't actually have them yourself? I pity you.

No, normal people actually /understand/ this after [misquotes me]

Do not misquote me again. Your post contained lines prefixed with ">"
that did not occur in the post that you followed up to nor summarize
ones that did. That is incorrect. Stop being dishonest.

When you gratuitously remove the context that you are responding to,
don't get your panties in a twist when the more honest crowd reinserts
it.

Exactly.

Ah, a breakthrough at last.

I agreed that normal people need special-purpose training to use your
crap.

Well, still a breakthrough. I only said this several thousand posts
ago. That it's finally penetrated your ill-advised mental defenses is
a sign of good things to come :-)

Stop sneakily putting words in my mouth by dishonestly editing the
quoted material, fucktard.

Well, you are my tutor in this - I only follow your example. And, of
course, you're right: it's fun :-)

I've gotten mighty sick of Andreass, Arse
Vajhøle, and Tristram Ralph dishonestly editing quoted material in
ways other than trimming and summarizing it (generally by actually
adding quoted material in by hand), thereby lying about what I said,
or about what I quoted others as having said. Don't YOU start.

Reinserting necessary context is not considered dishonest on Usenet.
The only reason you don't like it is that doing so showcases your own
considerable flaws.

No, they will do very strange and wonky things.

Strange and wonky to you

Strange and wonky to any of the tens of millions of people (perhaps
even hundreds of millions) that fall under your broad criteria for
people you think will benefit from emacs.

The broad criteria you are referring to were invented by yourself.

(Picking on my choice of metaphors while ignoring the gist of what I
said is a sure sign of the desperation of a born loser about to lose
again. It should be some consolation though that you've lost to the
best of the best, a genius-IQ grandmaster of this particular variety
of argument-fu. :P)

You're in Twisted-world again. Here's a hint: don't post while you're
in Twisted-world. It just makes you look silly.

I never said that. But they might as well be, for all they behave
unpredictably in ways that depend on complex and counterintuitive
factors that in any NORMAL application would not be relevant.

Complex and counterintuitive to you perhaps

To any of those hundreds of millions of people.

That you have invented.

As far as the end-user is concerned, there is no distinction between
one text document and another

Of course there is. One may be his shopping list while the other might
be a Java source file. Clearly he is concerned about the difference.

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.

And once again you spot your own error. When this happens, it might do
you better if you simply not write the erroneous statement in the
first place rather than to write it and then immediately afterwards
pointing out why you were wrong.

He most certainly does not expect his text editor to bind
keys like enter differently for some of them, or any of the other
basic text-input keys or basic navigation/editing keys.

He certainly does. Most immediately, he may want <Tab> to do different
things in source files than in text 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.

-- they are all (or, at least, *should*
all be) the same as far as the software is concerned because anything
else is confusing and unpredictable.

Except when it isn't. Such as in emacs.

In other words, emacs violates the Principle of Least Astonishment.
Capitulation on that point noted for the record.

You are imagining things again. How you got this out of the above
remains a mystery, but I suppose that in Twisted-world, logic isn't a
requirement.

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.

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.

I prefer software that works with the user, is as easy as
possible for the user to learn and use, adheres to all applicable de-
facto UI-behavior standards, and adheres to the Principle of Least
Astonishment.

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

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

There most certainly is.

Not.

You are displaying your ignorace again.

They opened a text editor. They
opened something in the text editor.

In the case of grep, they didn't "open something in the text editor".

Except that they did.

No.

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.

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.

Now they have a block of text
displayed in the main part of the text editor. They expect such a
block of text in the main part of a text editor to behave in a certain
way.

[snip utter nonsense]

No.

How can "utter nonsense" have the reply "no"? Are you lowering
yourself to arguing nonsense now? Or did you just snip something you
found embarrassing and try to label it as nonsense? I know which one I
go with :-)

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.

If it does not, it will upset them.

Which is exactly why emacs does this.

But it doesn't. In fact, it only *sometimes* doesn't, which is
actually worse.

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

If it *sometimes* does and
*sometimes* does not, it will upset them more.

And emacs is very consistent about this, of course.

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.

If there is some arcane
rule by which what happens can in principle be predicted from the
source of the text, the phase of the moon, and the price of tea in
China

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

What, you mean - your analogy was absolutely horrid again?

, they will not be appeased -- they want simple and very
predictable, consistent behavior, such as "enter always inserts a
newline at the insertion point in the big block of text inside of a
text editor".

[snip some implied insults and irrelevancies about "IT
professionals"]

The discussion is scoped to "everyone who edits text much", remember?

No, "a lot". And that "a lot" appears to be a different "a lot" than
the paltry amounts of text you seem to think that it refers to.

THIS IS FUCKING RIDICULOUS!

So why do you keep doing it?

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

Have you sputtering balloonjuice into your keyboard again? You really
might want to wait with the juice until after you're done posting.

A single application doing everything differently from ANY OTHER APP
ON EARTH is not at all "standard"!

It doesn't, of course, do "everything differently from any other app
on Earth".

Except that it does. Well, *almost* everything.

Of course not. Most things are by and large the same, but it certainly
has more use of keyboard shortcuts than what the norm may be in other
apps.

In the case of text editors, this means that it pretty much has to do
anything that Notepad does the way that Notepad does it

Sorry, but Notepad doesn't define "the text editor standards".

I never claimed that it does. It does, however, exemplify the text
editor standards. And through sheer market share helps establish de-
facto standards.

It might "help", but that's not quite enough of course.

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

No one but you much cares about your own VanillaEmacs, of course.

Bollocks! Even such normally-dependable things as the enter key
inserting a newline in the big block of text inside a text editor
cannot be counted on inside emacs depending on its "modes".

Emacs is very consistent in [being inconsistent]

Indeed, emacs IS very consistent in being inconsistent.

And again you score a "victory" by redefining my claim for me. You
must be the only one who doesn't realize how desperate this makes you
seem.

I don't WANT software second-guessing what I might find "most useful".

All software does this so I guess you don't actually want any
software.

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, of course, if you bother to learn it.

Sure there is. In fact there are several, of which of course emacs
honors none.

Cue Twisted trying to explain how Alt-Tab is a very natural way to
switch between tasks.

Simple: because that's what people learn to do from childhood these
days.

Which only means that it is /learned/ and not "natural". Thanks for
making my point for me.

As I said, they look the same. The different "applications" look as
similar as a *single* Windows (or Mac or even X) application
displaying different *documents*

Just as you tell differnt apps apart by their names in Windows, of
course, you tell the different modes apart by /their/ names in emacs.

That's irrelevant to what I said. It's a subtle point, but even with
your awful IQ you may get it eventually. You see, there is ANOTHER
difference between apps in Windows, and that's that they look visually
nothing alike, ASIDE from their names.

Some do, some do not - this is not in any way a reliable way to tell
apps apart.

(The figures come from a *generous* assumption of 10,000 existing
emacs users and a *generous* assumption of only 100,000,000 people
that edit text frequently. But even with a whopping 100,000 emacs
users or only 10,000,000 people that edit text frequently it's *still*
going to start with 0.00. :P)

You are dreaming up numbers again - moreover, you are dreaming them up
based upon your own dreamed up claims.

[completely irrelevant drivel deleted]

I accept your concession of the above point. Point: Twisted.

Even if I had conceded something (which I didn't, of course), you
deleted it and so I wouldn't have after all.

Interesting strategy, that.

but normal people in the normal world are
remarkably quick to recognize a superior tool when they see one and
eagerly adapt such.

Think about that carefully, Bent, and about the fact that nobody
normal touches emacs with a ten-foot pole.

Quite many do, of course, use emacs.

But nobody normal,

But, then, in Twisted-world, nobody is normal anyway.

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

This, of course, is entirely beside the point.

Indeed. Now notice how nobody much has, in the real world, realized
any "advantages" or tended to "embrace" it.

Except, of course, they often do.

Yep -- all three of them. Okay, maybe closer to three thousand. Out of
millions upon millions upon millions. Which is more likely -- the
world is wrong or this tiny sliver of a minority is wrong?

What is most likely is that very few people edit text a lot and so
most people don't need emacs anyway.

There are
tiny tribes, the world's last hunter-gatherers, that are more populous
than you. Little dissident movements. Far-from-mainstream religious
cults. Terrorist organizations. The whole population of emacs users is
smaller than these pipsqueaks and twerps.

You are babbling now. None of this is in the least bit relevant as to
whether or not emacs is a powerful tool.

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, no, because they have never ever heard of emacs. Hence,
they have not "voted against it".

The set of all current emacs users is, indeed, "nobody much".

.... in Twisted-world.

Several hundred million people
seem to agree with me

They do not agree or disagree with you - they simply have no opinion
on the matter.

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.

You need to learn that there is a difference between not having an
opinion about something and being against that same thing.

Software that sends normal users running screaming. This is what you
peddle. This is why you fail.

You may have normal users running around screaming - I have not seen
it myself.

and nearly everyone else on Earth simply doesn't
use computers at all. :P

Again, they have no opinion.

They certainly won't benefit from emacs.

Most of them probably won't, no.

[some irrelevant prattle deleted]

Bent seems to be conceding this point as well.

Ah, I recognize another desperate exit strategy when I see one: now
you're going to remove my text, call it "irrelevant" and pretend that
this means I have conceded some point or other.

Should be interesting to see how well this works for you.

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

The emacs UI is consistent, of course.

What the *** are you babbling about?

Real problem cases in the real world.

No, something you invented in Bent-world.

Yes, as I said, in the real world. :-)

If that mainframe is as legacy
as supposed, it could be replaced with a fairly cheap desktop computer
that would run rings around it and, properly configured, do the same
job but have SIX nines of uptime.

Except "cheap desktop computers" don't actually have anywhere near the
reliability of even quite ancient mainframes.

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. Some of that old IBM hardware is just mind-bogglingly
reliable.

Network several of them with failover, each
with a RAID drive, and you easily exceed the reliability of those old
clunkers by a large margin AND STILL for less money than those things
cost when new.

No. Replicating the reliability of those systems is a lot harder than
that.

And you'll now have thousands of times the memory and
megahertz, besides.

This doesn't improve reliability.

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.

Geographic dispersion is the best defense against localized disaster,
and pretty much requires (presumably now VPN-networked) multiple
redundant small machines instead of single big monolithic ones.

Your understanding of reliable systems is woefully inadequate.

Which, if it's as legacy as supposed, is probably
"reboot it", and, once in a blue moon, "turn it off, wait till the
hardware guys to replace something, and THEN reboot it".

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. Yeah, I know
/you/ actually don't care at all but I ensure you the bank /would/.

("Permanently" in that once the system is implemented with open source
software using open data formats, it should be possible to keep
migrating and updating components without any further truly-severe
difficulties.)

Except some downtime - which /is/ severe for these systems.

VT100 presumably uses a subset of these codes. The VT100 display
hardware does not actually show these colors, after all. Obviously,
then, a color VT100 is as mythical a beast as frigging Bigfoot no
matter WHAT escape sequences it uses.

Colour VT100 is easily observed in virtual[snip!]

In other words, in an imaginary world.

I am sure there are no VT100 terminal emulators in Twisted-world. In
the real world, on the other hand, they see extensive use.

Right next to the Starship /
Enterprise/; alien facehuggers; elves with magical powers living in a
town named Rivendell made of living trees; dragons; stargates; the
lost city of Atlantis; and numerous other such wonders of the virtual
CG world.

Ah, you base your world view on science fiction series. This explains
a lot.

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.

VT100 terminals haven't been physical for decades. While /you/ may
still be living in the 1980s, the reast of the world has moved on.

It doesn't need pixel-level acces to display underlining, or different
colours, of course.

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.

But you have said many times before you /want/ me to make your
arguments for you!

Even so...

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

You know, sooner or later 1980 will get fed up with you and kick you
out.

And in practise none
of those old terminals could display blue, underlined, clickable
links.

[insults and other nonsense deleted, including more about the
mythical "VT100 protocol"]

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

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.

If that
emulation has color, it's not a faithful emulation of a real VT100 and
therefore it's standards-violating and will potentially gum things up
(e.g. if the app at the sending end makes the right sorts of
assumptions as part of a larger assumption that the receiver is
standards-compliant).

Meanwhile, in the real world, showing colours in vt100 terminals works
flawlessly.

Your saying that they could in theory have constructed one that
would does not of course change the fact that NONE ACTUALLY DID!

And that is entirely beside the point.

NO. IT IS THE POINT.

It might be your point, now that you realize (again) that your
original position was completely undefendable. It's nobody else's
point, however.

The fact of the matter is that the protocol supports it

THERE IS NO PROTOCOL.

Of course there is. How else do you think one might display text on
the terminal?

Ah, right, I forgot: you are a big believer in telepathic software -
presumably the terminal should just /guess/ what to display and since
it's telepathic it always guesses right :-)

and you can witness this first hand (well,
you could if you were capable) using modern VT100 terminal emulators.

EMULATORS ARE IRRELEVANT. If you're using an emulator you can use a
VT420 emulator, or for that matter A REAL FUCKING GUI. :P

Except I am discussing the VT100 terminal.

VT100 is a machine, an ancient monochrome terminal such as you might
hook up to a dial-up modem and use to log on to some ancient Unix
mainframe.

And a protocol

NO.

Of course it is - it is the protocol you use to display stuff on a
VT100 terminal.

, of course, which would
just mean scalable fonts and other normal Windows-style UI
capabilities.

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.

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

"File->Open" will tend to give a File Open dialog from the underlying
OS.

Remember I'm discussing the modern era of software with
standardized GUI interfaces, which began no later than 1995 and really
began all the way back around 1990 or so.

It began much before that, of course: The first Mac came in 1984.

Not really.

Of course it did:
http://en.wikipedia.org/wiki/Macintosh#1984:_Introduction

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.

The protocol

WHAT protocol? See above. There was no wire protocol to speak of.

It is referred to as ANSI escape codes.

That's not a protocol. That's a crufty embedding of OOB data into a
raw ASCII stream.

aka a protocol.

The actual protocol will be something like telnet
over TCP/IP over serial, or raw fucking RS232 serial, or dial-up v.
42bis, or something else.

You do realize that protocols can be layered, right? Right?

There was raw ASCII over a line.

With ANSI escape codes.

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

HTML is more properly referred to as a markup language. Hope this
helped.

, but of course the
VT100 with its monochrome display could not support any escape
sequences that purported to specify color text.

Of course it could

NO. IT COULD NOT.

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. How these colours actually come
out on a physical display is a different matter altogether.

It is YOU who claimed that emacs had such behavior.

This whole telepathy debate was your own little invention. Why on
Earth you would expect any software to be telepathic is beyond me.

It always deletes the character it's /supposed to/, of course.

No, it does not.

Of course it does - I have never known it to do otherwise.

You explicitly described it failing to delete any character at all
under various circumstances

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

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

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

(...)fortunately, it doesn't *limit* its not deleting characters only to
when you're at the far left of the input field.

True, true. :-)

You said that the sensible backspace behavior would result in losing
access to earlier search results.

It would, yes.

I proved that wrong ages ago, dip***.

No, what you did was confuse yourself no end as to what might or might
not happen when search wraps around and how this might enable you to
rediscover old hits.

We have since found out that a) that
same problem would have plagued typing a new letter to add to the
query

It doesn't of course.

Sure it does.

foo
foob
foobar
foob
foobar

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

Yes.


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

No, you're on the first line.

AFTER one hit of "foo".
Backspace x1 (proposed nicer behavior) -> query is "foo" and you're on
the fourth line. After three hits of "foo".
Type a letter "a" -> query is "fooba" and you're on the fifth line.
AFTER one hit of "fooba".

This would not be desirable.

Face it, Bent. You're stuck between a rock and a hard place in this
case.

No, I'm stuck between the real world and your ignorance. And having a
great time being there :-)

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.

I think I can assure you that the backspace behaviour in the real
emacs is entirely different from that of your own VanillaEmacs
creation.

See above. You objected to sensible backspace behavior (i.e. always
delete the character to the left if there is one) on the grounds that
supposedly you'd lose access to some search results for "foo" if you
searched for "foob", moved a hit or two forward, and then backspaced
the "b" and the "b" immediately disappeared.

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.

Search for "foob" and you're at the second line above. Hit next-match
twice and you're at the final line. Backspace the "b" and with proper
backspace behavior you'd still be at the final line with "foo" in the
query.

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.

backspace behaving weird is awkward.

It certainly would be.

And if not
being on the first hit for the reduced query is awkward, then the
backspace behavior you've described is awkward regardless.

You do not seem to quite realize what happens when you reduce the
query.

But with the wonky backspace behavior, you have to backspace three
extra times

[quibbling deleted]

Don't quibble.

Quibble. Quibble. Quibble.

And if you don't watch it I will quibble some more!

, and end up on line two with the "foo" in the first "foob"
selected, STILL not the first hit for "foo".

No, you will be at the first "foo" (line 1) at this point.

No, you won't.

Ah, sorry, you're referring to your VanillaEmacs. Well, in that case,
all bets are off.

You went back to the first "foob" and then backspaced
the "b". At this point backspace behaves normally, or so you've
claimed.

What your VanillaEmacs does or does not do - I do not care to
speculate.

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.

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

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.

Your descriptions of its behavior are awkward. Worse, they're
inconsistent. Your objection to some nicer ways it could work is
equally applicable to the way you claim it actually works. Nothing you
have said justifies not having a separate "previous-match" binding and
a backspace that acts as people would expect. PEOPLE NEW TO EMACS in
particular.

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


Or, even better, the behavior you'd need to get what you ACTUALLY
seemed to want, which is that if you backspace from "foob" to "foo"
you're back on the first hit for "foo"

This is, indeed, what happens.

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.

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, no. Backspace deleting parts of the search query is desired
behaviour.

And implied that backspacing the "b" on the
first hit for "foob" wouldn't move you, only delete the "b".

You've been inferring things again.

Now you
contradict the latter,

I find that contradicting your inferences has become something of a
frequent necessity.

and claim that the actual behavior is behavior
you criticized as crufty when I suggested something somewhat similar.

No, you are confusing my earlier claims.

This is ludicrous! As far as I can tell, in Bent-world behavior is
crufty if Twisted proposed it and non-crufty if emacs exhibits it,
independently of a) other software and thus-established standards, b)
other users and their wishes, and c) anything resembling reason or
logic. Even to the point that if I suggest a behavior that emacs
actually has it'd be, in your eyes, both crufty and non-crufty at the
same time, I suspect. :P

If you were actually capable of remembering more than two posts back
(as you have been complaining you can not), then perhaps you would
also have been able to work out how I never complained about backspace
deleting parts of the search query.

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

Usefulness interests me. If symmetry detracts from usefulness, then
I'm afraid beauty will have to suffer.

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