Re: Great SWT Program
- From: blmblm@xxxxxxxxxxxxx <blmblm@xxxxxxxxxxxxx>
- Date: 10 Oct 2007 15:49:00 GMT
In article <1191993573.285352.310700@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<bbound@xxxxxxxxx> wrote:
On Oct 8, 7:12 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
[ snip ]
Well, okay, another round of "my tools versus your tools" ....
In which I'll at least try to focus on the few things where I think
you might be -- can I say "misunderstanding", or is that an insult?
[ snip ]
The file names might have nothing in common that you can use to
control a search-and-replace so that it "hits" all of them and
"misses" everything else. I don't know what you mean about "mark
them"; automatic marking amounts to the same problem again if they
have nothing in common textually.
These lines are the output of a directory-listing command and are
consecutive in the file being edited. Trying to find them among
unrelated lines is a non-issue.
It's not a matter of YOU finding them among unrelated lines; it's a
matter of the TOOL doing so when it's doing something AUTOMATIC. If I
do a search and replace in a text editor it will look at every line in
the file as a candidate for modifying. That means it may corrupt other
things than just the block of lines you're interested in. You need to
instruct the TOOL to "find them among unrelated lines", presumably by
making the search query not match anything outside of that area. That
means those lines need some commonality that can be exploited in
formulating the search query.
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.
With typical Windows tools, one can select a block of (consecutive)
lines and then perform a search and replace only on the selected
lines, right? That's what I'm talking about here.
Of course, searching and replacing also runs into another problem --
generally there's no way to do something like "prepend to the start of
the line",
Sure there is:
"s/^/text to insert at start of line/"
The "^" character matches the start of the line. As it does in
most forms of regular expressions I know about.
[ snip ]
Manual marking presumably consists
of something like type something, down, home, type something, down,
home ...
Dunno what you mean by "manual marking"; I was talking about either
setting (invisible) named marks, the old vi way, or using vim's
visual mode.
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?
with something that identifies the selected text in some visually
distinctive way (highlighting, different color, something)?
The old vi way is invisible and a bit clunky. The new vi way is
similar to what you do in Windows, but with different key bindings.
(No need to point out the awfulness of that.)
No need to put a unique identifier string into each line to mark
start-of-line, though, since inserting something at start-of-line
is straightforward.
[ snip ]
vim of course has its own internal clipboard (27 of them, in fact).
Did I hear something feeping?
I don't know, did you?
Yes, I do believe I did. I can't see having more than one or, at most,
two of them as providing the user with anything but unmanageable
complexity.
Well, there's the default one, and then there are others identified
by letters. If you're going to identify them by letters, simpler
to have 26 than 2, wouldn't you say? Maybe no one really wants all
26, but once you've made the decision to identify them with letters,
why not? rather than decide whether the right number is 2, or 4,
or what.
[ snip]
(How do you find out what's in one? Load it.
What happens to your current state? Better save it first. Of course,
which slot do you save it on without clobbering something you wanted
to keep?
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.
Can't check them all first without losing the current state
after all. Oops. So you'd better remember, or else set aside one save
to never put anything important into that can be used for very quick
save, do something, reload. Not that any of this matters a whole lot
because it's just games. You're talking juggling nearly THREE TIMES as
many "clipboards" when attempting to actually do something PRODUCTIVE
here.
I hadn't realized it was possible to use a file-selection box to
select multiple files matching a pattern. That does sound useful.
It depends. Annoyingly sometimes multiple selection doesn't work;
But your platform is consistent and intuitive, while mine isn't?
(No, no, I'm not making a serious argument that mine's better,
particularly for everyone, just taking advantage of the opportunity
to observe that apparently yours isn't perfect either.)
it
seems to be up to the application designer. Conveniently, though, it
usually does. You can always filter the files displayed at least to
those with a particular extension, so if you want "all the .tex files"
you can display just them, and ctrl+A to select them all if multiple
selection is supported. Or you can manually cherry-pick the files
using ctrl-clicks, handy if the ones you want have nothing in common
filename-wise that would let you specify them precisely in any more
automatic manner. Helpfully, every file dialog in Windows tends to
"tends to"?
support sorting by name, date, and other characteristics (so least-
recently-modified files can be grouped for instance). They even behave
somewhat as general-purpose file browser windows. This means if I want
"somewhat"?
Probably you mean "things work consistently a lot more often than
not." But. <shrug>
to e.g. copy a document file I don't need a separate window open on
its directory; I can go to the document itself, alt-F-A for "save as",
and probably have a window open to the document location, with the
correct file already selected by default, that does allow me to copy
it and even rename the copy and the like. This is also handy with the
Web browser: I don't need a separate window open on the directory I've
configured it to save downloads to. I can download something, and then
go to download another copy just to generate the save-as dialog open
to the location of the already-downloaded file, with it selected. Then
I can right-click virus scan it, run it, copy it, move it, rename it,
or whatever to suit. Of course I could have renamed it when I first
downloaded it but maybe I think of doing so only after a while. I
could navigate to wherever else to save it to a particular location,
but it's more convenient to keep a different window open to any such
task-related "particular location". Then I don't have to navigate the
browser's save dialog to different folders after every save, or at
least every download with a different destination than the last; I can
save it to the generic location, then reopen the dialog and drag the
file to another open window to move it. The only navigation now needed
is to find the right destination window, not to navigate the whole
file tree, if the destinations I tend to use tend to be kept open in
windows much of the time.
Hm .... What you seem to be describing here is saving things
to a central "temporary storage" location to avoid having to do
too much navigation in file-selection dialogs, then moving them
to where you want them -- which sounds like a great idea to me,
but seems a little like the "lots of temporary files cluttering
things up, just to get around the lack of a clipboard" thing you
were saying about my preferred tools a while back. And that *is*
sometimes a problem.
[ snip ]
As for cherry-picking files from all over .... Perfectly possible
from mutt; for that I'd do the attaching from its (text) menu,
which allows for browsing the filesystem.
Sounds like the crummy "Attach: " issue is completely avoidable anyway
then.
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:".
Although that file browser probably sucks compared to what I'm used
to. ;)
Probably by your definition of "sucks". No pictures, but other
than that, it seems pretty much like the text equivalent of what
I'm familiar with from the Windows world (ability to descend
into a directory, go back to the parent directory, search for
(part of) a filename [*]). No, wait, I don't think it allows
ordering by date rather than name. I guess I can imagine that
sometimes being useful.
[*] 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.
Turns out, too, that you can attach multiple selections from a
directory at once (with mutt); there's just not a way to select
them other than individually (i.e., no "all that match a pattern").
Wow, I'm learning lots of helpful stuff about these tools you want
me to abandon. I think your efforts to convert me are backfiring
to some extent, though I'm also getting some helpful tips about
what's possible on your preferred platform.
Which you can do -- except that it's all text, and I don't know of
a way to select multiple files matching a pattern.
Ick. See? ;)
[ snip ]
Thing being, anyone familiar with Windows idioms would be able to
manage this in a completely unfamiliar mailer (e.g. Eudora on some
machine at their new job, and they've only ever used Outlook or
Pegasus or something at home), unless that mailer specifically
thwarted it by disabling multiple selection in the file-open dialog
deliberately.
Unix tools may simply be missing the feature through oversight (on
Windows it takes a deliberate design decision, either not to use or to
set particular flags on the standard file dialogs), and where they
have it, it won't be findable by a novice user. It won't matter if
they have years of Unix experience and experience with another Unix
mailer, it simply won't be findable if they have none with THAT
SPECIFIC mailer.
Ugh.
Yeah. Different and not-entirely-compatible key bindings -- it's
an annoyance. I'm willing to put up with it to get something I
think is of value in exchange. <shrug> You don't have to make
the same tradeoffs if you don't want to -- and clearly you don't.
[ snip ]
And of course typing the command in
the editor you don't even have the benefit of whatever autocomplete
functionality your shell might provide...
Actually you do. (I suspect a lot of those text-mode programs
use the readline() function, which provides that autocomplete
functionality as well as a command history.)
I don't see how. The editor is not the shell. It could have a history
for commands typed, but I don't see it being able to autocomplete say
file names when it has no clue that you're even specifying a file name
because you're entering something for the shell (not the editor) to
parse that the editor therefore doesn't know how to parse.
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.
Maybe I'm hallucinating, though, or deliberately lying to you.
I'd say "why would I do that, when it would be so easy for you
to check" -- but apparently it wouldn't be so easy, and I wonder
whether you'd do it if it were. More fun, apparently, to rant.
Not that I'm never guilty of that myself. But I do usually say,
when I know I'm spouting some opinion based on sheer prejudice
and almost no actual information, something about how much fun
opinions based on zero knowledge are.
Are you calling me a liar?
No. I'm saying [insult deleted]
Oh, lovely. Back to insulting each other then is it? :P
I guess so, since any suggestion that anything you say could be
wrong for any reason is apparently considered an insult. For some
reason I'm unwilling to refrain from challenging things I believe
to be factually untrue just because doing so would offend some
anonymous poster with a very sensitive threat-detection system.
If you're willing to navigate the filesystem using autocomplete
features. Not quite as pretty as point and click, but far from
unusable. In my opinion, I guess.
Even if you somehow have filename autocompletion in *the editor* (and
not in a dedicated file-selection prompt or dialog either),
But when else would it be useful?
this is
like feeling your way along a darkened maze instead of running pell-
mell until you hit a wall face-first. It's slow and awkward, but at
least it doesn't injure you. OTOH, a proper filesystem browser lets
you see more than just one thing at a time, but all its siblings too,
and information such as type, size, date modified, how many things are
with it in its directory, etc.; this is like turning on the lights.
Autocompletion on a one-line prompt is at *best* like poking around in
that maze with a weak flashlight with a narrow cone; and without
autocompletion you're just walking around in it until you hear the
crunching sound of your nose impacting concrete.
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.
Yes, invoking interactive tools .... In practice that seems not to
come up.
Strange, since interactive tools are vastly more usable than "wind
them up and let them loose while blindfolded" ones.
Apparently not in my world. But then my thinking is no
doubt strongly influenced by years of using lots of little
non-interactive Unix programs to do things.
[ snip ]
If this thing even has a syntax as I understand the term, it's
obviously complex
More complex than "press F1 to get help", yes. I'd say it does
have a syntax that makes sense once you understand it, but I'm
not interested in providing further examples or trying to give
a condensed explanation. I'll track down an explanation if you
actually want one, but I doubt you do.
[ snip ]
Perhaps, but it seems messy tangles of cabling are hanging out of an
open case instead of being neatly packaged here. At least software
doesn't get prone to dust getting in and screwing up the heat
dissipation mechanics, so it's only a usability/esthetics problem when
the system's guts are exposed to the user.
That's not how it appears from my perspective; from my perspective,
vim hooks seamlessly into a system/paradigm I find familiar and
useful.
As a developer yourself your ability to see it objectively may be
questionable. In particular you're used to playing around with the
plumbing/guts of a system.
Yup. That's probably why it appeals to me.
(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.)
[ snip ]
As a programmer, you likewise may not be so bothered by interfaces
that make you hand-hack text files, or mess with plumbing of
components manually, or similarly, or even really notice that it's
like that. To a typical user, though, the systems you seem to enjoy
using are baffling, overcomplicated, and underdocumented -- at least
as regards what they get through what documentation browsing
functionality they actually successfully manage to use. Someone more
detached from the system will inevitably have major problems and poor
productivity without a huge time investment in lots of rote
memorization they can't justify given the existence of tools like
Notepad that are adequate and easy-to-use.
Do I need to say this again -- apparently I do:
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.
Unless "usable" means "must be usable by complete novices with
no training."
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, and those who think otherwise should just get used
to using whatever the mass market will accept. Leslie Lamport,
of LaTeX fame (infamy?), has a great rant along similar lines,
in an interview from some years ago. I'll track it down if
there's interest.
Perhaps *this* is the "unix paradigm" you were claiming earlier solved
the key bindings problem magically somehow and let someone use all of
this stuff easily; perhaps it's "being a programmer". Well, I am one
and I don't find those things any easier to use, probably because I
want to simply sit down and get some work done on my *real* work,
rather than study the ins and outs of these tools for the fun of it.
If you study them as a programmer, perhaps studying their source code
or approaching them as a language to program in rather than just a
tool to do work with, perhaps you do better at learning them and
finding them usable -- but it involves "task switching" of a sort, all
the same.
Could this be it?
For me the effort of learning some of these tools is -- I think
economics has a term "sunk cost" that applies? I learned vi
a long, long time ago, when I'm not there *was* a Notepad, or
at least not on the platforms I was using. (I chose vi over
its competitors because it seemed to be more cross-platform.)
Now that I've put in the time of learning it, it seems more useful
and pleasant to build on what I know rather than dropping it in
favor of something that to me seems uncongenial. <shrug>
Admittedly my time might be better spent learning something
other than tool intricacies. But that's not a question I want
to discuss in public.
[ snip ]
As for it taking many hundreds of lines to explain the basics --
I'm not explaining basics here; I'm describing some features that
make the tool attractive to *me*, as someone steeped in the Unix
mindset and willing to do some learning.
So far though there's been no indications that anything would make the
tool attractive to Joe User who just wants to get some work done and
hasn't got the time or inclination to do the equivalent of take an
extra, not-for-credit CS course on the side.
But I haven't been trying to do that. Did you think I was?
Why? I'm trying to explain why *I* like it, and why I think
it's useful as a horizon-broadening experience for CS majors.
I'm not trying at all to pitch it as something everyone should use.
That's never been my intent, and I thought I had made that clear.
Maybe not; maybe any signs of "I like this" come across as "and
you should too!!"
I do wonder whether anyone else is similarly confused about my
purpose here, but -- <shrug>
Well, the first lesson in the interactive tutorial, which I think
is enough to get people started, runs to .... just over 100 lines.
It has one? :P
No, I made that up. (Yes, it does. "vimtutor" from the command
line. I don't know if it's on a menu somewhere.)
[ snip ]
Sure it does; if I wanted to hand-hack a man page, I'd uncompress
the source, get a text file, modify it, compress it. Same as if
I wanted to change a PDF file produced by LaTeX -- I'd edit the
LaTeX source and rerun commands to generate the PDF.
That's not the same. A PDF file is a generated file with a source file
somewhere. Last I saw, .info files were not plain 7-bit ASCII nor was
there any obvious tool to use to edit one or generate one from some
source format. You're now claiming it's simply gzip, but if that's the
case why aren't the files .gz files, which would communicate that
fact? (Ditto man files)
On the systems to which I have easy access (Fedora Core), they are
(.gz files):
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.
I just tried uncompressing source for a man page, editing it,
compressing it, and viewing the result with "man". Seems to work.
Of course this "source" is input to a text-formatting program
I don't know (nroff/troff). But -- <shrug>.
Emacs. It's so changeable and configurable that if you use a copy that
isn't exclusively yours you have no way of predicting how it may
behave. The previous user might have rebound every key to "blink and
beep" to make it emulate vi, for all you know. ;)
But this is kind of a problem with any system that's configurable,
isn't it? (By the way, emacs does have a "vi emulation" mode.)
Feep, feep...
Or "have it *YOUR* way". As opposed to "my way or the highway".
<shrug>
If I run into configurable Windoze software that's been configured
"weirdly", I can use the mouse to find everything ... or at least go
tools, options ... and configure it to behave "normal" from there. An
emacs in some odd configuration will run across the problem that even
the equivalent of "tools, options" may have been rebound to ctrl-alt-
meta-shift-7 or something equally unguessable.
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?
[ snip ]
You didn't ask. I actually didn't know -- needing something like
this just doesn't come up very often for me -- but it turns out
that there's something called "Character Map" in one of GNOME's
menus, and it behaves very much like what you're describing.
It's probably more or less a direct clone, given it has even
essentially the same name. Icon looks like a key cap by any chance? :)
A group of key caps, yeah.
But you'd need to demonstrate a way to get equivalent functionality
*in text-mode* before I'd consider it a defense of the vi way of doing
things. ;)
("But it doesn't paste to the clipboard!" ? Actually I think
it probably does paste to GNOME's equivalent of that; it also
pastes to X's possibly-primitive clipboard. I didn't have any
trouble getting some Cyrillic characters pasted into a file
being edited with vim.)
But ... but ... but using a graphical tool is cheating! Actually, it's
making my case for me so I should just let you go right ahead and keep
doing so. ;)
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.
Would *I* use it that way, for more than casual/occasional use?
No. But I doubt you use CharMap to enter large amounts of
text either. Or do you?
[ snip ]
Yup. As long as you say things I believe to be factually untrue,
whether deliberately or not, I'll consider myself free to dispute
them.
The problem is that you're believing things I say to be untrue, even
though that is never the case.
Perhaps I'm misunderstanding you, then:
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.
What *is* true is that a lot of the functionality is hidden
behind an interface that Windows users will not find familiar or
necessarily comfortable, and which not everyone would be willing to
learn. If you think functionality only "counts" if it can easily
be found from a GUI, well, we'll have to agree to disagree there.
[ snip ]
And yet there's a regular in alt.folklore.computers who claims she
was able to teach non-technical people all they needed to know to
be productive with TECO in an afternoon. But that was long ago.
Given that non-technical people (that know Windows basics, i.e. most
in the developed world nowadays) can be taught all they need to know
to be productive with Notepad in an instant ... this doesn't seem all
that impressive. Still beats weeks (vi) or months (emacs) I guess. ;)
Well, my understanding is that the afc regular was talking about
teaching TECO to people who had never worked with computers at all.
So a fair comparison would be introducing someone to basic Windows
usage and then turning them loose on Notepad. An afternoon might
be enough time for that, though I'm a bit skeptical.
That you seem to have a knack for getting Unix to misbehave.
Well, XFMail was point-and-click. So was the misbehaving icon editor I
mentioned.
Well, there you are then. :-)
And the filesystem corruption I've seen has been secondary
to things like those causing graceless reboots and things like power
failures that are completely beyond J. Random User's control.
Does Windows cope any better with those situations? I guess it
could, if it always writes disk changes out right away rather
than caching them, and it never in the process of crashing writes
out junk.
If I'd been doing something dubious at the command prompt as root each
time, then you might have a point here. :)
Actually I think I was wrong about that: It's not a restriction
imposed by the implementation, because the ".." entry in a
directory, pointing to its parent, is apparently a hard link.
I'm guessing so is its name in its parent pointing back to it.
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 guess it could be one more thing for me to investigate, because
now I'm kind of curious.
As best I can tell from a quick Google search, disallowing other
hard links to directories is an attempt to avoid some sort of
unbounded recursion. You're right that it seems like an annoyingly
inconsistent restriction.
I guess they don't want recursive subdirectory stuff to end up going
in circles. Apparently they assume anyone programming for their
environment is too dumb to know how to implement a traversal of a
cyclic graph, and they themselves were too dumb to figure out how to
selectively ban only links that would create cycles in a formerly
acyclic graph.
It figures.
[ snip ]
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?
I am able to get meaningful information out of man and info pages,
and not because of some superhuman powers, either (which I don't
claim to have, an assessment with which I'm inclined to think
you'll strongly agree).
Superhuman patience to read the entirety of 300-page documents counts
as "superhuman powers", I'm sorry to say.
If I were doing that, I might agree. But I'm not. Probably I
*have* read hundreds of pages of Unix documentation over the years,
but usually it's been in smallish chunks. If you can claim to have
learned everything you know about your platform without reading
a lot of help pages, possibly adding up to hundreds of pages,
well, good for you. <shrug>
Not to mention that sometimes in skimming through a man page in
search of one thing one sometimes learns something nifty but
unrelated -- the serendipity thing that used to happen in looking
things up in a hardcopy encyclopedia.
Insert mode versus command mode. I thought you had used this tool,
at least a little.
Just enough to swear at it and start praying that control-C did the
usual unix thing of abort-process.
Well, then I apologize for assuming that what you know about it was
based on *some* experience, rather than guesses.
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
.
- Follow-Ups:
- Re: Great SWT Program
- From: bbound
- Re: Great SWT Program
- References:
- Re: Great SWT Program
- From: bbound
- Re: Great SWT Program
- From: blmblm
- Re: Great SWT Program
- From: bbound
- Re: Great SWT Program
- Prev by Date: Re: How to solve this issue Urgent pls help
- Next by Date: Re: "WHILE" Loops
- Previous by thread: Re: Great SWT Program
- Next by thread: Re: Great SWT Program
- Index(es):
Relevant Pages
|
