Re: Great SWT Program

In article <1192260709.960192.19190@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<bbound@xxxxxxxxx> wrote:
On Oct 10, 11:49 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx>
wrote:

[ snip ]

Huh? You only apply the search-and-replace to the selected
lines, which are easily identified because they're consecutive.
Easily done with both my tools and yours, I suspect.

Except for the niggling little matter that making a selection in your
tools is either a) nontrivial or b) simply not possible, depending on
the tool.

I shouldn't have said "tools" above, because I meant a single tool,
namely vim.

Making a selection .... There are various ways. I'm not sure
any of them would be obvious to someone whose only experience of
using computers was with Windows. To me that's not important.
To you apparently it is. Whatever.

The way of selecting text that probably comes closest to being
familiar to Windows users is "visual mode": One positions
the cursor at the start of the text to be selected, types "v",
and then moves the cursor to the end of the text to be selected.
Moving the cursor can be done in a number of ways (arrow keys plus
less-obvious ways of moving to next line, end of paragraph, etc.).
The selected text is highlighted. One then types the command to
be applied to the selected text.

No, vi doesn't have this. But vim does. I suspect some of the
other "vi clones" do too, or they have something similar.

[ snip ]

Sure there is:

"s/^/text to insert at start of line/"

Er, what is that? It's not something straightforward, that much is
certain.

It's a search-and-replace command, vi(m) style. Hence perfectly
straightforward to people who've made some attempt to learn how
to use this tool. No need to remind me that Windows users might
not want to do that, or about how in their world you use control-F
for search and replace.

The "^" character matches the start of the line. As it does in
most forms of regular expressions I know about.

I'm talking plain old search and replace. If you can do it using
rocket science^W^Wregular expressions, good for you, but what about us
ordinary users who would have to reach for the help on each occasion
of having to use a regular expression? (Add to that the problems
ordinary users have accessing the help in your preferred type of
tool ...)

I have never, ever been talking about what "ordinary" users can
do with this tool. I've been talking about my use of it -- not
that I'm so extraordinary compared to other vim users, of course.

And in vim terms, "s/^/text to insert at start/" practically *is*
plain old search and replace.

I was talking about putting a unique (occurs nowhere else in the
document) string into each line, presumably at the beginning.

Ohhh .... And I was talking about selecting text to be operated on,
which is something most Windows editing tools let you do, right?

You never said anything about selecting until this post. Previously
you mentioned marking particular lines, which is something one does by
prepending something to them in my experience.

Which .... Oh, that's the problem -- a difference in terminology.
When experienced vi users talk about "marking" a line, they mean
setting an invisible mark that allows the line to be referenced
in copy/delete/search/etc. commands. It didn't occur to me that
it might mean something else to most people. Sorry about that.

[ snip ]

I wonder what you can possibly be talking about here. It's easy
enough to paste the contents of one of these "clipboards"
("registers" in vimspeak) into the text being edited without
losing anything.

I was discussing the console emulator saves, where you obviously can't
do that. Any "paste" there being a replace-all.

Huh?

On the other hand,
pasting just to see what gets pasted poses a problem when you have
already got a document in existence. In particular, afterward you
probably want to examine it and then get rid of it. But where is the
beginning of it? The insertion point is presumably left at the end of
the paste, but finding the beginning may be nontrivial.

Huh? You put a few blank lines in the file being edited, and paste
the selected text in the middle, where it should be easy to find,
and then to delete. (As it turns out, ":reg" also displays the
contents of all of these mini-clipboards. Not that that would
be obvious either.)

Not only does
this make seeing exactly what it was difficult, but putting the
document back the way it was becomes difficult as well, unless there's
a working undo feature that will undo pastes. Which I wouldn't count
on; I'll bet hitting ctrl-Z afterward will just make things beep,
blink, or otherwise act screwy. :P

You are correct that control-Z does not do, in vim, what it
does in the Windows world (and in many Unix GUI applications).
Neither does control-C, control-S, etc. "leer" means something
different in German from what it means in English, and something
still different in Spanish.

But vim does have a "working undo feature that will undo pastes".
I thought we talked about "undo" earlier in this thread. But why
should you remember. <shrug>

