[this post is a excerpt from
The Modernization of Emacs, Xah Lee, 2006-04 at http://xahlee.org/emacs/modernization.html
]
The Modernization of Emacs
----------------------------------------
THE PROBLEM
Emacs is a great editor. It is perhaps the most powerful and most
versatile text editor. And, besides text editing, it also serves as a
email application, newsgroup application, ftp application, irc
application, web browser, shell interface, file management
application, programable calculator, calendar and personal info
management application, lisp language system, among other things.
These seemingly wild functionalities are employed in production daily
by a significant number of programers around the world. Some calls
emacs as a Operating System as a joke. (Technically it does not
qualify because a OS implies management of hardware.).
If emacs is such a great and powerful text editor why almost nobody
knows about it? Vast majority of people who need to write will be more
than happy to use editors other than emacs. Ask a Microsoft Windows
user. She'll be more than happy to use Microsoft Word↗. If he doesn't
have MS Word, he'll use NotePad↗ or WordPad↗. If he is a programer,
most will be more than happy to use any of other graphical editors on
the Windows platform or any of the Integrated development
environment↗. Same is true on other operating systems, and new editors
spring up here and there even though they don't have as much power or
flexibility as emacs. For example, there are NEdit, JEdit, Eclipse,
Xcode↗ , or the various associated with languages or third party
language software, such as Visual Basic or Borland C++.
Many reasons can be made out of this. For example, emacs is not
bundled on popular operating systems such as Windows or Mac, which are
used by some 99% of computer users worldwide. Windows and Mac both
have simple text editors bundled that will satisfy majority of
computer users, which are non-professional computer users. (NotePad
and WordPad on Windows, TextEdit↗ on Mac) For the few professional
computer users, a majority will need a easy to use, yet powerful
editor that also does styled text, formatting, and sundry light
publishing needs such as table layout, simple line graphics drawing,
embedded images, math formulas. They will choose and adopt Microsoft
Word for their needs. The tiny percentage that might be interested in
emacs, are programers. Even among professional programers, a majority
shy away from emacs.
A major difficulty among programers who do not use or like emacs, is
that emacs's user interface is rather esoteric, involving arcane
terminologies and keystrokes. This is in sharp contrast to the
thousands of software applications used today, where their User
Interface are similar and familiar to today's computer users.
----------------------------------------
THE COMMON USER INTERFACE
The following is a excerpt from the Wikipedia article on Common User
Access↗:
CUA was a detailed specification and set strict rules about how
applications should look and function. Its aim was in part to bring
about harmony between MS-DOS applications, which until then had
implemented totally different user interfaces.
Examples:
* In WordPerfect, the command to open a file was [F7], [3].
* In Lotus 1-2-3, a file was opened with [/] (to open the menus),
[W] (for Workspace), [R] (for Retrieve).
* In Microsoft Word, a file was opened with [Esc] (to open the
menus), [T] (for Transfer), [L] (for Load).
* In WordStar, it was [Ctrl]+[K]+[O].
* In Emacs, a file was opened with [Ctrl]+[x] followed by [Ctrl]+
[f] (for find-file).
Some programs used [Esc] to cancel an action, some used it to complete
one; WordPerfect used it to repeat a character. Some programs used
[End] to go to the end of a line, some used it to complete filling in
a form. [F1] was often help but in WordPerfect that was [F3]. [Ins]
sometimes toggled between overtype and inserting characters, but some
programs used it for “paste”.
Thus, every program had to be learned individually and its complete
user interface memorized. It was a sign of expertise to have learned
the UIs of dozens of applications, since a novice user facing a new
program would find their existing knowledge of a similar application
absolutely no use whatsoever.
----------------------------------------
SIMPLE CHANGES
In the following, i describe some critical changes that are also very
easy to fix in emacs. If emacs officially adopt these changes, i think
it will make a lot people, at least programers, like emacs and choose
emacs as their text editor.
* Change the keyboard shortcut of Copy & Paste to ctrl-c and ctrl-
v as to be the same with all modern applications.
* Change the undo behavior so that there is a Undo and Redo, as
the same with all modern applications.
* Get rid of the *scratch* buffer.
* Change the terminology of “kill” to “cut”, and “yank” to
“paste”.
* Change the terminology of Meta key to Alt.
* Make longlines-mode the default editor behavior for any file.
Things emacs should do now, even though it eventually will do.
* When opening a HTML document, automatically provide highlighting
of HTML, CSS, and Javascript codes. Similarly for other multi-language
files such as PHP, JSP, et al. This behavior must be automatic without
requiring user to customize emacs.
Possible Documentation Change Proposals
* Reduce the use of the word “buffer” in the emacs documentation.
Call it “opened file” or “unsaved document”.
* Switch the terminology of Window and Frame so it is more
standard. That is, Emacs's “Window” should be called Panes or Frames.
While Emacs's “Frame” should be termed Window.
* Change the terminology of keybinding to “keyboard shortcut” in
emacs documentation. Use the term keybinding or binding only in a
technical context, such as in elisp documentation.
Xah xa*@xahlee.org
∑ http://xahlee.org/
Jun 17 '07
331  14653 
Twisted <tw********@gmail.comwrites:
>
I have that exact URL now --
http://www.asktog.com/columns/027Int...sThatKill.html
Utterly unrelated to Emacs.
I think it is quite relevant. Clunky computer interfaces may not be so
dramatically dangerous, but they certainly can hamper productivity.
You're quite right. Windows/Mac user interfaces are so clunky that they
massively hamper productivity. Emacs, OTOH, enables it. For example,
C-s is search forward; C-r is search backward ('reverse'); C-M-s is
search forward for a regular expression; C-M-r is search backward for a
regular expression. A Windows or Mac editor would have C-s for save,
and that's it. It might have C-f for find, but it'd pop up a dialogue
instead of offering an interactive search, causing a mental context
switch. Searching would interrupt one's flow of thought rather than
being part of it.
Between Windows bugs and gratuitous misfeatures (e.g. DRM) and Unix
clunkiness, billions of dollars of potential productivity is lost
worldwide every *month*.
You left out user refusal to learn...
--
Robert Uhl <http://public.xdi.org/=ruhl>
If I could sum up my life in one sentence, I think it would be: He was born, he
lived, and then he kept on living, much longer than anyone had ever lived
before, getting richer and richer and glowing with a bright white light.
--Deep Thoughts, by Jack Handey [1999]
Twisted <tw********@gmail.comwrites:
>
>But Emacs does not have a "clunky" interface.
That's for the everyday novice-to-intermediate user to decide.
Why should the ignorant decide? Do you leave the decision of what great
art is to 3 year olds and their doting parents? Do you leave the
decision of what great food is to the ignorant, unwashed,
McDonald's-devouring masses? Why then do you leave the decision of
what's a useful interface to those with insufficient experience?
Emacs has a slight learning curve (so too did your Windows/Mac OS
interface conventions--you've just forgotten them), but it is easy to
use. A Windows or Mac OS text editor may have an easier learning curve,
but it'll never be as easy to use.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I read [.doc files] with 'rm.' All you lose is the Microsoft-specific
font selections, the macro viruses and the luser babblings.
--Gary `Wolf' Barnes
["Followup-To:" header set to comp.emacs.]
If you'd spent half an hour using the tutorial (helpfully displayed
right there when you start emacs), you could have saved three and a half
hours of wasted time. And you'd now be using an actual text editor,
which is often helpful.
Your statement is obviously based on your assumption everyone has as
good a memory as you. Unfortunately, this is not always the case. I
came to emacs as a geezer with a less than sterling short term memory.
I got about 8 keystrokes into the tutorial before I was lost. I
finally had to start a cheat sheet. It's also a PIA to read a
tutorial and practice in another window until you know how to
open/close/juggle said windows. I never did get much from emacs'
tutorial. It also took me awhile to train my pinkies to reach for
that until-now-unused Ctrl key. No, using emacs is not trivial. It's
a learned skill that requires some effort. More for some than others.
In emacs', defense, it's a helluva lot more intuitive than vi, which
is a nightmare straight from Hell!
nb
David Kastrup <da*@gnu.orgwrites:
You know you can use something like
C-x C-f /su::/etc/fstab RET
(or /sudo::/etc/fstab) in order to edit files as root in a normal
Emacs session?
I did not know that. That will save me huge amounts of time. You're
my hero.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest: http://www.gnu.org/philosophy/sylvester-response.html
Lew <le*@lewscanon.nospamwrites:
Joel J. Adamson wrote:
>My point is that I'm the sort of person that has a mind set up for
Emacs. I had none of the difficulties that someone else might have,
who's used to other kinds of software.
However, I'll also point out that my wife has used Emacs a couple
times, and she's never done more than point and click with a computer,
and she's had no frustration whatsoever.
A new user of two hours' experience. A father of a six-year old whose
child hums along happily with emacs. A computer widow who "had no
frustration whatsoever" with it.
I'll add that the words "Oh, cool" came out of her mouth during one
Emacs session, as they did when I showed it to a coworker.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest: http://www.gnu.org/philosophy/sylvester-response.html
I just tried it: works for me.
Joel
David Kastrup <da*@gnu.orgwrites:
Lew <le*@lewscanon.nospamwrites:
>Bjorn Borud <bo********@borud.nowrites:
>>>so if the context was system administration, I'd vote for vi as
well. if the context was programming I'd vote Emacs.
David Kastrup wrote:
>>You know you can use something like
C-x C-f /su::/etc/fstab RET
(or /sudo::/etc/fstab) in order to edit files as root in a normal
Emacs session?
I've been using emacs for something like twenty years and never knew
that before.
The package "tramp" will provide that (as well as editing files over
ssh, scp, rsync, telnet, plink...). It is already preinstalled in
Emacs 22.1, but can also be installed for earlier versions.
--
David Kastrup
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest: http://www.gnu.org/philosophy/sylvester-response.html
David Kastrup <da*@gnu.orgwrites: ja******@partners.org (Joel J. Adamson) writes:
>Or, since Emacs is customizable, for me it would be
<f1t
<f1i
<f1?
Huh? The latter are available by default on Emacs 22.1.
Interesting, maybe I have a telepathetic connection with the
developers; either that or I just kept using the same .emacs when I
upgraded ;)
(I had to change this when I was using Emacs 21.4, since I started
using C-h for backspace)
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest: http://www.gnu.org/philosophy/sylvester-response.html
Bjorn Borud wrote:
[Martin Gregorie <ma****@see.sig.for.address>]
|
| As for documentation, lets look at vi. Not a great editor, but every
| *nix variation has it installed and any fool can learn to use it in
| about 2 hours flat and it does at least have good pattern matching.
there's also the "info" system in Emacs, which not only covers Emacs
itself, but usually also a lot of documentation available for Emacs
extensions and other programs. again, this predates a lot of things
that people are used to today, so just because it seems (and sometimes
is) a bit more fiddly, it must necessarily be inferior.
I thought it might be in "info", like most GNUish things but I couldn't
check because I don't have it installed.
for instance, Linux has come a long way in addressing the needs of
desktop users, yet some people refuse to use Linux because it doesn't
behave *exactly* like Windows (as if that was a worthwhile goal) and
they are too lazy or don't think they can manage, to learn a new
system.
Yep, and the same people think a command line is to be avoided at all
costs. "I mean, its so /last century/ and you can't do anything useful
with it anyway".
Obligatory OT comment: right now I have two xterm sessions open with
which I've been writing a Swing/JDBC app using nowt but a bash shell,
cvs, microEmacs and (of course) J2SE. I don't need no steenking IDE.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
On Jun 21, 10:09 am, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
You're quite right. Windows/Mac user interfaces are so clunky that they
massively hamper productivity. Emacs, OTOH, enables it. For example,
C-s is search forward; C-r is search backward ('reverse'); C-M-s is
search forward for a regular expression; C-M-r is search backward for a
regular expression. A Windows or Mac editor would have C-s for save,
and that's it. It might have C-f for find, but it'd pop up a dialogue
instead of offering an interactive search, causing a mental context
switch. Searching would interrupt one's flow of thought rather than
being part of it.
Being a primarily windows user, I have to question your assertion that
using ctrl-f for find causes a "mental context switch". For me, in 90%
of the windows applications, finding something is as simple as ctrl-f,
the phrase, hit enter. Not terribly different from your set of
commands. The biggest difference is that if I need to use a Find
feature I might not often use, I have a visual interface to all the
related search functions. On the other hand, a terminal program would
necessitate a memory search at best, or a trip to the help pages at
worst.
The best part of my windows knowledge is that it's transferable to
most (all?) of the applications I work with. Find is usually ctrl-f.
Undo is ctrl-z. Save is ctrl-s, yadda yadda. Such knowledge is rarely
transferable from terminal programs in my experience -- what may be
true for one program (emacs) is wildly different in another program
(vi), and useless in yet another (pico).
On the other hand, I can move from notepad to Word to Open Office to
Notepad++, based on the availability at the terminal I'm on, with
little difficulty.
For the record, I use VIM when in terminals. Emacs isn't available on
our *nix boxes.
Feel free to disagree with what I'm about to say. I know that this
thread would be far, FAR shorter if OP hadn't been instigating
disagreement, but so far most of the discourse has been polite, so I'm
going to say what I'm thinking.
I think there are far too many people in all camps (the Emacs camp,
the vi* camp, and the GUI/IDE/point-and-click-and-make-
everything-"user-friendly" camp) who look at this disagreement as a
debate in which they Are Right, and the members of the other two camps
Are Wrong. There are billions of people in this world, and even if you
ignore the ones who don't need to use a text editor or word processor
on a regular basis, you end up with a VERY large number of people. And
people are different. We think differently, we all have different
things that come to us naturally, different things that are tricky but
learn-able, and different things that we'll never be able to do
without a manual open in front of us.
There are a lot of people for whom emacs is easy to learn, logical to
use, and the way it is set up (or at least the way -they- set it up)
is so natural to them that they'll never be as productive anywhere
else. But there are also a lot of people for whom emacs doesn't click,
who can give it a genuine try but still not catch on, and even once
they learn enough to muddle through, they'll always work better in
Word, or in an IDE.
But I think there's something else to it, and it's part of why I think
the emacs faithful swear by it so fiercely, even if it does seem a
daunting tool to master.
I don't think anyone can make the argument that any (past or current)
graphics-based editor is as efficient when being used to its fullest
as a text-based editor. It's basic math - it takes measurably more
time to move a hand to the mouse, move/click the mouse, and more the
hand back to the touch-typing position than it does to execute even a
moderately complex series of keystrokes. Maybe not large amounts of
time -per action-, but it doesn't take too long for it to add up if
you spend a lot of time editing.
Contrast the time saved by not having to reposition one's hands, the
extensibility, and customization against the learning curve of an
interface that doesn't exactly throw its controls at the user, and
here's the conclusion I think results: graphical interfaces are -
easier- to develop some proficiency with, but proficiency with emacs
pays of far more in the long run.
And if you disagree with me, or if you think I expressed my point
poorly (I'm good that that), all you need to do is ask Steve Yegge his
thoughts on emacs.
-Andrew
I don't think anyone can make the argument that any (past or current)
graphics-based editor is as efficient when being used to its fullest
as a text-based editor.
Clarifying - this part of the claim assumes a fairly similar feature
set, naturally.
On Jun 21, 2:10 pm, Kaldrenon <kaldre...@gmail.comwrote:
I don't think anyone can make the argument that any (past or current)
graphics-based editor is as efficient when being used to its fullest
as a text-based editor. It's basic math - it takes measurably more
time to move a hand to the mouse, move/click the mouse, and more the
hand back to the touch-typing position than it does to execute even a
moderately complex series of keystrokes. Maybe not large amounts of
time -per action-, but it doesn't take too long for it to add up if
you spend a lot of time editing.
Contrast the time saved by not having to reposition one's hands, the
extensibility, and customization against the learning curve of an
interface that doesn't exactly throw its controls at the user, and
here's the conclusion I think results: graphical interfaces are -
easier- to develop some proficiency with, but proficiency with emacs
pays of far more in the long run.
I have to point out, that this makes the assumption that the most oft-
used commands in a GUI editor are not as easily accessed from the
keyboard as they are in a terminal editor.
I took a moment to look at the gui editor which has been made
available to me, and short of the "remove leading spaces" commands, I
do not need to remove my hands from the keyboard if I do not want to.
Your statement holds true if, and only if, a user does not take full
advantage of the keyboard commands. But if we're talking about
experienced users in both cases, then that's not an issue, is it?
On Jun 21, 4:31 pm, Falcolas <garri...@gmail.comwrote:
Your statement holds true if, and only if, a user does not take full
advantage of the keyboard commands. But if we're talking about
experienced users in both cases, then that's not an issue, is it?
Granted. I suppose my claim should have been more specifically about
the means of interaction, and not about the tool being used. After
all, Emacs 22.1 has fairly complete point-and-click support, even
though I suspect more people use the keyboard as their primary input.
Kaldrenon wrote:
I don't think anyone can make the argument that any (past or current)
graphics-based editor is as efficient when being used to its fullest
as a text-based editor.
Actually, I think the argument can be made:
``We’ve done a cool $50 million of R & D on the Apple Human Interface.
We discovered, among other things, two pertinent facts:
* Test subjects consistently report that keyboarding is faster than
mousing.
* The stopwatch consistently proves mousing is faster than
keyboarding.''
(from http://plan9.bell-labs.com/wiki/plan...ard/index.html )
However, at least for me, heavy mousing is stressful to the wrist, so I
prefer to keep my hands on the keyboard (even though I use a trackball,
which greatly reduces the strain for me).
I also think that while intuitive cursor positioning and text selection
operations may be faster with a mouse, complex operations (like on the
shell or complex editor commands) are impractical through a pure
point+click interface.
On 2007-06-21, Kaldrenon <ka*******@gmail.comwrote:
Feel free to disagree with what I'm about to say.
[...]
And if you disagree with me, or if you think I expressed my point
poorly....
I think you expressed it well. I'll add that using one does not
necessarilly exclude using the other. I tend to use whatever makes
the job easiest FOR ME! ...be it a gui or the command line. Also,
ease of learning emacs has absolutely zero to do with mental prowess
and not everyone using it is a code whiz. Except for some html and
shell scripting, I do almost zero developement because it bores me to
freakin' tears. That's not to say I can't like the command line and
emacs.
All types of user interface have their pros and cons and it's
senseless to limit one's self to one or the other. Some tasks benefit
from using both simultaneously, acad and gimp/p-shop being prime
examples. Sure, everyone loves the camaraderie of belonging to a
group. That's just being human. But, choosing a preference doesn't
require fanatical loyalty to the exclusion of all other options, or at
least it shouldn't. Use the one that's best for the job.
nb
On Jun 21, 9:49 am, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
Twisted <twisted...@gmail.comwrites:
Given that in its out-of-the-box configuration it's well-nigh unusable
without a printed-out "cheat sheet" of some kind, of the sort that
were supposed to have died out in the 80s, getting it customized poses
something of a catch-22 for anyone trying to get started using it.
I don't see that. C-h t is your friend if you're starting out. The
only keystrokes a user really needs to remember are C-x C-s and C-x C-c;
everything else simple text editing needs works as expected (arrow keys,
backspace and so forth). Granted, text-mode is friendlier than
I'm not so sure C-h t is anybody's friend anymore. Every version of
Emacs that I've used since 1984 has supported the arrow and page up/
down keys. And every version of the tutorial that I've read (the
latest just a couple years back) insists on starting the user out with
C-f, C-b, C-p, C-n, C-V, and ESC-V, with some lame explanation like
"touch-typists shun the arrow and page keys, and besides, they might
not be supported on the next terminal you use." Like ESC, I suppose.
Furrfu.
Regards,
-=Dave
On Thu, 21 Jun 2007, ea*******@NOSPAMgmail.com wrote:
but it is easy to use. A Windows or Mac OS text editor may have an
easier learning curve, but it'll never be as easy to use.
This really is the biggest argument. Emacs takes more time to learn
than any other environment I've used. But, Emacs is the easiest to use
interface I've ever come across, by a very very wide margin.
--
Galen Boyer
Twisted <tw********@gmail.comwrites:
On Jun 20, 5:03 pm, Kaldrenon <kaldre...@gmail.comwrote:
>I still have a good deal to learn, even of the basics, but I've toyed
with it casually for a little bit (a total of two hours at most, but
almost certainly less) and I already know enough that finding out how
to do anything else IS trivial. It's not a program whose controls
throw themselves at you, exactly, but with a touch of patience and a
genuine interest in learning, it's not too bad.
I don't know what software you're describing, but it's obviously not
emacs, unless there have been some HUGE changes to (at minimum) the
help and pane-navigation (er, excuse me, "window"-navigation)
controls...
I don't know about *your* version of Emacs but in *my* version one can
switch windows using mouse. I think that's pretty easy especially for
beginners who are used to Windows.
There was also a Help menu on menu bar but I disabled menu bar since
keybindings are more convenient for me.
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--
[Twisted <tw********@gmail.com>]
|
| I think it is quite relevant. Clunky computer interfaces may not be so
| dramatically dangerous, but they certainly can hamper productivity.
| Between Windows bugs and gratuitous misfeatures (e.g. DRM) and Unix
| clunkiness, billions of dollars of potential productivity is lost
| worldwide every *month*.
bah, UNIX is not user hostile; it is just selective about its
friends.
-Bjrn
[Robert Uhl <ea*******@NOSPAMgmail.com>]
|
| Why should the ignorant decide? Do you leave the decision of what great
| art is to 3 year olds and their doting parents? Do you leave the
| decision of what great food is to the ignorant, unwashed,
| McDonald's-devouring masses? Why then do you leave the decision of
| what's a useful interface to those with insufficient experience?
Robert does have a point; however, one needs to take into account that
it is very difficult to judge the quality of an interface if it is one
that is very familiar to you or if the inner workings are obvious to
you. this is why programmers often make bad UI designers: we are
intimately familiar with the inner workings, and to us it is okay if
the UI is just a thin layer on top of a system we've made.
(I'd say the web is a better showcase for this. there seems to be no
end to the number of websites that have awkward interaction modes.
nor do people seem particularly shy about adding "just one more" thing
to an already crowded interface -- because they're blind to the wall
of complexity it presents to the occasional user).
editors like Emacs is not something which is designed for the casual
user, so what the casual user thinks is irrelevant. (also note that
the definition of "casual user" has changed).
-Bjrn
[Kaldrenon <ka*******@gmail.com>]
|
| I don't think anyone can make the argument that any (past or current)
| graphics-based editor is as efficient when being used to its fullest
| as a text-based editor. It's basic math - it takes measurably more
| time to move a hand to the mouse, move/click the mouse, and more the
| hand back to the touch-typing position than it does to execute even a
| moderately complex series of keystrokes. Maybe not large amounts of
| time -per action-, but it doesn't take too long for it to add up if
| you spend a lot of time editing.
a lot of IDE's are getting quite good and you don't have to mouse
around all that much. I think the main reason I stick to Emacs is
because I use it for a wider range of tasks -- not just programming.
also, the IDE's I've used in the past were sluggish and for some
reason the font-rendering was really hard to get right (if at
all). when you spend the majority of your waking hours editing text,
interactive response time and "editing ergonomics" matter a lot.
this reminds me that it is probably time to give IDEs another chance.
it has been a couple of years since the last time I tried a couple for
Java.
-Bjrn
[Falcolas <ga******@gmail.com>]
|
| I took a moment to look at the gui editor which has been made
| available to me, and short of the "remove leading spaces" commands, I
| do not need to remove my hands from the keyboard if I do not want
| to.
well, that depends on the editing features you use. I use a lot of
features I am not consciously aware of, so if I were to list what I
require from an editor, I would have trouble enumerating them.
I can't even tell you what keys they are bound to because I just use
them instinctively. the same goes for VI. (VI having the added
benefit of a really systematic way to organize editing actions into a
sort of a matrix (a useful metaphor I was made aware of by an "expert
VI user" who showed me how to make some editing operations more
efficiently))
having people who are good at efficient editing show you some tricks
really pays off btw. I can't bear to watch other people edit text
because they are doing so much manual labor that could have been
avoided if they had just bothered to learn more effective editing
habits.
-Bjrn
[Martin Gregorie <ma****@see.sig.for.address>]
|
| Yep, and the same people think a command line is to be avoided at all
| costs. "I mean, its so /last century/ and you can't do anything useful
| with it anyway".
I have a friend who is a carpenter. he switched to Linux a few years
ago because he was tired of how slow windows was and how easily it was
infested with malware. he really, really doesn't give a toss what it
says on the tin, he's a _user_ and that's it. to my surprise, finds
Linux as easy, if not easier to use, than windows. (he still has to
use windows for his invoicing system. everything else he does in
Linux).
I have observed similar opinions in other non-computer-freaks. people
who see the computer only as a tool and are only interested in getting
the job done. they have a surprising preference for Linux. (not many
of them have ever been exposed to OSX though, and I'd suspect they'd
prefer that since it is far more streamlined).
| Obligatory OT comment: right now I have two xterm sessions open with
| which I've been writing a Swing/JDBC app using nowt but a bash shell,
| cvs, microEmacs and (of course) J2SE. I don't need no steenking IDE.
I used J2SE, Ant, Emacs, Xterm, bash and Firefox as my main tools when
I wrote most of my production Java code. and it is not exactly what
you'd call "hobbyist projects" either. :-)
-Bjrn
Martin Gregorie <ma****@see.sig.for.addresswrites:
Bjorn Borud wrote:
Yep, and the same people think a command line is to be avoided at all
costs. "I mean, its so /last century/ and you can't do anything useful
with it anyway".
Funny ;)
It's funny that people consider typing commands to be "old-fashioned"
because pointing with a mouse is the stone-age device; typing was only
invented in the 19th century ;)
Xerox PARC (not Apple nor MIcrosoft) excelled in helping computers fit
in to how people already lived, not the other way around.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest: http://www.gnu.org/philosophy/sylvester-response.html
[David Kastrup <da*@gnu.org>]
|
| The idea is to start Emacs once and use it for everything.
....which is fine as long as you are only fiddling around on one
machine or you have emacs windows running on all your machines.
for my main use, I do start Emacs just once though. for instance at
work my Emacs has been running for as long as the machine has been up.
| so if the context was system administration, I'd vote for vi as
| well. if the context was programming I'd vote Emacs.
|
| You know you can use something like
| C-x C-f /su::/etc/fstab RET
| (or /sudo::/etc/fstab) in order to edit files as root in a normal
| Emacs session?
sure, but often it is just simpler, while you are fiddling around in a
shell, to just fire up vi to do some quick editing than to bounce back
and forth between windows. it is usually quicker too if you have to
navigate deep directory trees -- if you're already in the directory
where the file is, it'd be fewer keystrokes to specify the file than
opening it in emacs. even with tab-completion.
also, I make extensive use of the readline and history features when
fiddling about in the shell. shells have a lot of context if you use
them effectively. context that isn't easy to transport between the
shell and emacs -- and it isn't really easy to explain either.
-Bjrn
[Followup-To: header set to comp.emacs]
Bjorn Borud wrote:
sure, but often it is just simpler, while you are fiddling around in a
shell, to just fire up vi to do some quick editing than to bounce back
and forth between windows. it is usually quicker too if you have to
navigate deep directory trees -- if you're already in the directory
where the file is, it'd be fewer keystrokes to specify the file than
opening it in emacs. even with tab-completion.
well, ok, typing `emacsclient <filename>' requires more keystrokes than `vi
<filename>', but that's why i have an alias ec for it...
--
Joost Kremers jo**********@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
On 21 Jun 2007 16:52:17 +0200, Bjorn Borud <bo********@borud.nowrote:
on my tombstone will say
"here lies the last Emacs user on earth. M-x rip".
Hahaha! Very good one :-)
Falcolas <ga******@gmail.comwrites:
>
Being a primarily windows user, I have to question your assertion that
using ctrl-f for find causes a "mental context switch". For me, in 90%
of the windows applications, finding something is as simple as ctrl-f,
the phrase, hit enter. Not terribly different from your set of
commands. The biggest difference is that if I need to use a Find
feature I might not often use, I have a visual interface to all the
related search functions. On the other hand, a terminal program would
necessitate a memory search at best, or a trip to the help pages at
worst.
That's the advantage of a well-organised set of commands. If you want
to use regexp search, you have to look at the dialogue box and click on
a checkbox--which would be a context switch.
That's even assuming that your editor _offers_ regexp search. If emacs
didn't have it, I could add it, and it'd be just as much part of the
editor as if it were included...
The best part of my windows knowledge is that it's transferable to
most (all?) of the applications I work with. Find is usually ctrl-f.
Undo is ctrl-z. Save is ctrl-s, yadda yadda. Such knowledge is rarely
transferable from terminal programs in my experience -- what may be
true for one program (emacs) is wildly different in another program
(vi), and useless in yet another (pico).
Consistency is nice. That's be why the emacs are found throughout
Unix. In fact, for a long time Netscape used emacs bindings on Macs and
Windows. Among these bindings are C-a to go the beginning of a line,
C-e to go to the end, C-k to kill from point to the end of the line, M-b
and M-f to move forward and back by word and so forth.
It's Mac OS and Windows which are inconsistent. Emacs has been around
since they were mere glimmers in the eye of Jobs & Gates...
--
Robert Uhl <http://public.xdi.org/=ruhl>
Just because I'm not doing anything, doesn't mean I have nothing to do!
--Ellen Winnie
On Jun 22, 11:28 am, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
That's the advantage of a well-organised set of commands. If you want
to use regexp search, you have to look at the dialogue box and click on
a checkbox--which would be a context switch.
Again, you are assuming that the editor isn't set up in a way which
allows this to be done from the keyboard.
ctrl-f, alt-e, type, enter
That's even assuming that your editor _offers_ regexp search. If emacs
didn't have it, I could add it, and it'd be just as much part of the
editor as if it were included...
One advantage I'm more than happy to cede to you - the current program
I use is closed source and not extensible. Though, I'm sure that there
are editors for windows/mac/xwindows which are as extensible as emacs.
It's Mac OS and Windows which are inconsistent. Emacs has been around
since they were mere glimmers in the eye of Jobs & Gates...
Inconsistent? I would have to disagree. They changed paradigms -
terminal text based interfaces to GUIs. You wouldn't expect a piece of
software built for a terminal to be backwards compatibility to punch
card interfaces, would you? Why would a GUI based program limit itself
to functionality as defined by a terminal application?
On Jun 21, 12:11 pm, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
Twisted <twisted...@gmail.comwrites:
But Emacs does not have a "clunky" interface.
That's for the everyday novice-to-intermediate user to decide.
Why should the ignorant decide? Do you leave the decision of what great
art is to 3 year olds and their doting parents?
Did I say it was for the "beginner" to decide? No, I said "novice-to-
intermediate".
How clunky versus usable an interface to a tool is is for those who
invest some, but not extraordinary amounts of, time into its use to
decide. If it requires years of mastery, it is clunky -- period. This
may be unavoidable if it's something involved in nuclear power plants,
delicate neurosurgery, or whatever. If it's a text editor, on the
other hand, it's clearly going to have superior competition in the
area of usability.
Besides, ANY interface that involves fumbling around in the dark
trying to find a light switch is clunky. You should be able to see
what the hell you're doing and navigate easily. 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. An analogy to a genuine emacs experience:
you enter a workshop with some raw materials and tools. Unfortunately
there's no big ceiling lights so you can just flip the switch by the
door and then always be able to see where everything is. Instead
there's little lights here and there by various specific tools and
storage areas, and in one area a map of the place with switches to
control the lights. So first you have to fumble around until you
happen upon the map/light controls. Then you need to (in the dark!)
hit the switch for the map/light control area itself. (Now you've
found the help and gotten it to be the active pane, er "window".) Now
you need to find the tool you want on the map -- OK, that was easy.
Now you turn on its light. Oh, hell -- the light on the map/light
controls has now gone out though! That also included the instructions
on using the specific tool. You can go to and use the one tool, if you
memorized those instructions, but then it's back to the darkness...
(You find the help on doing a particular thing, then can't get back to
the document to do it because of clunky navigation. So you go back to
the help on switching windows, and now you can flip back to the
document. Only you realize you can have the document and help open at
the same time, but the only time the document has focus is when the
help is open to "help on switching windows", which makes this rather
useless! You end up having to memorize the help, because *you can't
have arbitrary parts of the help and your document open side by side
and be working on the document*. All because you can't simply tab or
click to the document. At minimum, you have to *memorize* some arcane
key controls for switching panes ... er, "windows", that are totally
unintuitive and unlike what is normally used.
Oops. The interface design is a nightmare. The most basic requirement,
that it be easy to have the help open side by side with your document
and switch back and forth and navigate inside the help easily, is
broken. If you have to consult the help just to navigate the help or
to switch focus between document and help, then you're trapped, and
that is what happens with emacs.
I don't know why people keep harping about what version. It was
probably something in the low 20s, after an earlier try with one in
the upper teens. 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. Defeating the whole purpose of
having a help system. A separate printed manual would have been
better, if I could have spared the paper and toner, as I could hold
that off to one side of the monitor and flip through it and open it to
anywhere I wanted to, then go back to my document without even having
to think about it. Even though it would be at the price of no full-
text search capability -- not that I could ever get that to work in
emacs anyway. There was no apparent way to do a simple substring
search and click "next match" or "previous match" to navigate among
the hits...more arcane keypresses would be required, and as soon as it
showed you the first match inside the help, the keypress documentation
of course vanished.
As far as I can tell, it just is not and never was possible to get
started with emacs without a separate, outside-of-emacs cheat sheet,
or to be very productive at all without actually memorizing the damn
thing. Modern user interfaces require a minimum of memorization, most
of which is basic, standard stuff that is the same from one app to the
next, so you already know it all -- your clicks and double clicks,
your alt-tabs and alt-enter-for-properties etc.; application-specific
keyboard shortcuts can be learned as convenient. 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. Every time you want to use the command but can't
remember the shortcut you just find it in the menu and activate it
from there, and see the shortcut while you're at it, helping to
eventually memorize it. And the commonest sorts of File and Edit menu
items have near-universal shortcuts, the big variation tending to be
whether Redo is shift-ctrl-Z, ctrl-Y, nonexistent, or menu-only.
But you can start using it right away with low productivity, and
increase your productivity with proficiency and learning (optional)
shortcuts, chiefly those to the commands you happen to use a lot.
Not so emacs, or most other unix-heritage tools. Those you can't use
in any nontrivial way without ascending a sheer cliff of memorization
*first*, before doing a single useful thing.
One person elsewhere in this thread even went so far as to suggest
that to avoid having a similar hurdle with every application you just
use emacs for everything. If you like being claustrophobically trapped
in 80x24x8BPP instead of 1280x1024x32BPP, that may be your cup of tea.
Also if you like having zero productivity in every single task instead
of just one until you've scaled the El Capitan of user interfaces. On
the other hand, you can avoid having a similar hurdle with ANY
application by simply using standard GUI apps developed with Mac and
Windows users in mind. I hear they even have them for Unix now --
technically including everything written for MacOSX as well as modern
WMs on Linux and probably *BSD.
(Use emacs for everything? That's like suggesting I move all my tools
*into* that dark place with the screwy lighting system, rather than
*out*. Me, I'd rather just avoid that place, or if necessary bring in
a big bank of floodlights and install them, and the sensitive artiste
who originally architected it be damned. Which is what Xah started
this whole mess by suggesting, in effect.)
On Jun 21, 12:09 pm, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
Twisted <twisted...@gmail.comwrites:
I have that exact URL now --
http://www.asktog.com/columns/027Int...sThatKill.html
Utterly unrelated to Emacs.
I think it is quite relevant. Clunky computer interfaces may not be so
dramatically dangerous, but they certainly can hamper productivity.
You're quite right. Windows/Mac user interfaces are so clunky that they
massively hamper productivity.
This is a joke, right?
Emacs, OTOH, enables it. For example,
C-s is search forward; C-r is search backward ('reverse'); C-M-s is
search forward for a regular expression; C-M-r is search backward for a
regular expression.
Aside from the collision with the standard in the case of C-s (should
be save focused document if it has unsaved changes), these present no
problem. The inability to find and use them without memorizing all
those keystrokes does present a problem.
A Windows or Mac editor would have C-s for save,
and that's it. It might have C-f for find, but it'd pop up a dialogue
instead of offering an interactive search, causing a mental context
switch.
Eh? In other words, it works the way it's supposed to. That dialogue
will ordinarily be modeless but floating, so you can get it out of the
way or use it to navigate the document, then edit the document without
having to close the dialogue, and avoid the dialogue disappearing
behind other things. New search can be typed in at the drop of a hat.
Some editors have regular expression searches. All have a
straightforward substring search. Generally if there's anything in the
least arcane (e.g. regular expression searches) there's a ? button to
pop up help, which goes directly to the search help. You can read this
and tab back to the search dialogue with ease, and get them side by
side without any mess or fuss. Of course the dialog offers search
forward and usually search backward. And it normally also offers
search-AND-REPLACE, to boot.
Is this somehow not "interactive" enough for you? Versus having to
memorize a bunch of keys. It also means no esc-meta-alt-ctrl-shift BS,
as the document window needs to have only a few bindings, such as C-f
and C-s, and only the one (C-f) for search; all the search bindings in
the one window in emacs get replaced by just one binding in the
document window and a bunch applicable to the find dialogue. And the
find dialogue can be operated without knowing the bindings by mouse,
and the bindings can be seen directly in the find dialogue by
underlined letters on button labels (see that underlined N in "find
Next"? It means you can hit alt-N while the dialogue has focus,
followed by alt-tab to jump to the document with the next occurrence
selected, or alt-N repeatedly to jump to later occurrences until you
see the one you want, just in case you have rodent allergies).
It has useful key bindings. It is also wise enough to make learning
them optional, so you can learn the ones that speed up your most
common tasks and spare the effort otherwise, where it would consume
more time than it would eventually save you (less common tasks). With
an emacs type interface, you only get to ignore the key bindings for
commands you will NEVER use, rather than ones you use but
infrequently. Forgetting the latter means a trip to the help every
time, also.
Searching would interrupt one's flow of thought rather than being part of it.
Where does this come from?
Twisted <tw********@gmail.comwrites:
On Jun 21, 12:09 pm, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
>Twisted <twisted...@gmail.comwrites:
I have that exact URL now --
http://www.asktog.com/columns/027Int...sThatKill.html
>Utterly unrelated to Emacs.
I think it is quite relevant. Clunky computer interfaces may not be so
dramatically dangerous, but they certainly can hamper productivity.
You're quite right. Windows/Mac user interfaces are so clunky that they
massively hamper productivity.
This is a joke, right?
How do you call a Mac user interface that let a user work during 3
hours to do a simple modification to a MS-Word file that takes 15
seconds to do with emacs or a simple unix script?
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On Jun 22, 3:06 pm, Pascal Bourguignon <p...@informatimago.comwrote:
How do you call a Mac user interface that let a user work during 3
hours to do a simple modification to a MS-Word file that takes 15
seconds to do with emacs or a simple unix script?
Would you mind elaborating on *what* took 3 hours to do, as opposed to
just throwing around unquantified numbers? Would you also mind
explaining the user's familiarity with the tools they were using on
the mac?
It's just as easy for me to say that it took me 30 minutes to simply
exit emacs, and use that to justify that emacs, and by extension
Linux, is a terrible tool.
On Jun 22, 3:47 pm, Twisted <twisted...@gmail.comwrote:
If it requires years of mastery, it is clunky
Well, now you keep harping on this, but it's just not true.
I use vim myself, but for purposes of this argument it doesn't matter.
If you take the Vim tutorial and use the help (which appears in a
split window anytime you want it), you can use Vim like any other text
editor within a day or so, especially if you use Cream, which is set
up to hold your Windows hands and act like any other Windows text
editor on the surface. But if you use Vim for YEARS you get better and
faster and more efficient precisely BECAUSE of its arcane
capabilities. If you are going to keep your hands on the keyboard
where they belong, if you REALLY want to go fast, then there's no
alternative to having complex key commands, which become second nature
over time, and take the place of repetitive, totally inefficient
mousing around.
You might enjoy this. Especially the link to an old essay called
"Interface Zen" http://tinyurl.com/2da3om
rd
On Jun 21, 11:06 am, jadam...@partners.org (Joel J. Adamson) wrote:
And it's baloney! No one in my office that uses one of these supposedly
user-friendly machines thinks that it's actually easy to use. They
slam their keyboards and throw their hands up *every* day.
Because of bugs or the network going down or stuff like that, I'll
bet, not because they can't find out or remember how to do some basic
task.
That's entirely orthogonal to the issue of interface learning curve OR
interface ease-of-use. Emacs has deficiencies in both areas, if
principally the former. (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. Now THAT is what I call
disruptive context switching. Meanwhile even the lowly Notepad
responds to "open" by displaying a list of text files and tools to
navigate the folder hierarchy without having to do it blind, while
still letting you blind-type a path if you remember it. And you can
also paste the path in from the clipboard. Unix systems don't even
*have* a proper system-wide clipboard and copy/paste capability. Under
X there's a weak, text-only imitation, which doesn't help you much
when you want to copy a selection from an image in a paint program and
paste it into a CAD or web-design or specialized image-manipulation
tool or whatever...you have to save it to a file and load it, which is
a pain in the butt and slowly clutters your hard drive with
"temporary" files you occasionally forget to delete.
The only solution that really works is for people to _learn_ how to
use computers, and to accept that it will be a challenge.
How much learning it takes can be varied by the programmer, however.
They can choose to make the learning curve steeply vertical at
takeoff, or they can make it start out shallow and climb steeply only
when the user desires expert functionality. (They can also, stupidly,
choose to leave out fancier functionality entirely, of course.)
As for bugs and other frustrations, better robustness in the key areas
of memory management and concurrency control is needed. Most serious
(especially crash-causing, data-losing, or data-corrupting) bugs
involve memory mismanagement and a lot more, as well as other serious
bugs, result from race conditions. These sorts of bugs are also
responsible for a lot of security holes -- buffer overrun exploits are
only possible against targets with memory management and input
validation bugs. Java apps, due to Java's memory management model, are
immune to these.
The Windows world may have a fair bit to learn from the Unix world
about software reliability and QA, and also about better supporting
task automation. But not about user interface design for when tasks
are done manually.
And as for the arcane commands needed to get to the help page, their
on the splash screen. Have you used Emacs recently?
Of course not. It's too hard to get started using it, so I gave up on
it years ago.
On Jun 21, 12:03 pm, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
Twisted <twisted...@gmail.comwrites:
Emacs is amazingly beginner-friendly for the power and flexibility it
provides. [snip]
That's a joke, right? I tried it a time or two. Every time it was
rapidly apparent that doing anything non-trivial would require
consulting a cheat sheet. The printed-out kind, since navigating to
the help and back without already having the help displayed and open
to the command reference was also non-trivial.
C-h i, C-x b RET is non-trivial?!?
Let's change that so that you see it the way most human beings see it:
navigating to
the help and back without already having the help displayed and open
to the command reference was also non-trivial.
Erh h, dhsd f hHE is non-trivial?
I'm sorry. I don't speak Chinese.
I trust I've made my point. Not only does it insist you learn a whole
other language (though I'm guessing it's not actually Chinese --
Greek, maybe), even when you know that's a bunch of keystrokes and
even what they are...
HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL
THEM THOSE ARE THE KEYS TO REACH THE HELP?!
I suppose it just pops in there by divine inspiration? Or it's
supposed to be self-evident to anyone who has TRUE wisdom? Or maybe
it's just expected that you be mentored by an expert, who would know
that arcane incantation and could pass it on to a new student. Well
I've got news for you buddy -- there's no such thing as divine
inspiration, it's not self-evident, and most people can't afford (if
they could find) a tutor just to learn how to use A TEXT EDITOR.
Of course, Notepad is so easy to use it doesn't even need help,
despite which it's readily available. In case you forgot the bog-
standard (and therefore it IS self-evident) "F1" there's even a "Help"
menu in plain view as soon as you open a Notepad.
This is the lowly Notepad, which I'll freely admit is the rusty
bicycle of text editors, and it's much easier to use (including the
help) than the supposed Mercedes-Benz of editors.
[remainder snipped, apparently describing some piece of software that
presents you automatically with an emacs tutorial if you start emacs
while it's running. I've seen emacs a few times in my day but never
whatever unnamed piece of software is being referred to here...but it
does occur to me that a context-sensitive auto-popup cheat sheet tool
would be useful on the typical unix system!]
On Jun 21, 10:52 am, Bjorn Borud <borud-n...@borud.nowrote:
[Twisted <twisted...@gmail.com>]
|
| Being beginner-friendly doesn't have to be at the expense of power or
| expert-user usability.
depends on your definition of "expert". :-)
Well, admittedly, if your definition of "expert" is "elitist pig who
considers beginner-hostileness itself to be a required feature in
order for him to regard the software as usable", then you may be
right.
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. Only if they "value" such perverse
things as "being one of the exclusive club that can actually manage to
use this thing" does any of this make sense. That's a form of
artificial scarcity, and as I think I've mentioned before, artificial
scarcity is one of the more major roots of evil.
Twisted wrote:
Of course not. It's too hard to get started using it, so I gave up on
it years ago.
So wtf makes you think you're remotely qualified to comment about
emacs as it stands today? Idiot.
On Jun 21, 11:11 am, Lew <l...@lewscanon.nospamwrote:
Joel J. Adamson wrote:
My point is that I'm the sort of person that has a mind set up for
Emacs. I had none of the difficulties that someone else might have,
who's used to other kinds of software.
However, I'll also point out that my wife has used Emacs a couple
times, and she's never done more than point and click with a computer,
and she's had no frustration whatsoever.
A new user of two hours' experience. A father of a six-year old whose child
hums along happily with emacs. A computer widow who "had no frustration
whatsoever" with it.
To the claim that "emacs is too hard for the beginner" we have a mounting pile
of steaming evidence that refutes.
It's a steaming pile of something, of that I am sure, but I don't
think "evidence" is the word I'd use to describe it. The word I'm
thinking of IS eight letters long, but it starts with "b" instead of
"e"...
I find these anecdotes liberally sprinkled into this thread frankly
unbelievable. Either they are not using the same software I understand
"emacs" to refer to, or someone somewhere is simply lying. Or maybe
there's a bunch of prodigies around and they all picked now to pipe
up? We can't design software or any other tool to cater exclusively to
a handful of Mozarts, though, unless there's no reason to believe
anyone outside that small and exclusive club will ever have a use for
it.
To the claim that the help is too hard to use comes the evidence that three
simple keystroke patterns are all one needs to know, and anecdotal evidence of
the help system's utility.
Utility is nothing without usability. In particular, no matter how
much useful content the help might have, the fact that when the
document window has the focus the help is always open to the section
on switching windows rather puts a crimp in the actual usability of
that information. The only times you can use it and the only times you
can read it are non-overlapping sets.
Some will refuse to face the truth. To the open-minded, let the facts speak
for themselves.
A few anecdotes prove nothing. A first year statistics 101 dropout
knows that much.
Falcolas <ga******@gmail.comwrites:
On Jun 22, 3:06 pm, Pascal Bourguignon <p...@informatimago.comwrote:
>How do you call a Mac user interface that let a user work during 3
hours to do a simple modification to a MS-Word file that takes 15
seconds to do with emacs or a simple unix script?
Would you mind elaborating on *what* took 3 hours to do, as opposed to
just throwing around unquantified numbers? Would you also mind
explaining the user's familiarity with the tools they were using on
the mac?
Anything that the user have to do repeatitively with the GUI, like
copy-and-paste, or reformating of a lot of paragraphs or table
entries, and which is done automatically by writting a one-liner
program in emacs or shell.
And they tried to put graphical user interfaces on scripting, it
doesn't work either. Programming is working with text, with verbs.
It's just as easy for me to say that it took me 30 minutes to simply
exit emacs, and use that to justify that emacs, and by extension
Linux, is a terrible tool.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Twisted <tw********@gmail.comwrites:
The Windows world may have a fair bit to learn from the Unix world
about software reliability and QA, and also about better supporting
task automation. But not about user interface design for when tasks
are done manually.
That's the point. Manual tasks have nothing to do in computers.
Computers are there to automatize tasks, not to give you more manual work.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Twisted wrote:
You end up having to memorize the help, because *you can't
have arbitrary parts of the help and your document open side by side
and be working on the document*.
WTF? Of course you can. http://oldr.net/emacs_two_frames.png
I don't know why people keep harping about what version.
Perhaps because essentially none of the crap you're spouting corresponds
to remotely recent versions of emacs they're are aware of. I'd be
increasingly dubious much applies to any previous versions either.
If everyone had such bizarre problems you describe yourself as having
with emacs, well, nobody would be using it. That is clearly not the
case. Of course, no one's pointing a gun at you and making you use it,
either - if you like notepad or joe or whatever, just use them instead.
Some entity, AKA Twisted <tw********@gmail.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
On Jun 21, 12:03 pm, Robert Uhl <eadmun...@NOSPAMgmail.comwrote:
Twisted <twisted...@gmail.comwrites:
>Emacs is amazingly beginner-friendly for the power and flexibility it
>provides. [snip]
That's a joke, right? I tried it a time or two. Every time it was
rapidly apparent that doing anything non-trivial would require
consulting a cheat sheet. The printed-out kind, since navigating to
the help and back without already having the help displayed and open
to the command reference was also non-trivial.
C-h i, C-x b RET is non-trivial?!?
Let's change that so that you see it the way most human beings see it:
navigating to
the help and back without already having the help displayed and open
to the command reference was also non-trivial.
Erh h, dhsd f hHE is non-trivial?
I'm sorry. I don't speak Chinese.
I trust I've made my point. Not only does it insist you learn a whole
other language (though I'm guessing it's not actually Chinese --
Greek, maybe), even when you know that's a bunch of keystrokes and
even what they are...
HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL
THEM THOSE ARE THE KEYS TO REACH THE HELP?!
What's your problem ?
Ofcourse a mere program-consumer would not look what was being
installed on his/her system in the first place ...
So after some trivial perusing what was installed and where :
WOW Look, MA ! .... it's all there!
lpr /usr/local/share/emacs/21.3/etc/refcard.ps
or your install-dir........^ ^
or your version.............................^
But then again buying the GNU-book from 'O Reilly would have solved it
in the utmost nicest possible of ways anyway.
Buying or printing the GNU-Emacs Reference Manual should do
quit a memorable job also.
But then again there allways will be people that cannot find their way to
the outhouse even when it stinks a mile a minute.
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
The biggest problem LISP has, is that it does not appeal to dumb people
If that fails to satisfy read the HyperSpec, woman frig or Tuxoharata
mailpolicy @ http://www.clsnet.nl/mail.php
On Jun 22, 11:52 am, Bjorn Borud <borud-n...@borud.nowrote:
[Martin Gregorie <mar...@see.sig.for.address>]
|
| Yep, and the same people think a command line is to be avoided at all
| costs. "I mean, its so /last century/ and you can't do anything useful
| with it anyway".
I think a command line can be useful as a way to directly talk to
something's brain. More GUI apps should have a command processor you
can access to do something arcane once in a while. The other thing a
command processor is good for is providing automation support.
Windows is definitely weak on allowing things like editors to be
embedded and used as components by other applications. OLE makes it
theoretically possible to e.g. use Winword in an IDE but who'd want
to? It also doesn't provide a system-wide way to select particular
components to do particular jobs -- the closest thing would be
splitting comctl32.dll into separate dlls for each common task or
dialog and allowing third-party drop-in replacements to be found in a
user-specific directory that override the defaults. That sort of
modularity and choice is alien to MS thought patterns however.
Combining the flexibility of componentry in Unix with the graphical
power of Windows might lead to something awesome ... which makes KDE
and Gnome things to keep eyes on in the future.
I have observed similar opinions in other non-computer-freaks. people
who see the computer only as a tool and are only interested in getting
the job done. they have a surprising preference for Linux.
But not emacs, I'll bet. I think emacs appeals to people who like
dealing with the mechanics of emacs or fiddling with and extending the
darn thing. But most people just want to get the job done, and the
editor or other tools they use have to get out of the way and simply
let them work. If their attention keeps being dragged forcible from
THE JOB to THE TOOL and how to make this cantankerous thing do *this*?
then there is a problem. If I sit down at a windows text editor (or
even kwrite or similar) I can just focus on the job. Faced with emacs
or most other text-mode editors (but not MS-DOS Edit, interestingly)
the editor keeps intruding on my focus. Oops.
Elsewhere, you mentioned 3 second attention spans -- I think you'll
find people are much more willing to spend 3 hours of attention on
their task than 3 seconds on your favorite tool. When the tool
intrudes into the user's attention (either by misbehaving, e.g.
crashing, or by confounding the user as to how to do what they want to
do next), then a problem is evident.
On Jun 22, 4:12 pm, Pascal Bourguignon <p...@informatimago.comwrote:
Anything that the user have to do repeatitively with the GUI, like
copy-and-paste, or reformating of a lot of paragraphs or table
entries, and which is done automatically by writting a one-liner
program in emacs or shell.
So the tool they were using did not support macros? You're right, that
would suck. I'm guessing this is before you could expose the Unix
underpinnings on the mac.
I will agree that I do miss much of the standard shell utility when
working in windows. Fortunately, I am able to replace a lot of that
with well written python or perl scripts.
And they tried to put graphical user interfaces on scripting, it
doesn't work either. Programming is working with text, with verbs.
Recording macros could be considered a form of programming, which can
have nothing to do with any text. Granted, they're pretty dumb if you
don't manually modify them, but really, nothing is stopping you from
modifying them either. I can't count the number of times I've created
a macro to do repeated modification of a text file.
I guess ultimately I'm trying to argue the point that just because a
tool was written with a GUI or on Windows does not automatically make
it any less a productive tool than a text based terminal tool. Even in
windows, you can use the keyboard to do all of your work, if you learn
how (thanks to the magic of the alt key).
On Jun 21, 10:48 am, Lew <l...@lewscanon.nospamwrote:
Bjorn Borud <borud-n...@borud.nowrites:
so if the context was system administration, I'd vote for vi as
well. if the context was programming I'd vote Emacs.
David Kastrup wrote:
You know you can use something like
C-x C-f /su::/etc/fstab RET
(or /sudo::/etc/fstab) in order to edit files as root in a normal
Emacs session?
I've been using emacs for something like twenty years and never knew that before.
I like the built-in therapist in emacs.
I think both of Lew's sentences here speak volumes.
One about the difficulty even supposed expert users can have with
tasks and finding things out from the help system. (I take it unix has
also still not caught up to the windows world in the concept of a "tip
of the day"?)
And both of them, though especially the latter, regarding what a
feeping creature emacs is. I don't suppose there's also a kitchen sink
in there somewhere? Or is that just nethack?
PS you'll have to stop posting such a high volume here. I'm getting BS
from Google Groups about posting limits being exceeded again.
Apparently they've lowered it still further, from 25 in a 24 hour
period to 12 or so in a 24 hour period. Fuckers.
On Jun 22, 6:32 pm, Cor Gest <c...@clsnet.nlwrote:
HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL
THEM THOSE ARE THE KEYS TO REACH THE HELP?!
What's your problem ?
Ofcourse a mere program-consumer would not look what was being
installed on his/her system in the first place ...
So after some trivial perusing what was installed and where :
WOW Look, MA ! .... it's all there!
lpr /usr/local/share/emacs/21.3/etc/refcard.ps
or your install-dir........^ ^
or your version.............................^
So now we're expected to go on a filesystem fishing expedition instead
of just hit F1? One small step (backwards) for a man; one giant leap
(backwards) for mankind. :P
But then again buying the GNU-book from 'O Reilly would have solved it
in the utmost nicest possible of ways anyway.
So much for the "free" in "free software". If you can't actually use
it without paying money, whether for the software or for some book, it
isn't really free, is it? The book assumes the role of a copy
protection dongle*. Of course, if the book is under the usual sort of
copyright and not copyleft, so much for the "free as in speech" too,
and nevermind the "free as in beer".
* In fact, I not-too-fondly remember the days when a common copy
protection scheme was for software to periodically (or at least on
startup) insist that the user enter the first word on page N of the
manual, for various changing choices of N. Making the interface simply
unnavigable without the manual strikes me as nearly as effective. If
someone did decide to intentionally cripple the interface of some
"free" software and make a killing off a book de-facto required to use
it, it would be quite the racket. I hope the open source movement
would chew them to pieces and curse them in public though.
Twisted wrote:
I find these anecdotes liberally sprinkled into this thread frankly
unbelievable. Either they are not using the same software I understand
"emacs" to refer to, or someone somewhere is simply lying.
So if someone provides evidence with which you disagree, you accuse them of lying.
There's no opportunity for reasoned discourse in the face of such tactics. Or
room for new information to combat one's prejudices.
--
Lew
Some entity, AKA ne********@gmail.com,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
On Jun 22, 6:32 pm, Cor Gest <c...@clsnet.nlwrote:
HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL
THEM THOSE ARE THE KEYS TO REACH THE HELP?!
What's your problem ?
Ofcourse a mere program-consumer would not look what was being
installed on his/her system in the first place ...
So after some trivial perusing what was installed and where :
WOW Look, MA ! .... it's all there!
lpr /usr/local/share/emacs/21.3/etc/refcard.ps
or your install-dir........^ ^
or your version.............................^
So now we're expected to go on a filesystem fishing expedition instead
of just hit F1? One small step (backwards) for a man; one giant leap
(backwards) for mankind. :P
that's M-` Escape-Backtick in a CLI, for you, thank you very much ...
Function-Keys do not work in in a vt100 terminal.
You really are that shallow, aren't you ? and lazy too, huh ?
copyright and not copyleft, so much for the "free as in speech" too,
and nevermind the "free as in beer".
Download & print the junk then.
Ofcourse you pay your ISP for the priviledge & give some treehuggers a
nervous brakedown in the process.
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
The biggest problem LISP has, is that it does not appeal to dumb people
If that fails to satisfy read the HyperSpec, woman frig or Tuxoharata
mailpolicy @ http://www.clsnet.nl/mail.php
Twisted wrote:
I find these anecdotes liberally sprinkled into this thread frankly
unbelievable.
If you'd spent as much time learning the software as you're ranting
about it, you could actually use it _and_ would get the additional
benefit of having avoided making a fool of yourself on Usenet. Of course
that would have been too easy, wouldn't it? This thread has been closed and replies have been disabled. Please start a new discussion. |
