[29324] in Perl-Users-Digest
Perl-Users Digest, Issue: 568 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jun 24 03:14:42 2007
Date: Sun, 24 Jun 2007 00:14:12 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 24 Jun 2007 Volume: 11 Number: 568
Today's topics:
Re: The Modernization of Emacs: terminology buffer and <twisted0n3@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <twisted0n3@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <twisted0n3@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <twisted0n3@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <dak@gnu.org>
Re: The Modernization of Emacs: terminology buffer and <dak@gnu.org>
Re: uninitialized value <tadmc@seesig.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 24 Jun 2007 03:59:24 -0000
From: Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182657564.912472.55570@g4g2000hsf.googlegroups.com>
On Jun 23, 10:36 am, Martin Gregorie <mar...@see.sig.for.address>
wrote:
> However, there's a case he missed, probably through never using a CAD
> system. All the good ones can be driven either by mouse, or by
> non-chorded key sequences or any combo the user likes. The essence of
> CAD is very accurate pointing but all too many mice move slightly when
> clicked. Fortunately a decent CAD system offers the possibility of
> purely pointing with the mouse and doing everything else with the other
> hand on the keyboard. The result is both fast and extremely accurate.
Actually, what I prefer in (2D and 3D) visual design apps is the
ability to snap to some kind of grid/existing vertices, and to zoom in
close. Then small imprecisions in mouse movement can be rendered
unimportant.
> An interface design point that nobody has yet mentioned here is that
> there are four different types of user that map onto a grid:
>
> casual dedicated
> untrained 1 2
> expert 3 4
>
> I first ran across grid this in "Design of Man-Computer Dialogs" by
> James Martin and its been very useful in systems interface design.
>
> The problem with almost all current GUIs is that they are aimed at types
> 1 and 3 users - this certainly applies to Windows, OS X and Gnome
> desktops with the emphasis on type 1. vi and microEmacs, OTOH, are aimed
> at type 3 and 4 users.
The problem of course being the complete exclusion of type 1 users.
Everyone starts out as type 1, and I don't think type 2 occurs in
practise. You'd have to be some kind of religious nut to be
"dedicated" while still "untrained", rather than only as a result of
experience. Apps that provide no traction for a type 1 user will not
see much adoption except in an environment of immersion, mentoring, or
desperation. I wonder which of the three explains the majority of
emacs users, and of vi users, and whether those prove to be the same
one. :) (Actually, there'll be a single or a small number of class-2
users: the original developers, who presumably became dedicated before
having much experience *using* the tool. Their experiences are
atypical however, and their knowledge of the internals probably means
they're type 4 by the time they actually use it to do more than debug
it. Unsurprisingly, never experiencing it as a type 1 themselves they
tend to be inconsiderate of future type 1 users...this is normal, and
requires effort to avoid, in much the way blinkered views of stuff and
seeing what you want to see can be normal, and efforts like using
double-blind studies may be needed to avoid bias in evaluating, say, a
new drug. That such efforts are needed should not be seen as
disparaging the programmer or the drug-studier, but as merely
reflecting human nature, and as a simple pragmatic requirement if one
is to maximize utility.)
> Its very difficult indeed to design an interface that suits both
> untrained and expert users.
One with a bog-standard UI but also a "console" or command prompt,
scripting language, and customizable bindings?
Funnily enough I can count the software I've seen with that range of
capabilities (so able to satisfy type 1, 3, AND 4 users) on one hand.
Here's the list, in fact:
ROM BASICs and QBasic (on any really ancient microcomputer, and old
pre-Windows PCs, respectively; the former came with printed manuals
and you could just run prepackaged software from disks very easily;
QBasic had mouse and menu support, but an immediate mode command line.
You might not count ROM BASICS as as friendly, due to the lack of
menus and such, but then at that time in history NOTHING had menus and
such! And comprehensive introductory use manuals came with those, and
with pre-Windows PCs (DOS also had a decent and easy to navigate help
system). Most other BASICs and programming environments more generally
lack an integrated environment with an immediate mode prompt. Eclipse
actually sort of does, but the evaluate line can't be used really
arbitrarily and I've found it touchy, and rarely use it.
Hypercard (found commonly on old Macs; had a command prompt you could
access to directly communicate to an interpreter).
Fractint (fractal graphics making software for old pre-Windows PCs;
had a similar prompt, accessed by typing 'g', but also had extensive
help and menus readily controlled by stock keyboard commands such as
the arrow keys, and later a Windows port with menus and mouse
support).
Quake and descendants (yes, the games. Easy to just use the menus and
play the game. Advanced users could hit ~ to drop down a console and
do a few things. Really advanced ones made config files to rebind
weapons and make chat macros to fire off a taunting sentence with a
single keystroke -- no more embarrassment getting fragged while typing
it in longhand in mid-game. Super-advanced ones got at the QuakeC and
made bots, flag-capture mode mods, and other enhancements and
utilities. And sometimes cheats.)
There's probably some more out there, but I've yet to see such
desirable things as:
* The paint program with the usual interface, except you can also do
stuff like hit ~ and type "resample files:c:\foo\*.jpg width:640
height:480 preserveAspectRatio:true doNotEnlarge:false"
* The word processor with the usual interface, except you can also do
stuff like hit ~ and type "format leftIndent 2 where paragraph begins
'Quotation: '"
* The word processor with the usual interface where I can define
logical styles, then change them in only one place and affect every
pre-existing occurrence retroactively.
* The word processor with the usual interface where I can also view an
underlying markup representation and hand-hack that, and which likely
has the capabilities of the first two as a direct consequence of the
implied architecture. Only please, proper functional markup, not
macros like LaTeX or (shudder) winword. I don't want it to be possible
for documents of dubious origin to make it start sneezing, or any of
the general ugliness that follows TeX around like its shadow.
Documents that look as nice when displayed and printed, sure, but just
as nice under the hood if you please.
* Something as powerful as Mathematica, but with a more
straightforward basic-use interface as well as access to a fancy
interpreter.
* The operating system where you can do powerful stuff with a command
line and a script or two, but can also get by without either. (Windows
fails the former. Linux fails the latter.)
* For that matter, the operating system whose GUI takes the concept
behind OLE to its logical conclusion, and lets the user separately
choose and configure their text editing, this-editing, that-editing,
whosit-viewing, and the like components, and those components are used
in building more complex applications. All the alternatives would of
course adhere to a common interface for a particular sort of
component, of course. (An OO language like Java lends itself to this,
what with interfaces and inheritance and dynamic class loading!)
When I run my browser and go to GG to make a post I'd get a text entry
field that was actually my choice in a box, with the usual
capabilities such as spellchecking available, and its own little menu
bar at the top and suchlike. I'd be able to save the contents to disk
without futzing around with the clipboard and launching Notepad, and
later reload, in case the web site was prone to eating the odd
submission. My Jave IDE would display code in the same editor (the
interface should therefore support the using application externally
driving coloring/highlighting, as well as jump-to-line and similar
capabilities). Of course the editor wouldn't itself be Java-aware,
which might not be useful, for example composing a usenet post.
Instead it would provide a variety of abilities to the embedding
application, which may or may not use them. What it would provide
being its particular internal search, spell check, key bindings, etc.
> About the closest I've seen have been
> keyboard driven menu structures which have been designed so the user can
> build their own "command sequences" that traverse menu levels without
> showing the menus, as long as items are selected correctly from each
> level. Many CAD systems approximate to this but I've yet to see a
> graphical desktop, IDE, or editor menu structure that came close.
The bog-standard alt, this, that sequences on Windows "come close";
they do make the menus display, but otherwise they do exactly what you
want, and you can ignore the menus blinking around in your peripheral
vision. When I go to save a file with unsaved changes my first
inclination is ctrl+S; if the app doesn't support that the very next
thing I try is alt, f, s, before resorting to the mouse.
------------------------------
Date: Sun, 24 Jun 2007 04:57:20 -0000
From: Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182661040.286559.150880@q75g2000hsh.googlegroups.com>
On Jun 23, 2:04 am, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
> Of course, emacs doesn't take years of mastery. It takes 30, 40
> minutes.
I gave it twice that, and it failed to grow on me in that amount of
time.
> > Besides, ANY interface that involves fumbling around in the dark
> > trying to find a light switch is clunky.
>
> That sounds like vi, not emacs.
That sounds like any application where you need to read the help, but
"f1" does not bring up a separate help window, switchable with the
main one using alt-tab or the mouse, and navigable using arrows,
pageup, pagedn, and the mouse. The result of that is invariably that
when the document has the focus, the help is open to "help on
switching windows" rather than whatever you need it to be on once the
document has the focus. You can read the help on doing what you want
to do with the document, but to apply it you need to transfer focus
back to the document. If doing that isn't second-nature, you have to
navigate the help away from where you need it to get the focus back to
the document. Now the focus is on the document, but the help you need
isn't displayed next to it anymore. Frustrating? You can't begin to
imagine, I suspect. Apparently, some people are born somehow able to
avoid this problem without having to memorize one or the other piece
of help. You're clearly one of those. I am equally clearly NOT one of
those. Of course, if emacs let you keep THREE windows open and visible
at the same time, instead of being limited to one or a horizontally
split two ... and a cramped 80x10 or so each, at that ...
> > Applications that not only eschew normal methods of navigation of the
> > interface, but force you to fumble your way between the help and the
> > task you're trying to do, are definitely clunky.
>
> a) emacs doesn't 'eschew normal methods of navigation'; it's been doing
> its own thing since before there _were_ Mac OS or Windows
I'll admit that it didn't USED TO 'eschew normal methods of
navigation', but at a certain point in time there began to be 'normal
methods of navigation' and emacs naturally began eschewing them
promptly and has done so ever since.
> b) I believe you've never used the emacs tutorial, which is quite
> definitely designed for you _not_ to have to fumble around between
> windows
If I haven't, it must be the case that finding this tutorial (or even
discovering that it exists) was nontrivial, or it wasn't built into
emacs, one or the other. My memory is somewhat fuzzy after all these
years so you'll forgive me if I don't make a definite statement about
which. On the flip side, if I have, the tutorial can't have been all
it's cracked up to be. Especially given I can program Java
proficiently, including some fairly sophisticated network-using tools,
and clearly am not an idiot or untalented in technically demanding
areas involving substantial amounts of arcana. Of course, I might have
put more effort into learning effective Java; effort like that in
learning some language is necessary to being a programmer. Thanks to
modern editors and IDEs, putting a comparable amount into learning the
mere mechanics of operating a text editor is not necessary, and I
chose to spend the time and effort elsewhere, where it was necessary,
such as on learning a programming language.
The technical term for managing limited resources, such as time and
effort, first where needed and never where avoidable, is "efficiency",
in case you were unaware.
> > The interface never improved over that time -- the biggest problem
> > consistently being that whenever focus was successfully transferred to
> > the document window, the help window was invariably open to the
> > instructions for switching windows, so you could never be doing
> > something with the document and have the help for that something
> > available at a glance.
>
> That doesn't even make sense. Either your memory is faulty
Impossible
> you've never actually used emacs
Untrue
> or you're just making things up.
Also untrue, and you've just accused me of incompetence once and of
lying twice, which in a formerly civil discussion constitutes behavior
that I consider to be in poor taste.
> If I'm browsing the manual
> online, I can switch from said manual to my document buffer without
> making the manual scroll to the documentation for switch-to-buffer.
Apparently because you find the switch second nature, despite its not
being the obvious (which is ctrl-tab, to switch between documents in
an MDI app). Cheat sheet? Memorized with painstaking months of hard
effort? Thanks for proving my point, either way.
> In fact, I am not aware of any package which auto-changes the *info* or
> *Help* buffers to reflect the last keyboard command.
I didn't say it auto-changes. It manual-changes. The exact sequence of
events that causes this with a novice user being:
* Need to do X, and the usual command doesn't work (e.g. go to save
document and get search prompt)
* Now nothing much works (typing stuff bleeps), hit esc a bunch of
times
* Now it complains of hitting esc too many times, but typing into the
document at least works again
* OK, time to resort to *gulp* the help.
* Oh, great, now what did it do? I hit F1 and ...
* Eh. Try random stuff. Help starts with h. Alt-h? Ctrl-h? ...
* Oh, right. I seem to remember the help popping up unwanted when I
tried to backspace over a typo earlier, so I'll just do that.
* Hrm, now how to search the bloody thing?
* <Hours pass, some spent trying ctrl+f and ctrl+s, mostly
fruitlessly, followed by a load of scrolling>
* Ah. "How to do Foobar to your open document". Perfect!
* Oh crap. How do I do anything to my open document, when the focus is
on the help instead of the document?
* <Scrolling for ten minutes>
* Ah, I hit this. It worked!
* Oh, fudge. Where did "How to do Foobar to your open document" go?
The help's open to "How to switch windows". For shame.
* Switch back, scroll ... there it is.
* Crap, now I don't remember how to put the focus back on the document
window.
* More scrolling.
* Oh, fudge. Where did "How to do Foobar to your open document" go?
The help's open to "How to switch windows". For shame.
* <however many repetitions of the preceding 4 lines>
* Error: Stack overflow. Dumping core.
I trust you get the picture.
[snip]
Whoa, what did you just say? Page 899 of the ... good Christ. Er ...
Run! Flee! It's a monster! Head for the hills! Sound the civil defense
sirens, tornado TORNADO! *runs*
> > Infrequently used commands you can stand to hunt for in menus. When
> > you find you use one frequently, you can try to learn the keyboard
> > shortcut -- and you can find it without even consulting the help,
> > simply by finding the command's menu item.
>
> This is no different from emacs. There's a menu bar
What are you blithering about? Oh, great, now I'm using the term
"blithering". :P But ...
WHAT menu bar? We're discussing emacs. As in, a text-mode editor. As
in a cramped little 80x24 grid of letters, numbers, spaces, and
punctuation with no menus, no concept of a pointing device, and a bad
attitude.
Actually, the big thing the GUI and mouse did was rescue us from
escalating UI problems with tasks complex enough to require modes. You
needed either separate components with separate associated
functionality and a "focus" to move among them, or you needed commands
and keyboard-toggled modes. The former got you an emacs and the "can't
switch back from the help" syndrome, and the latter got you ...
something vile.
Until the GUI-with-pointing device, which made user control of a
"focus" a snap requiring virtually zero learning curve, and better
yet, what little learning there was being transferred readily across
applications. Unified windowing systems, with Macs and Windows,
cemented the victory of the pointing device over the problem of focus
management. Point at the thing you want to use next and click; that
simple. A child can do it. Using a GUI is like doing a job yourself,
such as washing the car. Using something from the dinosaur age,
especially afterwards, feels like sitting back and directing some
hired help. Help that happens to be blind as a bat as well as having
the usual poor grasp of English. "Left, Senor. Right, Senor. No not
THAT far right! Now you've gotten it all into the open drivers-side
window, and those documents I left on the front seat are ruined!"
Ouch. Yet trying to control old text-mode tools is pretty much exactly
the same, only the flawless English it speaks belies an even dodgier
grasp of same, or even the need to speak to it in some obscure dialect
of Greek full of "meta" instead...and it doesn't apologize when
there's a screwup a more hands-on interface would easily have
prevented.
If you want a job right, do it yourself. With a mouse, you can; no
need to speak an obscure variant of Swahili into a keyboard just to
get the focus to the document from the help or wherever. And to top it
off, every Windows app understands tab and alt-tab and most understand
ctrl-tab. Actually, the OS GUI components themselves understand alt-
tab, and the applications just get told the focus went elsewhere or
came back, making it one less area for application designers to screw
things up. (All too often, they screw up ctrl-tab in tabbed/MDI apps,
or screw up tab by using a dodgy tab order or controls with no visual
indication of focus, mind. And then you can just resort to the mouse,
rather than throw up your hands or find something non-electronic to
sob into so as to avoid ruining another $40 keyboard.)
> You've actually hit on another advantage of emacs: consider emacs itself
> as an operating system hosting multiple applications, in which the vast
> majority of commands are the same.
It's an "operating system" to precisely the extent Windows 3.1 was.
It's like Windows 3.1 in a number of other ways too, including size
and aesthetics, though not stability. Even more like its predecessor
DOSShell.
Take that however you wish.
At least Windows 3.1 had most apps have the same keys for the vast
majority of commands, and those were the right keys. Emacs has all the
applications have the vast majority of their commands use the same
WRONG keys. Including whatever you'd use to rebind them. And the help
you'd use to find out what the damn keys are in the first place. ;)
And let's not forget that to someone with a 17" LCD monitor and a
blisteringly fast graphics card, 80x24 text in a terminal emulator is
somewhat underwhelming, and doesn't provide anything like the
information density needed to make truly complex software interfaces
usable. The human optic nerves have about 100Mbps of bandwidth *each*;
that's a couple of ethernet cables directly into the cortex. Even a
large, high resolution, big-color-gamut display with a decent refresh
rate doesn't use more than a fraction of that capacity to deliver
information to the user, even when the display is used to maximum
advantage by the software to provide state information and navigation
cues (and document views!).
Those dim old greenly-glowing 80x24 terminals flickering at 20-odd Hz,
by contrast ... barely adequate to design their own replacements on,
though necessary for same. It's a good thing some people are
apparently very good at maintaining most of the state information in
their head that that tiny little box of text isn't displaying to them,
and "reading between the lines" to make use of even fairly complex
applications through such a tiny interface. Or those replacements
might never have been built.
> I can use the same text-editing
> commands for reading & writing emails, reading & writing Usenet posts,
> reading & writing code, browsing the web, organising my schedule and so
> forth.
I'm not sure that's such an advantage. Sometimes, unifying tasks too
much creates security holes, especially when some of those tasks are
network-facing and some are not. Some proposed or actual Windows
features result in an unclear boundary between "my computer" and "the
net out there", and that's bound to result in leaked passwords and
credit-card numbers and all manner of other accidental breaches, as
well as enable a variety of new social engineering attacks to
purposely compromise more of the same. Phishing and similar attacks
already pose a problem, but if the "phishing" looks like it's local
applications or content instead of online, it's even more likely to be
mistakenly trusted.
One sometimes wonders if Microsoft has more sinister motives than "get
rich with as shoddy and cheap a product as possible" in light of
things like this. I do hope the unified stuff you describe in emacs
isn't the open source equivalent. There's frank danger in making it
too easy to mix up local stuff and online stuff while at work at a
computer.
> The vast majority of what we do on a computer is reading & writing
> text--wouldn't it be cool to have a full-fledged text editing
> environment always available for that sort of thing?
Define "we". It can't be "people", because a substantial fraction of
people use computers heavily for image or even 3D manipulation, or
sound, rather than text, or a mixture with text not predominant, and a
much larger fraction use computers for absolutely nothing at all.
"Programmers" maybe. Even so, some people program from time to time
but do a lot of, say, image manipulation.
I expect even most programmers like to be able to see what the heck
they're doing, rather than resorting to fumbling around with a
flashlight or grunting terse instructions to a blind butler with an IQ
in the mid-zeros.
> Wouldn't it be cool not to have one program implement search in one way, and another a
> second way, and yet another a third? Wouldn't it be cool to have access
> to a proper text editor when editing text on a web page?
Search is usually ctrl+f, type something, hit enter in my experience.
And I can use any text editor I want to edit HTML.
> That's how I learnt emacs. I was 13, and had only ever used Mac
> software up until that point. I had a fairly limited command set
> (basically, C-x C-f, C-x C-s & C-x C-c).
That looks like three commands, although I can't be sure -- my Swahili
is a little rusty from years of disuse. ;)
I'd normally use at least eight -- open, save, quit, find/find next,
replace, cut, copy, and paste. That's not counting arrows, page up,
page down, del, backspace, and the like, and unixy tools don't let you
take even THOSE for granted. And if I needed more, add help. Add the
four arrows, page up, page down, delete-forwards, backspace, and help
to the original eight and we now have 17 commands. I seriously doubt
that your short chunk of Swahili up above encompasses all of them.
> Do you realise that emacs has a GUI these days? I'm writing this in a
> 70-line window, with gtk+ widgets. Which means full-resolution,
> full-colour.
What are you talking about? Clearly not emacs, which is a console app
for unix systems (with the inevitable MS-DOS ports and others). Some
sort of bastardized Windows port I suppose? I've seen the occasional
attempt at a Windows port of a unix tool, and the results are fairly
uniformly awful. Everything looks mostly right, and nothing works
quite right. They're often actually more unstable than native Windows
apps, probably because the porters don't know half as many of the
landmines littering the windoze APIs as real Windows application
programmers do (and *they* only know maybe half of the total, to judge
by the stability of even higher-quality Windows apps) and because they
are bolting on a thin layer of Windows widgets onto a core that works
in ways fundamentally alien to those same APIs. No real Windows app
dares to try spawning around 700 threads to service a request to copy
two lines of text to the clipboard, for example. :)
------------------------------
Date: Sun, 24 Jun 2007 06:21:18 -0000
From: Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182666078.511962.280030@w5g2000hsg.googlegroups.com>
On Jun 23, 8:35 pm, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
> Twisted <twisted...@gmail.com> writes:
>
> > For an example of the latter, consider opening a file. Can't remember
> > the exact spelling and capitalization of the file name? Sorry, bud,
> > you're SOL. Go find it in some other app and memorize the name, then
> > return to emacs.
>
> Once again I am forced to wonder if you have _ever_ actually used
> emacs. find-file has tab completion: hit tab without anything typed, and
> it displays _everything_ in the directory; type a few characters to
> narrow it down; hit tab to complete the filename and be done with it.
>
> Or of course you could use directory mode, which enables you to navigate
> around a directory tree, performing actions on files (including editing
> them).
>
> Then of course there's ido.el, which is even better: type a few
> characters from anywhere in the name, and it displays files matching
> those characters.
Really? None of this happens if you just do the straightforward file-
open command, which should obviously at least provide a navigable
directory tree, but definitely does not. One sounds like it involves
managing a separate open window on each directory you're interested in
(versus having a file...open dialog that falls open to the last place
you'd left it and doesn't clutter up any space when you're not opening
a file); the other sounds like it involves actually installing a
plugin of some kind, which is obviously well beyond what a beginner
should need to do just to get a freaking directory listing. :) Tab
completion is a poor cousin to a real directory tree navigator, as I'm
sure most would agree. Even if it will show all matches to a partial
name instead of none, it's the textual equivalent of navigating a
directory tree made into menus instead of provided by a proper folder
view window. Windows users unfortunately have the experience
regularly: the notorious Start menu. You have to expand submenus to
find stuff, and you can't leave it idling to do something somewhere
else and come back to it because it's a menu. Moreover, clicking an
item may display a large number of items the next level down, which
runs into screen display space issues. Even a large video mode can't
hide the fact that menus weren't really designed to list hundreds of
sibling items or for scrolling or finding stuff in a large set of
files, unlike folder windows. I can only imagine the pain of trying to
navigate an equivalent way in an 80x25 box of text information. That
would be like navigating the Windows start menu from outside your
house by peeking through a keyhole and reaching through a window with
a repurposed straightened out coathanger. Clumsy AND the neighbors'll
see you and call the cops well before you find the item you're looking
for. :) (Navigating the Windows start menu in safe mode, at 640x480,
is about as close as most Windows users are ever likely to come to the
nightmare of opening a file in emacs when you don't already know its
exact path.)
------------------------------
Date: Sun, 24 Jun 2007 06:33:42 -0000
From: Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182666822.651882.7200@k79g2000hse.googlegroups.com>
On Jun 23, 11:56 am, Bjorn Borud <borud-n...@borud.no> wrote:
> [Twisted <twisted...@gmail.com>]
> |
> | That sort of negative-sum thinking is alien to me. Software being easy
> | for beginners to get started using does not in and of itself detract
> | from its value to expert users.
>
> the fact that you imply that this is my argument tells me that either
> you have not paid attention, or you have a raging inferiority complex.
> given the sum of your postings so far I'd say that you neither are,
> nor consider yourself, a cerebral sort of person, so this narrows it
> down somewhat (although not to the exclusion of you not having paid
> attention).
That ... makes no sense. Sorry. Previously, I said:
> Being beginner-friendly doesn't have to be at the expense of power or
> expert-user usability
and you said that depended on the definition of "expert". Apparently
you believe there is a type of "expert" for whom beginner-friendly
software is intrinsically less usable than beginner-hostile software.
Given that beginner-friendliness does not preclude any kind of expert
level functionality being available (consider something configurable
enough that an advanced user can start it up and open an advanced-uses
window and immediately do advanced stuff, and a real expert can make
it start up with that window already open and focused by default), it
follows that these experts' perceptions of decreased usability are a
psychological result of simply knowing beginners can easily become
proficient in using basic functions of the software in question,
rather than a material result of some compromise necessarily made in
the software's design, as there is no such compromise that can't in
practise be avoided.
An expert who feels software is less suitable for his use *purely*
because the unwashed masses can actually use it to accomplish
something is quite obviously some type of elitist jerk.
I rest my case.
------------------------------
Date: Sun, 24 Jun 2007 08:52:27 +0200
From: David Kastrup <dak@gnu.org>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <85zm2petec.fsf@lola.goethe.zz>
Twisted <twisted0n3@gmail.com> writes:
> On Jun 23, 2:04 am, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
>
>> > Besides, ANY interface that involves fumbling around in the dark
>> > trying to find a light switch is clunky.
>>
>> That sounds like vi, not emacs.
>
> That sounds like any application where you need to read the help, but
> "f1" does not bring up a separate help window, switchable with the
> main one using alt-tab or the mouse, and navigable using arrows,
> pageup, pagedn, and the mouse.
Well, f1 brings up a prompt: f1 (type ? for further options)-
Typing ? brings up a separate window (and instructions how to scroll
it) with a variety of help options, among them the tutorial. If you
want a separate window, File/New Frame will give you that. Of course,
switchable with the main one using alt-tab or the mouse, and navigable
using arrows, pageup, pagedn and the mouse.
> The result of that is invariably that when the document has the
> focus, the help is open to "help on switching windows" rather than
> whatever you need it to be on once the document has the focus. You
> can read the help on doing what you want to do with the document,
> but to apply it you need to transfer focus back to the document. If
> doing that isn't second-nature, you have to navigate the help away
> from where you need it to get the focus back to the document.
Nonsense.
> Now the focus is on the document, but the help you need isn't
> displayed next to it anymore. Frustrating? You can't begin to
> imagine, I suspect. Apparently, some people are born somehow able to
> avoid this problem without having to memorize one or the other piece
> of help. You're clearly one of those. I am equally clearly NOT one
> of those. Of course, if emacs let you keep THREE windows open and
> visible at the same time, instead of being limited to one or a
> horizontally split two ...
Which it does...
> and a cramped 80x10 or so each, at that ...
Emacs frames can certainly be resized and repositioned at will using
the mouse...
You are really babbling a lot of nonsense that is, at best, somewhat
relevant for prehistoric versions of Emacs without GUI support.
Just shut up until you have installed and worked with a modern version
of Emacs.
> If I haven't, it must be the case that finding this tutorial (or
> even discovering that it exists) was nontrivial, or it wasn't built
> into emacs, one or the other. My memory is somewhat fuzzy after all
> these years so you'll forgive me if I don't make a definite
> statement about which.
"After all these years"... You really should not rely on 10-year old
memories about an application.
> On the flip side, if I have, the tutorial can't have been all it's
> cracked up to be. Especially given I can program Java proficiently,
Apparently, at the time you last looked at Emacs, Java did not yet
exist.
> including some fairly sophisticated network-using tools, and clearly
> am not an idiot or untalented in technically demanding areas
> involving substantial amounts of arcana.
Up to now you have not delivered any discourse that would warrant the
"clearly" in this sentence. Not that using Emacs involved
"substantial amounts of arcana".
> The technical term for managing limited resources, such as time and
> effort, first where needed and never where avoidable, is
> "efficiency", in case you were unaware.
Sure, but babbling about a system you have never seen in its present
state for 10 years, and consequently putting your foot in your mouth
in hundreds of postings requiring hours of times spread over several
months, when it would take all of 10 minutes to get your information
somewhat up to scratch, is called "stupidity", in case you were
unaware.
>> or you're just making things up.
>
> Also untrue, and you've just accused me of incompetence once and of
> lying twice, which in a formerly civil discussion constitutes
> behavior that I consider to be in poor taste.
Well, so what is it about you accusing people of lying that report
experiences about a system you have never looked at in its current
state? You even accused me of lying when I posted _screenshots_ from
a publicly accessible site, suspecting me of forgery.
>> If I'm browsing the manual online, I can switch from said manual to
>> my document buffer without making the manual scroll to the
>> documentation for switch-to-buffer.
>
> Apparently because you find the switch second nature, despite its
> not being the obvious (which is ctrl-tab, to switch between
> documents in an MDI app).
And which works fine when using Emacs frames. Look, you are making a
complete spectable of yourself. Get a current version of Emacs and
actually try it.
> Cheat sheet? Memorized with painstaking months of hard effort?
> Thanks for proving my point, either way.
You are babbling. Not that this is new.
>> In fact, I am not aware of any package which auto-changes the
>> *info* or *Help* buffers to reflect the last keyboard command.
>
> I didn't say it auto-changes. It manual-changes. The exact sequence of
> events that causes this with a novice user being:
> * Need to do X, and the usual command doesn't work (e.g. go to save
> document and get search prompt)
Try the File/Save menu.
> * Now nothing much works (typing stuff bleeps),
Typing letters will search (the I-search: prompt in the message area
is pretty obvious). Typing other stuff (like cursor keys) will abort
the search and do their normal work. Clicking with the mouse into the
main window will abort the search and reposition the cursor. Quite
easy.
> hit esc a bunch of times *
The splash screen already explains that C-g is used for aborting
operations.
> Now it complains of hitting esc too many times,
No, it says "Quit" since it has quit the search.
> but typing into the document at least works again * OK, time to
> resort to *gulp* the help. * Oh, great, now what did it do? I hit
> F1 and ... * Eh. Try random stuff.
No, F1 works fine for entering the help.
> Help starts with h. Alt-h? Ctrl-h? ... * Oh, right. I seem to
> remember the help popping up unwanted when I tried to backspace over
> a typo earlier, so I'll just do that. * Hrm, now how to search the
> bloody thing? * <Hours pass, some spent trying ctrl+f and ctrl+s,
> mostly fruitlessly, followed by a load of
> scrolling>
Well, what kind of help did you select? The tutorial explains about
Searching some point down in the document, certainly not requiring
hours of paging. But you could, of course, also click on the
Edit/Search menu. Or on the "Search" button in the toolbar: after
all, Emacs is a modern GUI application.
> * Ah. "How to do Foobar to your open document". Perfect!
> * Oh crap. How do I do anything to my open document, when the focus
> is on the help instead of the document?
> * <Scrolling for ten
> minutes> * Ah, I hit this. It worked! * Oh, fudge. Where did "How
> to do Foobar to your open document" go? The help's open to "How to
> switch windows". For shame. * Switch back, scroll ... there it is.
> * Crap, now I don't remember how to put the focus back on the
> document window. * More scrolling. * Oh, fudge. Where did "How to
> do Foobar to your open document" go? The help's open to "How to
> switch windows". For shame. * <however many repetitions of the
> preceding 4 lines> * Error: Stack overflow. Dumping core.
>
> I trust you get the picture.
Yes. You don't have a clue what you are talking about. Your
experience is, self-admitted, at least 10 years old and completely
irrelevant to the modern state of Emacs. And, of course, the "Stack
overflow. Dumping core." nonsense bears no relation to _any_ behavior
_any_ version of Emacs, prehistoric or not, ever showed.
> [snip]
>
> Whoa, what did you just say? Page 899 of the ... good Christ. Er ...
> Run! Flee! It's a monster! Head for the hills! Sound the civil
> defense sirens, tornado TORNADO! *runs*
You are getting delirious.
>> > Infrequently used commands you can stand to hunt for in
>> > menus. When you find you use one frequently, you can try to learn
>> > the keyboard shortcut -- and you can find it without even
>> > consulting the help, simply by finding the command's menu item.
>>
>> This is no different from emacs. There's a menu bar
>
> What are you blithering about? Oh, great, now I'm using the term
> "blithering". :P But ...
>
> WHAT menu bar? We're discussing emacs. As in, a text-mode editor. As
> in a cramped little 80x24 grid of letters, numbers, spaces, and
> punctuation with no menus, no concept of a pointing device, and a
> bad attitude.
We are discussing Emacs. An editor tightly integrated into the GUI
of, at choice, Windows, MacOSX, X11 Athena, X11 Gtk+, its own Lucid
widget set, with mouse navigation, toolbar, multiple resizable frames,
menubars, support of graphics, proportional and different-sized fonts
in the frame. The one displayed in the screenshots
<URL:http://www.gnu.org/software/auctex/screenshots.html> on the
AUCTeX web site.
You, on the other hand, are not "discussing Emacs" but talking
nonsense based on fuzzy memories of passing decade-old experiences
with an early predecessor.
> Actually, the big thing the GUI and mouse did was rescue us from
> escalating UI problems with tasks complex enough to require
> modes. You needed either separate components with separate
> associated functionality and a "focus" to move among them, or you
> needed commands and keyboard-toggled modes. The former got you an
> emacs and the "can't switch back from the help" syndrome,
> and the latter got you ... something vile.
Get an update. Emacs started supporting window systems with Emacs 19
(a very long time ago), at first just under X11. But current versions
of Emacs support all modern GUIs with all features they offer.
> Until the GUI-with-pointing device, which made user control of a
> "focus" a snap requiring virtually zero learning curve, and better
> yet, what little learning there was being transferred readily across
> applications. Unified windowing systems, with Macs and Windows,
> cemented the victory of the pointing device over the problem of
> focus management. Point at the thing you want to use next and click;
> that simple. A child can do it. Using a GUI is like doing a job
> yourself, such as washing the car. Using something from the dinosaur
> age, especially afterwards, feels like sitting back and directing
> some hired help. Help that happens to be blind as a bat as well as
> having the usual poor grasp of English. "Left, Senor. Right,
> Senor. No not THAT far right! Now you've gotten it all into the open
> drivers-side window, and those documents I left on the front seat
> are ruined!" Ouch. Yet trying to control old text-mode tools is
> pretty much exactly the same, only the flawless English it speaks
> belies an even dodgier grasp of same, or even the need to speak to
> it in some obscure dialect of Greek full of "meta" instead...and it
> doesn't apologize when there's a screwup a more hands-on interface
> would easily have prevented.
Again, you are babbling based on decade-old passing exposure to an
early predecessor of modern Emacs.
It is not like you have not been told a hundred times, over a duration
of several months. You could have downloaded, tried and _learnt_ a
modern version of Emacs in half the time you used for spewing about
it. You choose ignorance, and showing off what an idiot incapable of
rational behavior you are.
> If you want a job right, do it yourself. With a mouse, you can; no
> need to speak an obscure variant of Swahili into a keyboard just to
> get the focus to the document from the help or wherever. And to top
> it off, every Windows app understands tab and alt-tab and most
> understand ctrl-tab.
As does Emacs. Or rather, it does not need to. Instead it reacts,
like other applications, to the frame and focus switching commands
from the window system which in itself interprets alt-tab.
> Actually, the OS GUI components themselves understand alt- tab, and
> the applications just get told the focus went elsewhere or came
> back, making it one less area for application designers to screw
> things up. (All too often, they screw up ctrl-tab in tabbed/MDI
> apps, or screw up tab by using a dodgy tab order or controls with no
> visual indication of focus, mind. And then you can just resort to
> the mouse, rather than throw up your hands or find something
> non-electronic to sob into so as to avoid ruining another $40
> keyboard.)
And your point was?
> And let's not forget that to someone with a 17" LCD monitor and a
> blisteringly fast graphics card, 80x24 text in a terminal emulator is
> somewhat underwhelming, and doesn't provide anything like the
> information density needed to make truly complex software interfaces
> usable.
You are talking about Emacs 18, or (in a DOS box, likely) at best
Emacs 19.
[Rest of the nonsense assuming that Emacs is a terminal application
only deleted]
> Those dim old greenly-glowing 80x24 terminals flickering at 20-odd Hz,
> by contrast ... barely adequate to design their own replacements on,
> though necessary for same.
Again, you parade your incompetency even about the decade-old
experiences you choose to talk about. No terminal ever flickered at
less than 50Hz. The normal frequency for US built terminals was 60Hz.
> "Programmers" maybe. Even so, some people program from time to time
> but do a lot of, say, image manipulation.
>
> I expect even most programmers like to be able to see what the heck
> they're doing, rather than resorting to fumbling around with a
> flashlight or grunting terse instructions to a blind butler with an
> IQ in the mid-zeros.
The latter sounds like a description of you. Current versions of
Emacs 22 even offer browsing through directories with images (use the
image-dired function) and applying basic operations like rotating
them. Good for managing a photograph collection.
>> That's how I learnt emacs. I was 13, and had only ever used Mac
>> software up until that point. I had a fairly limited command set
>> (basically, C-x C-f, C-x C-s & C-x C-c).
>
> That looks like three commands, although I can't be sure -- my
> Swahili is a little rusty from years of disuse. ;)
>
> I'd normally use at least eight -- open, save, quit, find/find next,
> replace, cut, copy, and paste.
All of those are on the toolbar (not to mention in the menus).
> That's not counting arrows, page up, page down, del, backspace, and
> the like, and unixy tools don't let you take even THOSE for
> granted.
All of those work with Emacs.
> And if I needed more, add help. Add the four arrows, page up, page
> down, delete-forwards, backspace, and help to the original eight and
> we now have 17 commands. I seriously doubt that your short chunk of
> Swahili up above encompasses all of them.
All of that is available by clicking on icons, using scrollbars and
dedicated arrow/pageup/dn keys.
>> Do you realise that emacs has a GUI these days? I'm writing this
>> in a 70-line window, with gtk+ widgets. Which means
>> full-resolution, full-colour.
>
> What are you talking about? Clearly not emacs, which is a console
> app for unix systems (with the inevitable MS-DOS ports and
> others). Some sort of bastardized Windows port I suppose?
You are so clueless. Take a look at the web page for AUCTeX
<URL:http://www.gnu.org/software/auctex/screenshots.html>. That are
screenshots from a somewhat current version of Emacs.
> I've seen the occasional attempt at a Windows port of a unix tool,
> and the results are fairly uniformly awful. Everything looks mostly
> right, and nothing works quite right. They're often actually more
> unstable than native Windows apps, probably because the porters
> don't know half as many of the landmines littering the windoze APIs
> as real Windows application programmers do (and *they* only know
> maybe half of the total, to judge by the stability of even
> higher-quality Windows apps) and because they are bolting on a thin
> layer of Windows widgets onto a core that works in ways
> fundamentally alien to those same APIs. No real Windows app dares to
> try spawning around 700 threads to service a request to copy two
> lines of text to the clipboard, for example. :)
The Windows port of Emacs is full-quality and full-functionality and
tightly integrated with Windows' GUI. You can get it with an
installer from the EmacsW32 web page
<URL:http://ourcomments.org/Emacs/EmacsW32.html>, for example, or from
the main Emacs distribution site from the FSF.
You are babbling uninformed outdated nonsense, and have been pointed
to the relevant info dozens of times over months. Yet you choose to
stay ignorant and continue looking like an uneducatable idiot.
Uneducatable idiots should not choose to work in the computing
business since things move fast there, and uneducatability (and the
unwillingness to reevaluate decade-old experience) are plainly a
hinderance.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
------------------------------
Date: Sun, 24 Jun 2007 08:56:58 +0200
From: David Kastrup <dak@gnu.org>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <85veddet6t.fsf@lola.goethe.zz>
Twisted <twisted0n3@gmail.com> writes:
> On Jun 23, 8:35 pm, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
>> Twisted <twisted...@gmail.com> writes:
>>
>> > For an example of the latter, consider opening a file. Can't remember
>> > the exact spelling and capitalization of the file name? Sorry, bud,
>> > you're SOL. Go find it in some other app and memorize the name, then
>> > return to emacs.
>>
>> Once again I am forced to wonder if you have _ever_ actually used
>> emacs. find-file has tab completion: hit tab without anything typed, and
>> it displays _everything_ in the directory; type a few characters to
>> narrow it down; hit tab to complete the filename and be done with it.
>>
>> Or of course you could use directory mode, which enables you to navigate
>> around a directory tree, performing actions on files (including editing
>> them).
>>
>> Then of course there's ido.el, which is even better: type a few
>> characters from anywhere in the name, and it displays files matching
>> those characters.
>
> Really? None of this happens if you just do the straightforward file-
> open command, which should obviously at least provide a navigable
> directory tree, but definitely does not.
It definitely _does_ when you are using the mouse to open your file
dialog. Again, _try_ a current version of Emacs before showing your
ignorance.
[Other nonsensical speculation deleted]
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
------------------------------
Date: Sat, 23 Jun 2007 21:47:01 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: uninitialized value
Message-Id: <slrnf7rmp5.pt6.tadmc@tadmc30.sbcglobal.net>
jan09876@hotmail.com <jan09876@hotmail.com> wrote:
> I try to learn perl by myself without any programming background.
> I keep on receiving this message
No you don't.
You receive this message:
Global symbol "$titles" requires explicit package name at ./print.pl line 16.
Execution of ./print.pl aborted due to compilation errors.
Please do not re-type Perl code, use copy/paste or your editor's
"import" function rather than attempting to type in your code. If you
make a typo you will get followups about your typos instead of
about the question you are trying to get answered.
You inserted a typo that cannot be in your real program.
We need to see *exactly* what code you're running if we are to
help you debug it.
> Use of uninitialized value
That means you are using the special "undef" value as if
it had been given a real value.
> in join
> or string at ./print.pl line 18,
Is that really the line number?
Because I cannot duplicate that...
(or did your re-typing change line numbers too?)
> <DATA> line 8. and don't know what to
> do to fix the problem.
First you need to *find* the problem. Then you fix it.
Every message that perl might issue is documented in
perldoc perldiag
so you should get in the habit of looking up your messages in there.
> #!/usr/bin/perl
> use warnings;
> use strict;
This is most excellent!
You are already ahead of most newbie Perl programmers.
> my $title = "#.*#";
You never change the value of that variable in your code, it is
a variable that does not vary!
Is that what you meant to do?
> my %hash;
>
> while(<DATA>) {
> chomp;
> {
> my($key,$val) = split(/\s*=>\s*/);
What will end up in $val for your "title" lines?
This is the cause of the warnings you are getting.
You need to treat the title lines differently than the data lines.
> push(@{$hash{$key}},$val);
> }
>
> for my $key (sort keys %hash) {
> print "$key => @{$hash{$key}}\n";
> print $titles;
^
^
The program you posted will not even run, so it cannot be issuing
uninitialized warnings because those happen at runtime.
> }
> }
>
> __DATA__
> #title -fruit-#
> orange => orange
> orange => carot
> red => apple
> red => cherry
> red => strawberry
> #title -vegetables-#
> green => cucumber
> red => tomatoes
>
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 568
**************************************
