Re: Great SWT Program

In article <5526fb6e-bc34-4666-ac83-4ef72e34e546@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<twerpinator@xxxxxxxxx> wrote:
On Dec 28 2007, 9:39 pm, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
[snip]

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

After you. Or then again, perhaps not :-)


Your post, of course, is just as long.

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

Certainly, since I don't have an obsession about these things, my
posts are exactly as long or short as I want them to be.

In fact, yours could
be nonexistent and it wouldn't cost you anything.

This is wrong, though. It would cost me a significant source of
amusement, for one.

Exactly. All it said was insults.

No, it said [insult deleted]

That IS an insult, moron.

Not in the normal world, no.

YES IT IS.

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

Straw man alert! Torch! Torch!

Because in Twisted-world, rotation, bump-mapping and ray-tracing are
/not/ among the powers of modern graphics hardware.

Sure they are. But I never said I need those from my text editor.

You said the text editor should make use of the full capabilities of
modern graphics hardware, which includes the above. So you are wrong
again. How does that feel?

Just
a text editor where I can actually see what the *** I'm doing and
navigate around decently.

Even after changing tack like this, you're still missing your
target. It is easy to see what's going on in emacs so your implied
complaint falls flat to the ground.

Then why are you using archaic crud?

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

Which apparently is all the time.

No, only very occassionally.

What kind of profession, by the way,
insists on nobody modernizing?

Changing topic again? What are you trying to sweep under the rug now?

No, we are discussing the mini-buffer, not the status line.

Both being a waste of space, in Twisted-world.

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, by its nature, is always in use, and in modern
applications, toolbars and menu bars need to be accessible at any
time. The title bar on a modern app is arguably dispensible, but it
provides a useful orienting cue as well as a convenient handle to grab
the window by

You can't actually grab windows by the status bar in Windows apps and
then do anything useful with them.

Fortunately, Google Groups will, as always, put the lie to your
attempts to rewrite history and distance yourself from claims you made
that now embarrass you.

It would, I suppose, if such claims existed. But again, you would
never be able to verify this.

No, it is not normal for enter to fail to insert a newline in the big
block of text in the text editor window!

Of course it is

NO, IT ISN'T.

Do a telephone poll of random middle-class Americans if you don't
believe me.

Are you trying to build another random middle-class straw man now?

when the user does not want enter to insert a newline

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

Often, perhaps, but not always.

This
follows almost directly from the definition of "text editor" for
chrissake.

Of course not. Well, not in the real world. It might on planet
Twisted.

("The user"
being any random person from the huge class you've been peddling emacs
to, of course, rather than a pre-existing experienced emacs user.)

Most of them, of course, will have no trouble absorbing the emacs
training even if they /don't/ have any previous emacs experience.

Of course they will.

No, you see, most people aren't quite as hidebound as you appear to
be.

It's completely alien to every kind of UI
standard

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

(...)

Ouchies.

Try not to think so much if it causes you actual pain :-)

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. As you have said many times yourself,
Windows apps are remarkably easy to learn for the most part.

The smart choice there, of course, is always going to be "everything
else".

Whileas the really smart (that would be "impossibly smart
super-geniuses" in Twisted-world) go for both and so get the best of
both worlds.

Of course it does - it says so right there in the status line.

No it doesn't. It says any of several cryptic things

[irrelevancies deleted]

We are not discussing MDI indicators here. That was in another thread.

And yet, again your past mistakes come back to haunt you. Don't you
just hate it when that happens?

I have repeatedly pointed out, ever since this thread began, that it
requires training to become proficient with emacs.

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. Powerful tools require training - the rest of us learn
to deal with this fact.

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.

Would you like it if
your kid's trike came with a 400-page manual and handlebars covered
with more controls than in the Space Shuttle cockpit?

In what world are kids considered to be professional trike riders? Oh,
yeah, right, Twisted-world, that's where.

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 you're way off track here.

And there goes your claim of emacs being suitable for use by darn near
everyone.

That is not my claim, of course.

It was.

Of course not - it was a claim you invented to give yourself an easy
target.

YES IT DOES. If emacs is misusing this to not mean what it normally
means then that is just one more black mark against emacs.

We realize by now how much you hate user friendliness :-)