Of course, if you had a proper editor in a proper GUI environment,
you'd be able to paste into a blank document even if you were in the
middle of something, because you could create a new document without
closing the existing one, or even a whole new instance of the editor
running concurrently. But you're stuck single-tasking in a text mode
screen, so it's paste it into the current document, or save it, file
new, paste it, and then file open and find your place again.

Having a single text screen doesn't preclude logically splitting
it into multiple subscreens, each of which can be used to edit
a different file, or to show different areas of the same file.
Which is something vim supports (calling the subscreens "windows").

[ snip ]

Sure, if you're willing to attach files by selecting them one
at a time. I don't know of a way to select a bunch of files
matching a pattern, other than the admittedly somewhat arcane
one involving inserting those lines starting "Attach:".

A serious UI flaw in the "mutt" tool. Probably one of many.

Serious? Really? How often do you actually do this? I don't
much -- and I'm fairly sure it's not because it's difficult to
achieve, because I don't find the method I previously described
especially difficult.

It might be a nice feature to have, true.

[ snip description of selection menu for attaching files ]

Hrm. And you probably can't navigate as easily. I'm guessing it was
written before the invention of the mouse, here, and that the
programmers had the usual unix aversion to any key right of the enter
key, so selecting anything involves actually typing its whole name
rather than even arrowing around and hitting enter. :P (The Windoze
ones let you do all three: type a name, arrow around and hit enter, or
use the mouse.)

I don't really know about mouse support. The keyboard interface,
hm, it strikes me as being considerably nicer than what you
imagine:

One can move up and down the list of files with arrow keys and/or
page up/down, search for a particular file with "/" followed
by search text ("/" being the key used to initiate a search in
many text-mode applications), select a file by pressing enter,
descend into a directory similarly.

[*] I assume this is possible in Windows file explorer(s); I'm
not sure I know how to do it. It's probably "intuitive" though.

Sure can. Enter wildcards in the filename box and hit enter, i.e.
"*futz*" for files with "futz" in the name somewhere.

And see -- I'm not sure I knew this. People who use Windows
more than trivially and are willing to put a little time into
learning shortcuts would know it. But not even all long-time
Windows users are in that camp.

[ snip ]

Yeah. Different and not-entirely-compatible key bindings -- it's
an annoyance.

It's a showstopper, when combined with the help systems that range
from unnavigable to braindead to non-existent. :P

Except that in practice most of those old text-mode tools use one
of a small number of sets of keybindings, so an experienced user
would probably try those first, with a good chance of getting it
right on the first or second guess, and then resort to the man page.

Not ideal, but not the hopeless mess .... Oh well, maybe you think
anything but "one set of keybindings for all" is a hopeless mess.
Agree to disagree, maybe.

[ snip ]

It must be happening by magic, then. When I type the command to
insert the contents of another file into the one being edited, I
can type part of the filename and hit tab and get autocompletion
that works as it does in the shell. My guess is that vim is, on
detecting the command to insert a file, calling this readline()
function to get a filename. gnuplot provides similar functionality.

A command whose parameter is a filename yes. We were discussing
commands whose parameters are commands for the underlying shell to
execute, though, like when you want to ls those .tex files and paste
in the output. If you wanted to ls some other directory than the
current one you'd need to specify that as part of the command line,
and then you're SOL. The editor only knows you're entering some sort
of executable command for the shell. Hell, the shell would only know
you were entering some sort of parameter for some binary it's about to
launch.

Well .... vim seems to know when what I'm typing is meant to be
a command to be executed by a command shell, and to invoke ....
Hm, it's not quite the same function used by my shell to read
commands, because tab completion doesn't work on command names.
But at any point in typing the parameters to the command, if I
press tab, it assumes what I'm typing is meant to be a filename
and does the autocomplete thing.

One of the things that's interesting to me about this discussion
is that you seem to be working from some completely different
frame of reference, in which many of the things I take for granted
seem impossible, or at least very difficult. My guess is that
it's because our backgrounds are fairly different -- you seem to
know the Windows platform fairly well, and the Unix platform not
well at all, while for me it's the reverse. What's interesting
about it -- something to do with hidden assumptions, I think,
about what "everyone knows".

[ snip ]

Or you could split the screen into two windows, and type "edit ~/"
in one of them, and get something that behaves -- to me anyway --
remarkably like a text-mode version of a file browser.

