Re: Great SWT Program

In article <1193441761.071420.275430@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<nebulous99@xxxxxxxxx> wrote:
On Oct 26, 6:18 pm, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
[snip]

I don't have time to be constantly playing catch-up. Back off your
posting rate. Allow at least 18 hours after I've posted a reply before
you post a counter-reply please.

You should lodge your complaint with the Usenet Frequent Posting
Arbitration Council.

Even when this is the case (but it's really more of a case with long
sequential key sequences than with complicated parallel ones), you
remap it if it's something that you find very useful.

Oh, wonderful. So instead of finding ctrl-shift-alt-this in the help
and then typing it, you find it in the help, find some remapping stuff
in the help, type something else complicated, type ctrl-shift-alt-
this, type something simpler, and type something else complicated, all
before EITHER of the helps you viewed passes out of short-term memory?
What was this system designed for use by?

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

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

Some humans, perhaps.

So while "insert
text in region" might normally be C-x r t, you can happily remap it to
just C-r or C-t if you want. Or even to just "r" or "t" if you're
truly a fanatical string-rectangle user.

So much fo popely yping ino you documen any wods conaining ceain lees,
eh? You'll end up wishing fo vi's scewy modes! :P

Ah, that is right, you fail to comprehend the usefulness of modal
editing. Oh well, not my loss.

Well, it's that or the mouse, if you want to select an arbitrary chunk
of text partway up the screen from where you were typing at the
leading edge of the document for whatever reason.

I can do this easily with backwards incremental search (C-r).

I'm talking about an arbitrary selection. Not some specific, contrived
case where the endpoints happen to be marked by some unique string.

Why would it need to be unique?

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

Experience shows that this is generally not the case.

, and b) you
have to get the query exactly right or it just says "not found" and
you go nowhere.

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

That gets you to one endpoint of the selection. Then you have to get
to the other endpoint EXTENDING THE SELECTION.

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

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

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

I don't see a way to do it with your method. Certainly I don't
see shifting your C-r turning out to actually "move mobile selection
endpoint to target" -- it wouldn't be that simple, it just wouldn't
be, not in a million years. That simply isn't how the designers of
emacs thought. It would make things too easy.

Incremental search forward is C-s. And emacs, unlike your much vaunted
GUI editors, doesn't suddenly decide to forget where the start of your
region is just because your finger slipped on the Shift key midway
through the Shift-arrowkey procedure. Once you have C-s'd your way to
the region endpoint, emacs will still remember where you were when you
started and you can proceed right on to making region commands.

And, as a bonus, when I do this, the context I need to think about is "what
text do I want to start the selection at" rather than "what are the
relative coordinates of the character I want to start the search
at". Much more convenient all around.

Funny. I don't think either of those things. I just see where I want
to go and I go there with one click, or with some arrowing in the
general direction until I'm there.

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

To use your method I would have to think and not just click
reflexively where I wanted to go.

If clicking seems more convenient, I will certainly do that instead.

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

You could if you wanted to complicate matters over-much. If you were
more interested in actually getting things done, however, you would
press C-r and start typing what you're looking for - correcting on the
fly if you find you make mistakes.

Then assuming I'm at the target I
still need to extend the selection to the other intended endpoint.
That's shift-arrows again, or else typing the ENTIRE thing I intend to
select into ctrl+f, in which case it better not be multiline or
especially long at all.

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

Versus click, instantly there, shift-click, selection instantly as
intended. All of which takes a fraction of a second.

There is certainly no reason not to use the mouse if that appears more
convenient.

Search is simply not useful for the sort of thing we are discussing.

Not if you're using inefficient GUI-like search paradigms, no.

After all it was never intended to be; it was intended for finding
information, not as a primary navigational command for long-range
jumps.

The search facilities in emacs, however, were designed precisely to be
useful for this sort of activity.

From down here, for example, "C-r chunk" will take my cursor right
back to the word "chunk" you typed above without any fiddling around
with cursor keys or the like.

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

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

With an inefficient keyboard interface, that statement may be true. I
am lucky enough not to be cursed with such abysmal tools.

Nothing is abysmal about my tools. My tools don't require me to use
the (inevitably and unavoidably) inefficient keyboard interface for
long range travel, because of the wonderful invention called the
mouse!