I DO NOT. Stop putting words in my mouth, you lying little prick.

You have implied it. Over and over again.

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. Different users will, of course, have different ideas of what is
convenient and what is not.

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

And now you're losing it again, as emacs doesn't lie to the user.

In fact no archaic box of text glowing green on a black
background like it's the 1970s is "user friendly". :P

And now you're /completely/ off the playing field. Maybe you went to
get coffee or something?

(Funny how nostalgia buffs in the computer field always seem to favor
stuff from that particular era. It's never earlier, e.g. punched cards
or toggling everything in manually after each reboot, for some reason,
and never later, like old-skool Windows 3.x era stuff, either. I
wonder why?)

You are wrong again, of course, since many of the Unix tools were
developed throughout the 90s and right up to the present.

On the contrary: if they really /do/ edit text a lot, they are quickly
going to see its advantages over Notepad and will likely never look
back.

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.

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 :-)

Sure, it won't have a built-in newsreader. Who needs one in a text
editor? I'll use Thunderbird.

Sure, it won't have a built-in Mayan calendar. Who needs one? Period.

Sure, it won't have i-search, in all likelihood. Fortunately, we in
the GUI era have far less need of such to get around in our documents.

If I need code-editing-specific stuff I can use Eclipse or NetBeans.

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.

I have no use for emacs

Of course you don't - you don't actually edit text a lot. You are not
in the target group.

It's 2008 now. Time to stop living in 1978. Get with the times; get up
to speed on modern window system UIs (it should take less than two
weeks and be applicable to nearly every modern application instead of
only one!) and 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.

Or keep using emacs if you really prefer to, but stop telling everyone
else that they should turn their clocks back three decades and use
that old hunk of junk instead of the modern tools they currently are
very productive with.

This is another straw man of yours, of course.

This is "cryptic" to anyone without weeks of special-purpose training,

No, normal people actually /understand/ this after you've explained it
to them one single time. This takes all of half a minute to do.

Exactly.

Ah, a breakthrough at last.

("All of half a minute"? Bull***. Earlier you said it takes two weeks
and I'm quite sure it actually takes quite a bit longer with anyone
whose level of IT skill is only normal.)

You are confusing issues again. Learning most of the useful features
that one particular user needs may take a couple of weeks with ongoing
use. What you failed to spot was that I focused on one /single/
feature and commented on how long it might take to learn this one.

Try and tell that to the large hordes of people that need to be
retrained for the Vista Office suite :-)

If what you're implying is true, it just means that M$ fucked up Vista
even worse than I originally suspected. Although I'd thought that
applications are, in Vista, still displayed in distinct and easily
identifiable windows much as they have been in every Windows since at
least as far back as 3.1 up until XP?

Professional users seem to think otherwise. Apparently, Microsoft have
introduced some new paradigms to account for the plethora of functions
("creeping featurism" in Twisted-speak) in their applications and
these new paradigms take some time to learn - just as the old Windows
paradigms do.

Go to hell, pervert.
Fucking rich, this, after Bent's spent weeks explaining how even the
most standardized keys everywhere else in the world, like backspace,
esc, and enter, will do surprising and wonky things in emacs

Read: will do useful things that the user wants to happen. [implied
insult deleted]

No, they will do very strange and wonky things.

Strange and wonky to you, perhaps, but then most things apparently
/do/ seem strange and wonky to you.

Some of them are,
perhaps, also useful things, but useful things that some other key
should be doing instead so that backspace or whatever can be free to
do as God intended. :P

Ah, now it's by divine mandate that your GUI dogma have been
established? It would explain why you consider them to be written in
stone, I suppose.

You are really going off the deep end here.

, and
furthermore do different things from one minute to the next in emacs,

None of the functions in emacs are dependent upon the wall clock.

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, but not to someone who
actually cares about learning the UI.