Erm ... whatever. Nothing you said there makes much sense, starting
with the mention of windows (what windows? I thought we were
discussing terminal mode stuff here)

Discussed above. "Windows" here means "logical subscreens
displayed within the terminal emulator window". Again, I didn't
realize that the overlapping terminology would be comfusing.
"My bad", maybe.

and continuing with the thing you
typed, which apparently comes directly out of your fertile
imagination,

No. Everything I'm describing is based on things I've actually
tried and confirmed to work. My descriptions may be confusing,
and I'm sorry about that, but I really am not making anything up.

Again -- I make no claims about whether any of this functionality
is easy to discover, but I was able to figure it out, and it does
exist.

[ snip ]

Nevermind. You've already made my point for me; it's basically
necessary to actually write program code just to edit text with your
tools. And every one of them has its own language too. :P

Well, no, because all my "editing text" can be done with one tool.
That's kind of the point.

(By the way, I think in this group it might be presumption for
me to call myself a developer. I did spend a few years making a
living working on code, but it was maintenance/enhancement rather
than development, and nothing in my academic career has involved
developing anything very big.)

And you've never developed anything from scratch even on your own
time, for your own purposes?

Sure -- but nothing of any size, just little throwaway programs,
or nests of shell scripts. If there were more hours in the week,
or I were willing to devote more of them to things related to
what I do for a living, maybe .... <shrug>

I'm not claiming that these tools I'm talking about are
novice-friendly. They're not. What I'm claiming is that to
someone with the right mindset -- and it probably *is* a mindset
more apt to be found in techies than in non-techies -- they're
far from the unusable mess you seem to be claiming they are.

I'd count myself a techie, but I still prefer tools that just get out
of the way and let me work

Which is pretty much how I feel about the tools I use. Yes, really.

than ones I basically have to consciously
interact with and program to do my work more indirectly, unless the
work is inherently amenable to automation (remove the first three
characters from the names of all 11,435 files in this directory,
say ... doing it manually would be madness).

[ snip ]

What I'm saying, in addition, is that I resent the suggestion
that tools that *are* novice-hostile but expert-friendly are
of no value

You resent it? Personally? Why?

"I'm weird"? Could be. But it's hard for me to imagine someone
*not* feeling a touch of resentment on being told "that thing
you like so much is junk!" Maybe other people's mileage varies.

Fact is, such tools are only of use to
a fixed population: the pre-existing experts. Nobody else can reach
that point, because it basically actively prevents them. As time has
passed since the 70s, that pre-existing population has remained about
the same size or slowly shrank as the older members die off, while the
planet's population has approximately doubled. The more time goes by,
the more irrelevant they will be, given that nobody can use them that
wasn't "there from the beginning" or whatever, and that population
will eventually die off, and meanwhile the number of people in
"everybody else" will double another time or two...

It's valuable to you, and everyone else in that population, but to be
honest, yes, it is completely useless to the rest of the world, and
that's the vast majority.

Could be. Maybe I'm in the same category as -- what's the canonical
example of experts whose expertise is of no current value? makers
of buggy whips? Sad if so, but oh well.

[ snip ]

Maybe not; maybe any signs of "I like this" come across as "and
you should too!!"

I think the latter, especially when accompanied by puzzlement/
disparagement directed at Windows software interfaces. (You can
disparage Windows reliability and security all you want; they honestly
do suck. :P)

My "disparagement" of Windows interfaces falls into two categories,
I think:

(*) I personally find it rather off-putting -- to me it feels like
something designed for people who are more interested in using
a computer for entertainment than for work, and like something
that makes novice tasks easy and expert tasks impossible (or at
least unnecessarily difficult). I'm quite sure that if I knew
the platform better I'd feel differently. But I think that's
true of Unix as well -- people who know it well feel differently
from people who don't.

(*) I think many things about it are not nearly as "intuitive"
as its proponents claim. Sure, if you grew up with Windows
and have put a little time and thought into learning about it,
many things seem easy and obvious. As someone who only came to
the platform ten years or so ago, though, and who has watched a
few non-technical types struggle with it, I think I can say with
some justification that not everyone finds it so obvious.