What is actually the case is that the designers of your tools are
relying on the mouse as a crutch to avoid having to implement what
would actually be an /efficient/ way of going about things. I am lucky
enough to have the best of both worlds: I can use the mouse if I feel
like it, or I can use an efficient keyboard-based interface if that
seems more opportune.

I rarely make arbitrary selections - I tend to be quite particular
about the selections that I make.

I'm sure, but that's not what I meant by "arbitrary". The selections I
make are far too varied to boil down to any sort of "recipe" or
simplified description that might conceivably simplify automation even
more than "click, shift click, done" does. It would have to be the
case that you could make a (smaller than a screenful) selection that
was exactly right with only ONE keypress to beat that. Whether you hit
several dozen arrow keys or type several dozen characters to make a
sufficiently-unique search query, you're going to be several dozen
times too slow to qualify there methinks.

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

I do. As does anyone who is proficient with emacs.

What a pain to have to memorize all that crap when it could have been
something *simple*!

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

My arrow and paging keys also work, of course, but I rarely use them
because their positioning on the keyboard makes them awkward to get
to.

Maybe you should replace your keyboard. I don't have any such trouble
with mine.

That is only for lack of a proper alternative. If you had access to
navigation keys that were actually handy to use, it would become clear
to you how owkward the arrow keys are.

But anyway, this isn't what emacs' incremental search does and it's
not nearly as useful as emacs' incremental search feature.

Well, then, apparently emacs' incremental search is misnamed then.

Incremental search is a fairly well known concept in the programming
field. I am somewhat surprised you haven't heard of it.

I
assumed it meant what it says, in plain English, and what I find is
common search functionality that fits the description. If it's
something weird and strange instead that's hardly my fault. Xah Lee
was right about their confusing misuse and mangling of commonplace
English words it seems! And if you're not even using the real English
language but something subtly different (emacsese?) that closely
resembles it, it's no wonder we're at loggerheads...

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

So your proposed solution to having an annoying search dialog is to
bring it up and then to dismiss it because it's in the way. Somehow, I
prefer the application that saves me from having to bring it up in the
first place.

Except that you have to have a place to put the query into! I'd hate
to have to type it blind.

As would I.

You can't actually define your search terms without first bringing it
up though, and you can't change them without bringing it back up
either. How cumbersome.

Again, you have to type your search terms into somewhere. I'd much
rather not do it blind, nor have the place where they are typed
wasting screen real-estate during the 99.7% of the time that I'm not
searching. Or have it be small and cramped because they had to
compromise between using too much real-estate and making it big enough
that you could see what you were doing without becoming
claustrophobic.

Does this enumerate all the possible ways you would rather not have
it, or are there more?

Did you know that you can actually edit a search query to be slightly
different and reissue it with my tools? Your typical unix tool makes
you hit / or whatever, type something, hit enter, and it goes
somewhere or says "not found". To do a slightly different search you
hit /, type the entire slightly different query from scratch, hit
enter...

If so, then it is not incremental search.

Perhaps your presumption is wrong?

No. Nothing about me is ever wrong, and in this case I was simply
stating an observation that is easily confirmed with a cursory google
groups search for Chrissakes.

So you have found masses of people celebrating how the javadoc on
Java's regexp parser is the best thing since sliced bread?

If you're going to arbitrarily dispute
with me for the sake of disputation, at least pick something that
doesn't force you to be so clearly counterfactual!

Well, you see, something isn't automatically a fact just because you
have claimed it to be.

Ask someone who doesn't know a "C"-type language what a C program
looks like. That's right, line noise.

IOCCC entries, perhaps. Well-written and structured code, no.

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

OTOH, I haven't seen a nontrivial regexp that wasn't way too much
punctuation by volume.

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

You assume that you wouldn't use anything else except emacs, period,
ever again, in the way of computer software. If it's *that* damned
addictive they should ban it IMO. :P

Well, once the competition catches up, I'll be happy to start using
it.

Of course, this kludge isn't necessary in emacs.

How the hell would you know?

I've used it for a number of years now. I know.