Opening documents is unlikely to put you into a non-editable state

Then why did your example of opening the output from a search do so?

That isn't a document, it's just a grep buffer.

More terminology-quibbling. And wholly irrelevant.

It would have to be to preserve your own self image I suppose.
Meanwhile, in the rest of the world, it cuts straight to the heart of
the matter.

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.

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

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

There most certainly is.

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".
What they did was run a command in the text editor, which is something
else entirely.

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.

E.g., they except a grep buffer to let them choose a line and move
them to the relevant hit.

If it does not, it will upset them.

Which is exactly why emacs does this.

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

And emacs is very consistent about this, of course.

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

Emacs does not concern itself with moon phases and tea prices, of
course.

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

/You/ may need very simple software, of course, but IT professionals
generally do not.

Clear only to an expert, of course.

Of course, in Twisted-world, anyone who has the patience and extreme
willpower required to stick to any one task for more than an hour
straight is an expert by default

Two weeks of training, or had you forgotten already?

Ah, you have been working under the erroneous assumption that one
would have to train for two weeks, 24/7, without sleeping or eating?
This would explain some of your crazier misconceptions I suppose.

THIS IS FUCKING RIDICULOUS!

So why do you keep doing it?

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

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". If
anything, it defines the lowest standards one may keep to and still
call something a text editor but that is something of a different
matter.

By the way, there are precious few other text editors that support
Notepad's log file feature so you've basically just betrayed your own
ignorance again.

There is *nothing at all* that is remotely "standard" about emacs. It
does not even have *internal* consistency

Of course it does, and this is one of its very strong points.

Not only do they not correspond
to anything in the way of commonly-used modern software, but they
don't even seem to be standardized *inside of* emacs.

The different emacs modes are remarkably consistent in their key
bindings.

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 having enter do the most useful thing in
its various modes.

The problem being that it provides no natural way to switch tasks

There is, of course, no "natural" way to switch tasks anyway.

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.

, and
all applications look the same,

Except, of course, they have different names that are clearly
displayed when they are active.

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.

even ones that behave enormously
differently (oh, except for the crude prototype "title bar"
equivalent, which is of course in the wrong location, below instead of
above the client area, and therefore where nobody's likely to look for
it...)

Emacs users don't have this particular problem, of course.

Experienced ones probably don't

It's one of the first things you are likely to learn, but yeah, to you
someone with five minutes of emacs experience is probably an
"experienced" user.

If only a couple of thousand people out of tens of thousands of times
as many, i.e. less than 0.01% of people, will look there, I think
"nobody's likely to look" there is a fair approximation. We're talking
0.0001 or so of your target market here. Rounding to three significant
figures, as is commonly done, that literally IS nobody.

You've got your imagined numbers completely wrong again, of course.

Desired behavior, as decided by just about all of the people that
you've recommended emacs to but that don't currently use it, would be
for enter to consistently insert a newline into the big block of text.

Not once

YES, IT IS!

Or perhaps you just need to clean your keyboard. Have you spilled coke
into it or something? That would explain the sticky shift key.

I do agree that many may have been tricked to believe otherwise from
whatever tools they used previously [remainder of paranoid ravings
deleted]

What a lunatic. Someone lock Bent up before he hurts someone. If only
me, my sides splitting due to laughter and needing hundreds of
sutures. :P

You might want to try and gain control over that maniacal laughter of
yours - it seems to be causing you physical injury :-)

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.

There's a tantalizing
implication there waiting for you to recognize it, once you grow your
second ever brain cell and it finds your first and grows you your
first ever synapse. :P

I can accept that no one in TwistedWorld uses emacs, and also that no
one in the real world would use your own VanillaEmacs, but that's as
far as it goes.

Most people can become such a user

Nobody should have to, just to be able to use a fucking *text editor*,

Nobody's forcing them, of course, but once they realize the advantages
they will tend to embrace it.

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. Do you ever find it annoying when
reality fails to adhere to your wild guesses?