I've long suspected that one reason I bonded, so to speak, with
Unix is that I learned it in an environment in which there was
a local expert available to answer my questions and get me to
the point where I had a reasonable idea of what kinds of things
were possible and how to learn on my own. Watching him work
was usually an education -- "wow, you can do that? cool!
show me how!" I also suspect that if I'd ever had that kind
of access to a Windows expert I'd feel completely different
about Windows. I don't think it's just a matter of Unix help
being inscrutable and Windows "intuitive", either -- if you
don't know, and can't imagine, that a thing is even possible,
you won't go looking for help on how to do it.

[ snip ]

Well, *you* seemed to think that *my* purpose here was to "convert"
you rather than question your various claims,

"Convert me" might have been the wrong phrase. "Convince me I'm
wrong" might be closer. "Convince everyone else I'm wrong" might
be closer still. You'd know better than I, of course.

especially the ones that seem more outrageous.

As best I can tell, you regard as outrageous any suggestion that
those old text-mode tools might have any capabilities beyond
(1) what was available decades ago on much more primitive hardware,
and (2) what would be immediately obvious to a Windows-centric
new user. I don't quite understand why you aren't willing to
say "well, you know the platform better than I do, maybe you're
right", but -- another <shrug>.

No, I made that up. (Yes, it does. "vimtutor" from the command
line. I don't know if it's on a menu somewhere.)

If we're talking text-mode unix apps, the answer to that would be
"What menu?" ... or even "What's a menu?" :P

I was thinking of a menu in whatever desktop environment is
being run.

We'll gloss over the little matter of how the proper response of a
text editor to the user typing "vimtutor" is to insert "vimtutor" into
the open document at the insertion point. :)

Notice how I said "from the command line" above. That means this
isn't something you do from within the editor.

Just typing "vim", by the way, brings up a screenful of text that
includes instructions for accessing the online help.

We *won't* gloss over the little matter of the unobviousness of this
eight-character sequence. OK, once you know it it's obvious what it
means, but where will you hear that you should type it (and not say
"vimteacher" or "vitutor" or "vt" or ...) in the first place? (Chance
encounters with it in USENET posts in comp.lang.java.programmer
notwithstanding.)

The standard old-Unix way of finding commands related to a
particular keyword ("apropos vim") would find it. Not that that
always works, but in this case it did. Unix documentation isn't
one of the system's greatest strengths, but it's .... No, we've
had that discussion before.

[ snip ]

There are files with names ending .info.gz, which as best I can
tell are gzipped ASCII text representing a "source" for info pages.
Similar for man pages, except the file names just end with ".gz".
"zcat" to uncompress them to standard output produces something
that sure looks to me like 7-bit ASCII.

Eh. Weren't we talking about the .info and .man files themselves?

Yes. On the system I'm using right now, these files exist in
gzipped form, with names ending ".gz" for man files and ".info.gz".
Uncompressing these files gives something that to me looks like
7-bit ASCII.

But that's Fedora Core Linux, and maybe things are different ....

I just tried a short experiment on a SunOS system to which
I have reasonable access, and it looks like there the man-page
files are uncompressed, but still 7-bit ASCII.

(On
the few systems I've used, it's not even been clear where the latter
are, or even whether they exist as such; "man" appears to get the text
it displays directly out of its own *** for all the user can tell.)

"man man" describes how it finds its input files; details appear
to be different on the two systems where I tried it.

The .info files were definitely not ASCII text nor named ending
in .gz ...

Huh. Well, I can believe that things are different on different
Unix/Unix-like systems. I'm reporting on the one(s) to which I
have reasonable access. Which one did you say you were using?

[ snip ]

Windows has a last resort available even so: reinstall the offending
application. Good luck replacing the emacs on a unix box with a fresh
copy with factory-default settings if you're not root.

If you're not root, how did you .... Oh, if the *systems* person
configured it weirdly. Do any of them do that?

I have no idea. If it's as malleable as you claim, it's surely
possible.

Very much so. I just question whether it happens much -- and if
you're constrained to use a system where the system administrator
makes bad choices, you might have worse problems than not being
able to get a copy of the factory-default settings of emacs files.

Then again, you might be able to install your own copy of emacs
in your own directory ....

