Re: Great SWT Program
- From: bbound@xxxxxxxxx
- Date: Wed, 10 Oct 2007 05:19:33 -0000
On Oct 8, 7:12 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
How else do you account for the many, many programs that make
automation difficult if not impossible?
Asshattery, or perhaps just narrow-mindedness and uncaring attitudes.
If it wasn't on the keyboard of one of those old-time text
terminals .... (I can't actually remember whether any of them
had arrow keys and am too lazy to research it.)
I think many of them did, and they're all obsolete cruft now
regardless, so there's really no sense in clinging to them, or, worse,
designing for them. Imagine if some place you tried to do business
with by phone had one of those awful phone-menu systems in place of
live people to assist you ... and they'd designed it to work with, and
ONLY with, ROTARY phones.
The pain ... the horror ...
Sounds like a job for gnuplot. I think I saw something recently in
comp.text.tex about a package that lets you invoke gnuplot directly
from LaTeX.
Cute.
Sounds interesting. When should we look for the first release? (Sort
of a :-) .)
When can you have it ready?
(Sort of a ;).)
My way: Type input for "dc" calculator program into file I'm
editing:
24 7 * f
Type ".!dc" to pipe this line to "dc" and replace it with the result
(168).
I've got a GUI editor on windows that will do something like this,
only it's actually smart enough to report what you wrote there as a
syntax error, while correctly parsing "24 * 7 =". I find it handy, and
it only requires remembering one "arcane" key-binding to use the
feature.
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.
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", unless every line of interest (and no others in the entire
file!) begin with a common prefix, in which case a replace of "prefix"
with "new stuff prefix" will prepend "new stuff " at the start of
every line starting with "prefix". Part of this is there's no way to
tell it to replace a newline, since entering a newline actually fires
off the search rather than inserting it into the query. But that's a
fundamental limitation of the very nature of entering a single line of
text at a prompt or into a one-line field on a form, so there isn't
much that can be done about it without introducing unobvious arcana
into the interface. (I've seen some things that will expand "\n" in a
query into a newline and the like, but this is hardly easy for a
random person to use, although it makes sense to someone like me with
a C/C++/Java background. Of course it also suggests a nasty
possibility for their choice of implementation, that it passes a user
input to printf or the like as a format string, which is likely to be
a security hole -- denial-of-service at minimum, just type "blahblah%d
%d%d%d%d%d%d%d%d" and bet that it will read outside of the stack frame
and probably cause an exception.
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. If
you're going to change them all to start with "Attach: ", the only
apparent way to save typing there is to change them all to start with
"A:" or something and then change "A:" to "Attach: " with a replace
operation. This works if "A:" (or whatever) doesn't otherwise occur in
the document. I don't know what else "manual marking" could possibly
mean in this context, and you'd already indicated that you'd prepend
the "Attach: " using search-and-replace, so obviously the "marking"
must be to put the text to replace with "Attach: " at the start of
each line. If you can come up with a nowhere-else-used two-character
combination, which seems plausible, you can save typing six characters
per affected line this way, but it doesn't obviate the need to diddle
each line manually, and in Windows the clipboard gives a similar
capability as something can be pasted repeatedly with a single two-key
chord per repetition. If we count a two-key chord (ctrl+V) and a two-
letter prefix ("A:" or whatever) as equivalent typing, each involving
two keys as it does, then the two approaches come out about even.
Go to first line. Type command to insert "Attach:" at the start
of the line ("0iAttach: <esc>"). Move down one line, type "." to
repeat the insertion command. Move down one line ....
This seems like the copy, paste, paste, paste ... approach, minus the
chord but also minus any kind of obviousness. Anyone familiar with
Windows will be able to determine, without additional study, that the
clipboard can be exploited to speed up repetitive typing in that
manner. Nobody familiar with Unix will be able to come up with your
method without extensive study of the specific application vim, and
even then won't be able to transfer the knowledge to anything else. I
can use the same method to spam copies of a polyhedron in a 3D
modelling tool on Windows, or to populate form fields (e.g. on a blog
comment form that allows anonymous posting but "pries", to paste "None
of your beeswax" in as the name, email, URL, and etc.) or whatever
else. On the Unix side, it seems likely you need to learn some
different and incompatible version of your vi method in each other app
where you might wish to use it.
vim of course has its own internal clipboard (27 of them, in fact).
Did I hear something feeping?
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. The only things I use that come even close are game-
console emulator save states; there are usually ten of them assigned
to function keys, or else the digit keys, in some way, and either
there's a "current" one and some commands to save, load, and rotate
through them or each function key controls its own (say, shifted to
load and otherwise saves, or vice versa). This can take a bit of
getting used to, and remembering what is where gets tricky. That's
with only ten of them. (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? 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; 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
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
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.
And of course the browser offers to "run" as well as "save"
executables, but to invoke the virus scanner of my choice first takes
access to a saved-file icon. Fortunately, anywhere the system shows
one it shows all file management options installed, including the
"scan" options of the installed virus scanners, so I can scan it
directly out of the browser's save dialog. Then launch it from there.
Then delete it from there. Handy for installers!
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.
Although that file browser probably sucks compared to what I'm used
to. ;)
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? ;)
How broken of it.
I wonder now whether it *can*, but I just don't know it. (Don't
bother to tell me how this demonstrates the superiority of a GUI.
I have little experience with GUI mail programs so can't say how
obvious I'd find this feature .... )
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.
You could with a file browser, but you were entering command lines
blind as I recall.
For suitable definitions of "blind".
I consider "unable to see wtf you're doing" to be suitable as such.
It could do anything or fail spectacularly with one
little typo if you use a relative path or other such prefix and
mistype or misremember something. 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.
Are you calling me a liar?
No. I'm saying [insult deleted]
Oh, lovely. Back to insulting each other then is it? :P
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), 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.
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.
Eh? I don't recall a "!" in the other one, your "ls" example...
It was there, in the original example anyway: "r!ls *.tex"
It was :r! then, not r! and certainly not !anything else. The ! wasn't
first. It wasn't even in the same position, since the other was :!
{ or :!} or something like that.
If this thing even has a syntax as I understand the term, it's
obviously complex and it even seems deliberately designed to thwart
attempts to generalize from known working examples, if things move
around fluidly. That the ! means the same thing even when it's in
different places in different commands is clearly going to lead people
not to recognize it as a common factor. The : *is* a regularity
discernible in your example commands, which makes me now suspect that
(according to the Principle of Maximum Perversity that appears to
govern all Unix UI design) it will surely mean different things in
each case!
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.
The guy that works in the boiler room is used to having thousands of
colored pipes everywhere and valves whose labels have faded or that
have quirks and idiosyncrasies. He'll swear that everything's clear as
crystal and any moron could do his job easily, and he'd be wrong. An
outsider confronted with the same system wonders how anyone can find
anything or do anything properly without accidentally causing a major
flood or other disaster in the attempt, unless he's an expert plumber,
in which case he can probably figure out what does what by inspection
and the unlabeled controls pose no major obstacle to him.
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.
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?
"fmt" might be proven formally, for all I know, or care; the point
still applies since you might launch something that isn't as
thoroughly tested and debugged, with Christ alone knows what
consequences if it then crashes while attached to the editor that also
holds your unsaved work...
And your whizbang GUI tool might crash because of its *own* bugs,
losing your unsaved work.
So might your editor. We're assuming the editor is bug-free but the
callee might not be, here.
We might as well be discussing emacs, really -- emacs fans may not
like my saying this, but I think vim is starting to provide a similar
set of functionality.
With, of course, totally different UI and bindings.
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.
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
100 lines of documentation just to get someone who already knows the
operating system's basics to the point of being able to put "The quick
brown fox jumped over the lazy dog." into a .txt file successfully.
Lovely.
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)
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...
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.
I had a student a while back who liked to remap the keyboard
Dvorak-style. Now *that* was disorienting.
See? Told you so!
Well, whatever. I think I might be about ready to wrap this one
up; it's getting to be too much of a time sink, though it's been
fun in its way.
Hmm.
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? :)
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. ;)
Well, no. vim will display a list of allowed glyphs and the
arcane key combinations, etc. That's admittedly not quite as nice
as what you describe, but it's not as bad as you make it out to be.
As usual.
That's exactly as bad as I made it out to be. You have to go somewhere
else, memorize the key combination, then navigate back to your editor,
the document, and the position you wanted to insert the glyph at
*within* the document, all before the clock runs out and you no longer
can remember the key combination. It's similar to the annoying
usability issues with phone numbers that result from not having
replaced them at least a decade ago (when it definitely had become
technologically feasible) with a name based system similar to DNS. You
get a seven (nowadays, ten) digit number in some voice mail message to
memorize and have to hold it in your head while you delete the
message, go through any others, hang up, and start to redial, instead
of having some way to save it (other than wasting ink and paper, which
cost money, or having a computer with an open Notepad instance by
every phone).
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.
Now that you mention it, I believe you're right. No idea what I was
thinking, perhaps that if you wanted to get RedHat's stuff directly
from them you have to pay. I'm not sure about that.
Even if so it won't stop people torrenting it, and they won't even be
infringing as long as the torrent includes the source. (You
automatically share torrents while downloading them, so you'd be
potentially violating the GPL if you torrented a binary-only copy. In
practise it probably wouldn't matter as anyone who wants the source
can find it, and you weren't modifying it while not distributing the
modifications' source.)
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. ;)
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. 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.
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.
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.
Especially silly given that a directory traversing algorithm that
worked properly on a cyclic graph could have been implemented once, in
library code, as a C function accepting a function pointer of the type
int (*)(const char*) that would be called with each directory (or even
file) name, once and once only for each. (I figured to return a
boolean from the callback to allow the callback to stop traversal,
e.g. if the caller is only interested in the first "hit" of some
sort.) Third-party programmers would only need to use the library
function to do recursive filesystem traversals.
Security can't be the explanation either, since a hard link to say \etc
\passwd won't be world-writable to anyone but "root" any more than \etc
\passwd itself is, and presumably isn't -- it's a *file* so the hard
link is allowed under the *current* system.
Disallowing only hard links that would complete a cycle is also easy
in theory. There's a lot of published algorithms for all of the graph-
related algorithms alluded to in this last section.
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.
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.
.
- Follow-Ups:
- Re: Great SWT Program
- From: blmblm
- 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
- From: blmblm
- Re: Great SWT Program
- Prev by Date: Re: Another noob in trouble! Help me out if you like!
- Next by Date: Re: OT: Unicode and vi(m). Was Re: Great SWT Program
- Previous by thread: Re: Great SWT Program
- Next by thread: Re: Great SWT Program
- Index(es):
Relevant Pages
|
Loading