The only thing I'd
"embrace" it with is an Iron Maiden.

Ah, /you/, yes, of course, but then you are "special" :-)

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.

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

Again, they have no opinion.

Inconsistency in the UI is ALWAYS a Bad Thing, moron.

Except [snip]

NO. IT IS ALWAYS A BAD THING.

Except, of course, when it is a good thing.

WHICH IS NEVER!!!

You can generally wedge out the shift key using some thin tool. You
shouldn't use detergents to clean underneath though, just a dab of
water generally does the trick.

It sure as *** is, because whatever it is that's misbehaving can
obviously be replaced with a $200 OLPC laptop for Chrissake.

Yeah, you tell that to your employer "we'll just replace your
99.999%-uptime mainframe with this here OLPC and everything will be
fine - well except it doesn't actually run your business software, but
hey, I get to use a mouse and that's really all that matters anyway".

What the *** are you babbling about?

Real problem cases in the real world. Something you are largely immune
to in TwistedWorld, but you nevertheless need to deal with it when
interacting with other people.

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. In TwistedWorld,
employers probably don't care about this of course.

Most likely it just needs to be
remotely administered from a desktop machine elsewhere that runs a
nice graphical frontend for whatever needs to be done on the
mainframe, though.

Then someone would need to develop that frontend: "Well, sorry boss,
but I'm Twisted and I'm allergic to CLIs so I demand that you plonk
down a cool mill so that we can create a frontend that I am actually
capable of comprehending."

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: . . ."

But this will be beyond you.

When legacy
parts get scarce

I think you will find that IBM are quite happy to support their
mainframes for quite some time to come yet.

, the data needs to be exported to something sane
(like CSV, just temporarily) and then imported into something open-
source (like OpenOffice), in which case problem solved.

Yeah, right, you would import a banking system into OpenOffice. Heh.

Permanently. :P

Well, I suppose it would be "solved" in that the company would soon be
bankrupt and so wouldn't actually need their business software any
more :-)

If I had
the choice of learning to use awful cruft like emacs or replace the
thing, I'd pay the $200 out of my own pocket and do my bit to
modernize things around the place. :P

Except it wouldn't actually work afterwards

Sure it would. You're just inventing additional hypotheticals purely
for the purpose of trying to make me look like a liar. But I'm not a
liar, Bent; you are.

Unlike you, I actually have some clue as to the /real/ problems that
exist out there in the /real/ world, and everything is far from as
rosy as you have dreamt up in your own little Twisted-world.

You would be surprised at how many legacy systems are running
mission-critical tasks around the world.

No. Dismayed, but not surprised. Upgrading them is of course a good
idea, though it progresses slowly for time and budgetary reasons.

And, of course, for "if it's not broken, don't repair it" reasons.

I dare say that if:
a) its software is awful and crufty to use, and

Only to habitual deniers of reality, of course.

b) it's getting hard to find the right parts for the hardware, and

Ah, a new and interesting straw man. What do you think he will grow up
to become?

c) the data is in some legacy format that's increasingly not
supported,

And he's got a brother!

then it's fucking broken and in dire need of repair

Since none of your points actually apply, you're just blathering
again.

Nonsense. Later VTs may have but VT100s are monochrome.

VT100 uses the ANSI escape codes, which supports red, green, yellow,
blue, magenta and cyan.

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 T100-capable terminals. As
to whether anyone ever made a physical VT100 that could show colours,
I have no idea: physical VT100s became irrelevant a very long time
ago.

YES. IT MUST BE ABLE TO PIXEL-ADDRESS THE DISPLAY TO QUALIFY AS TRUE
GRAPHICAL SOFTWARE.

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.

That wasn't your complaint though - your complaint was about colour
and underlining.

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

You're stuck arguing about ancient physical terminals now? Try to
update yourself and join the 21st century some day. VT100 is a
protocol used for virtual terminals.

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. The fact of the matter is that
the protocol supports it and you can witness this first hand (well,
you could if you were capable) using modern VT100 terminal emulators.