I think what I'm saying is that this tool you keep slamming --
vim -- interoperates nicely with the GNOME analog to CharMap,
in almost exactly the way you're pitching as being the great
strength of a more-GUI-ish editor.

I don't see how. You might be able to copy from the character map, but
will you be able to paste it into a text-mode app? I suppose that
depends on what the terminal emulator supports.

I'm sure it does depend on what the terminal emulator supports,
but the "character map" application supports copying text into X's
clipboard, and vim seems happy to accept text pasted in from that
clipboard, using the old X conventions.

I tried copying in characters from many different languages into
the same text file (with UTF-8 encoding specified), and *that*
didn't seem to work so well. I'm not sure whether this is a
limitation of UTF-8, or vim, or what. Things seemed to work okay
if all the characters came from a single (additional) alphabet.
<shrug>

[ snip ]

You often seem to me to be claiming that something can't be done
with this tool I like so much, when that simply isn't true.

Can't be done easily, or without help, perhaps.

Where "easily" seems to mean "in a way that would be obvious
to someone familiar only with Windows conventions".

But it seems to me that many times when I've mentioned
something I can do, your response has been along the lines
of "I don't see how that's even possible." At which point
I seem unable to resist explaining ....

[ snip ]

I'd settle for it to easily be found browsing the help, with the help,
of course, being easy to browse, and easily remembered afterward so
you don't close the help, return to your work, and then realize you've
forgotten part of it and need to go back to the help again right away.

That's why it's sometimes useful to have multiple terminal-emulator
windows on the screen.

I know the ability to have the help and your work visible at the same
time with the focus in your work is too much to ask of a terminal-mode
app. :P

So vim must really be going beyond the call of duty:

":help" divides the terminal-emulator window into two logical
"windows" and displays its text in one of them while leaving the
text being edited in the other, and allowing you to switch back
and forth. (Easily? In a way that would be obvious, etc., etc.?
Oh, I don't know. It's all there in the online help, and if
you start with ":help" .... Which begins with instructions for
navigating it. "Whatever.")

And this doesn't even depend on the terminal emulator providing
something not provided by the old text-only terminals. emacs
has been providing similar functionality for years.

[ snip ]

Well, there you are then. :-)

?

If I remember right, you were going on about how difficult it was
to install applications under Unix, and when I asked for specific
examples, two of the ones you mentioned seemed to involve pointing
and clicking. It's my opinion that a lot of that stuff is not
quite as easy to use (or, apparently, install) as some people
might like to believe, and that was the point I was trying to make.
Unsuccessfully, it appears. Not important!

[ snip ]

Huh? really, maybe the way to say it is that hard links are the
normal way of pointing from one part of the filesystem to another,
but there *might* be some restrictions on the circumstances in
which two of them can point to the same place. The "ln" command
won't make a hard link to a directory. It's not obvious to me
that the link() library function has similar restrictions.

I don't suppose you would risk your filesystem's integrity to test
it? :)

No. If I were really curious, I might try an experiment on some
filesystem I could easily rebuild -- maybe using one of those
little USB-connected thingies.

I did a little more Googling, though, and apparently whether "link"
will make hard links to a directory depends on the filesystem in
which the links are to be made, and many don't allow it.

Amazing -- you launch into what seems to be a longish rant about
the idiocy of Unix inventors/developers, based on something I
preceded with "as best I can tell from a quick Google search",
in an attempt to suggest that it might be true or might not.
You *could* investigate, or ask me, before ranting, but -- nah,
what fun would that be?

Investigate what? Their rationale?

No. Whether my guess about when/whether hard links are allowed
is even true.

Assuming they had one, I can't read
minds to find out. I'm forced to speculate.

It could well be documented somewhere, possibly even somewhere
that would be findable with an appropriate Google search.

But I wouldn't want to try to keep you from launching into wild
speculations based on a limited set of facts. It *is* fun,
though I regard it as a guilty pleasure.

The obvious reason is to
avoid circular links, but there are ways to do so without being so
restrictive, and ways to make the system able to tolerate
circularities too. Ways anyone experienced in the computer programming
field should have known about.

Huh. Now I'm curious about whether there was ever a good reason
for this restriction, and what it might have been. Maybe I
should ask in alt.folklore.computers. Sometimes Dennis Ritchie
posts there.

[ snip ]

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
.