Re: Great SWT Program

On Nov 10, 1:05 pm, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
It's a nice place in some ways -- advertisements have little power
[1] to influence our buying decisions

They have little power to influence mine, and I live right here on
Earth. :P

[2] Compare any print medium, or NPR in the US, with US television
news. I guess things could be different in whatever country
you live in.

For real analysis of any news thing I rely more on the internet and
particularly on certain reputable blogs, Wikipedia with its avowed
goal of neutrality, and the like.

"Possible" being sufficient to disprove any claim of an intrinsic
failing of the GUI user-interface paradigm.

Strawman argument.

Bull***. This whole thread amounts to you and Bent saying "the GUI
paradigm sucks" while trying to defend the "doing everything in the
dark with a flashlight between the teeth" paradigm, which genuinely
DOES suck.

Why this isn't happening -- I can only
surmise that there's no demand for the features we find useful.

And there you have it. Your needs are clearly enormously atypical, and
therefore any suggestion that your tools are superior in any general
sense (rather than merely for you and the few other people with the
same atypicalities) is clearly bogus.

I would further surmise that the lack of demand has something to
do with the fact that most people have not been exposed to any
UI paradigm other than the dominant one

Most people that *are* exposed to a "do it in the dark with a whole
lot of extra typing all the time" UI paradigm run away screaming. They
clearly appeal only to a very small minority; pushing them as "better
than GUIs" in such a way as to imply that this applies to everyone
instead of to a very narrow subset of the population is clearly wrong.

This is one reason
I think it's important for the people who may be designing the
software of the future to be exposed to more than one form of UI.

Too bad your preferred choices will mainly just give them some pointed
lessons in what NOT to do in UI design. :)

Not really: mount the appropriate share; fire up editor; type away.

And that probably works fine if the remote files aren't too big,
and your network connection is fast enough -- I mean, if you're
going to open one of those remote files, isn't that going to
involve shipping all of its bits temporarily to the local system?
at least to its memory?

How common, though, is it to need to work remotely with large files
over a dial-up speed connection these days?

In Unixworld we call them "NFS mounts" (if I understand properly
what a Windows "network share" is). How common is it for Windows
shops to allow remote access (i.e., off-site) access to these
shares?

Who said anything about *off-site* access? But it's fairly common, and
fairly secure, via password-protected VPN tunnel or similar.

Even if the schlepping is hidden / automatic / easy, it's still
happening, isn't it? which to me seems kind of inefficient

Not as inefficient as making the user work with a clunky and awkward
interface remotely over a slow connection, I'm sure.

[insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

Yes, as I say a few sentences later, most other
text-mode applications I know of make some use of either the
vi keybindings or the emacs keybindings. Some (e.g., the bash
command shell) allow you to choose either one.

That doesn't make sense. Those are text editor bindings. Apps that
aren't text editors won't generally have any major functions in common
save navigation, which really should just be by arrow keys anyway, and
maybe some form of primitive cut/copy/paste.

And really, this whole thing about keybindings -- I don't know,
but it seems like a bit of a red herring to me. It's nice if
the same keybindings work in multiple applications, and a bit
annoying when they don't, but I guess I'm not convinced that it's
as important as you seem to think.

Well, except that you learn one set and use it. If one of the N
applications you have uses a different set it will always be tripping
you up. Unless you make those bindings the ones you use when you use
the computer, in which case the other N-1 will ALL trip you up. It's
lose-lose.

ESPECIALLY when even basic things like the behavior of backspace and
the keys used for movement and cut, copy, paste can't even be depended
on to remain constant.

Exactly the same as the number of text editors -- what a
coincidence! :)

Why, yes.

In other words, EVERY SINGLE ONE is different to the point of
perversity. Hard to consider something a "convention" when there's
only one of each, hmm?

As someone pointed out a few rounds ago, nothing about how we
communicate with computers is natural. Maybe if you've only
spent significant time with one platform, and you started with
it at an early age, "control-Z to undo" is as natural as breathing.

That doesn't get emacs off the hook for lying to the user about what
will be deleted and it doesn't get vi off the hook for its wacky use
of modes. :P

Just like for me "j to move the cursor down a line" .... :-)?

Oh, j is down? Really, how is anyone expected to form and remember the
correct associations between hjkl and various directions when there's
no obvious connection between them, either geometrically as laid out
on the keyboard or in some sort of letter association? It's
(deliberately) obtuse and difficult to learn when the arrow keys are
right there on the same keyboard, gratuitously eschewed by the
software designer.


Curiously enough, vim in insert mode responds to the Del key by
deleting the key under the cursor. I don't use that feature,
because for me learning the older methods long since became a sunk
cost. But it's available.

You prefer to actually count and then type the number in and "x"
rather than just hold down del until most of what you want to nuke is
gone and then tap it a few times to get rid of the rest? It's a lot
more complicated. Most of the time when I use del it's either to
delete a character (one hit), a word or a few words (hold down for a
bit, then tap), or to the end of the line (shift-end, del). It takes
me a fraction of a second to 1 second in each case, and doesn't
require me to count a possibly-large (30 or 40 sometimes) number of
characters and then type in the resulting number before hitting my
delete key, and then undo if I miscounted and start all over again.
You hate to move your hands a whole lot for some reason; surely you'd
appreciate hitting only del in place of reaching for the number keys
to type several digits first? Or doesn't your OS preference let you
set a reasonably short key repeat delay and a reasonably high repeat
speed so that the hold-down-del method works quickly enough? The only
saving grace for the whole count-em-first way of doing things is that
your software obliges you to view the text in a fixed-width font,
which makes counting characters a little easier than with a
proportional font. On the other hand, proportional fonts have their
own advantages, too, and my tools don't require me to count characters
like that, so I don't incur the disadvantage...

I'm all in favor of what I understand to be the original idea of
HTML -- logical markup, with details of presentation dependent
on user's settings. I'm just not entirely convinced it makes
sense for code.

Why? As long as the semantics (what the compiler cares about) would be
preserved...

.