VT100 is a protocol, if you hadn't noticed.

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 much used by modern terminal emulators. Of course,
you're stuck in the 1970s so you wouldn't realize this.

Except, of course, that you have /yourself/ stated, in this very post,
that you require text editors to use the full power of today's
state-of-the-art graphics hardware.

I have not.

Indeed you did.

Not.

And now you're frantically trying to get out of the impossible
position you have put yourself in - again :-)

You specifically lambasted emacs for not being able to
make use of the full capabilities of modern graphics hardware.

By "modern" I meant "as modern as Windows 95"

Yeah, the 21st century is so frightening, isn't it, you wouldn't want
to just barge into it unprepared :-)

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

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.

Impossible. There is no "VT100 protocol", there is simply raw ASCII
over a line, usually in those old systems without even error
correction. You also seem to have forgotten that the real, physical
VT100 has a monochrome display. One of the later VT series had color,
and even *that* is an obsolete piece of junk.

The protocol

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

It is referred to as ANSI escape codes.

There was raw ASCII over a line.

With ANSI escape codes.

Some clever stuff was transmitted OOB
using escape sequences and other crufty mechanisms

Ah, so you /did/ know you were wrong after all. Then why did you
choose to first bollocks it up completely?

, 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 - but it might display them as as different shades
of gray.

*** off, asswipe.

No, what YOU wrote was meaningless, fucktard.

Go to hell.

My claim didn't involve telepathy at all, it concerned itself with
altogether more mundane functionality.

Functionality that happens to require telepathy to implement properly,
mind you.

Perhaps in Twisted-world. In the normal world, emacs did it a couple
of decades ago.

Except that it didn't, as I demonstrated by exhibiting a case in which
it would indeed fail to alert you "instantly" when you had to modify
your query to get to the specific spot you were looking for.

Do you really think that your strategy of trying to pretend that
software should be capable of mind control is going to actually get
you anywhere?

Go to hell.

That much is true. But it is not what you originally said.

[insult deleted]

No. Nothing about me is "faulty".

On the contrary, most things appear to be.

There's nothing wrong with it if it deletes the character it's
supposed to, moron.

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 yourself have claimed that it sometimes fails to
delete any characters at all

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

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

It would, yes. You would have to find them again instead.

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.

and b) it doesn't actually happen anyway because the search
wraps.

It can wrap, but then you're stuck with having to try and search your
way to the "older" results once more. Emacs tries to be considerably
more user friendly than this.

So your objection to sensible backspace behavior proved not to
hold water.

Not if you're prepared to live with terribly awkward behaviour instead
I suppose.

Because I long since purged every trace of that execrable piece of
crap from my hard drive and absolutely refuse to ever let it back on
there, and therefore don't have a copy in front of me, that's why.

[insult deleted]

No matter. It suffices that I have used it, whether or not I keep a
personal copy.

It does not, because the copy you used appears to be hopelessly
outdated in this day and age.

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.

But now we know that that was another lie, Bent. Suppose the document
was:

foo
foob
foob
foov
foobar

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.

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

Two extra times.

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

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.

And of course hit next-match one or more times from there and you WILL
end up back at the first "foo" or "foob" as appropriate, eventually.

Yes.

Your original objection to having backspace behave normally appears to
provide equally valid objections for the ACTUAL backspace behavior,
AND the behavior when typing another letter, AND seems pointless when
the search wraps anyway.

Only if you don't care about efficiency and prefer to manually try and
find out which new match is the same as some older match.

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.

, and that's that backspacing a)
removes a letter from the query and THEN b) jumps back to the first
hit for the query, instead of the other way around. Perhaps also
adding a letter should jump you to the first hit for the query

It jumps you to the /next/ hit for the new 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.

You cannot presume to know what circumstances will be faced by the
users that you plan to inflict this horror upon! They are far better
placed to decide what they want than you are. Let them be!

They may be - but you are not.

Yes, I am. I edit text a lot too, as it just so happens.

This does not seem likely.

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