Everything you do in emacs is apparently
one giant kludge, either around the lack of a proper windowed display
or around the lack of a mouse or around the lack of the entire right
half of your keyboard!

So, you figure that everything in emacs is one giant kludge to account
for all of the fictional deficiencies that you have attributed to it?

I'm sorry, but the emacs developers do not schedule their programming
according to your delusions.

Even text can make use of rectangular blocks in a meaningful manner.
Code is no different in this regard.

Specialist features for some obscure sort of fancily-formatted verse
don't belong in a plain text editor.

I don't think I ever claimed that emacs was a "plain" editor. It's an
editor with bells and whistles, if anything.

Only if the indent goes at the start of the line, and even then only
if the automatic indentation is suitable for the structure you are
trying to emphasize.

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

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

, and if automatic indentation
isn't formatting things to your liking, well, then, you should
reconfigure it. Oh, the auto-indent says "my way of the highway"? Use
Eclipse or something else nice that lets you redefine its indent rules
more-or-less arbitrarily.

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

And ultimately we are discussing cosmetic features here. Any sane
implementation of auto-indenting of C/C++/Java code will do in a
pinch; it may not look how you prefer it but it will still do the
important thing of visually keeping the nesting levels straight.
Anything beyond that is just decorative tweaking and hardly mission-
critical.

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

But, again, if you already know how to do it there is no mental burden
and the learning curve has long since been scaled.

There is added mental burden if you have to think which to choose from
among a large set of specialist commands instead of a small set of
orthogonal, generally-useful ones (such as up and delete).

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

It's like having two possible street layouts. (...)

The standard windows interfaces are like very-similar-to-one-another
grid layouts. Emacs is obviously quite the maze, like the tangle of
variously-angled streets (some one-way) typically found in old
downtown cores of cities. Maybe you can eventually travel a few
specific routes especially fast in your city, but it's massively
hostile to newcomers (think maze-like street layout WITH NO STREET
SIGNS) and even when you master it it obviously favors a particular
flow. The grid layout accommodates any workflow, including ones the
original programmers never anticipated, and is simple for anyone to
learn to navigate. It's clearly superior.

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

How am I doing so far?

You should get some sort of a ruler across the wrist treatment for
your behavior so far.

My nominal ruler is King Harald V. I really wouldn't mind meeting him,
so if you're working on this you have my whole-hearted support.

I don't like the insulting insinuation you again made here. And the
fact is, typing the path to the binary every single time instead of
only the first time is BY ITSELF enough to demonstrate my way
superior.

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

So is the fact that the secondary app can actually be
interactive in my case. So is the fact that I can do something, copy a
result, then make a slight edit and generate and copy another result
without starting over from scratch, while you need to type one
command, specifying the path to the binary and everything else, then
type another only slightly-different command, specifying the path to
the same binary all over again ...

You must have missed the part where I explained how commands can be
re-issued. Perhaps if you used a better editor, this sort of thing
wouldn't happen.

What are you blathering about now? You're moving the goalposts again.
We were discussing using a text editor's "launch external command"
command to run something and auto-paste the output, not running
commands from a full command shell with history and other features.

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

You can run your command from the shell or you can run it from the
editor, but you have to choose only one. You can't defend your choice
of editor on the basis of things you can do from the shell! Only what
you can do from inside the editor can possibly count.

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

And regardless, the command still has to be noninteractive. You can't
have it do 90% of the job, then decide on the basis of what the
results so far are what final tweaks to make, then make those tweaks
and have it finish, or do something that involves actually "building"
something instead of just specifying a linear string of text, or
anything like that, either. But I can.

Interactive shell tools aren't particularly common in emacs'
environment, but you can certainly have them. In most cases, it's more
convenient to be able to specify all the parameters on the command
line so they can easily be edited and/or reused later without having
to wade through all of the interactivity again.

If what you're writing is effectively an entire little program in its
own right, you'll just type it into the editor window, select it, and
run M-x eval-region

If what you're writing is effectively an entire little program in its
own right, you're better off using a proper development tool to do
this with and keeping the newly created binary around in case you have
future use of it, instead of potentially writing and discarding the
same one-off zillions of times over the course of your life.

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

Bah. You will never stop attacking me will you?

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

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