The Modernization of Emacs

[David Kastrup]

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?!

Because there is a menu called "HELP" and because the "standard"
keybinding for help, f1, brings up help?

Not to mention that there is an initial splash screen pointing this
out?

 

[David Kastrup]

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.

Actually, in Emacs the task more often than not is solved by using
C-h a or M-x apropos and then finding the command that already does
the job.

Somebody who needs 30 minutes to find the File/Exit Emacs menu is not
qualified for reporting _any_ computing experience.

It is like letting yourself get a report about the points of violin
playing from somebody who has just had his first exposure to music,
incidentally in the form of a violin lesson.

 

[David Kastrup]

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?

You are aware that the ubiquitous standard terminal width of 80
columns has been chosen to match the 80-column punch card standard?

Why would a GUI based program limit itself to functionality as
defined by a terminal application?

Emacs uses variable width fonts, can deal with a larger-than-8bit
variety of GUI-based input events and can display images. Take a look
at the screen shots for preview-latex
<URL:http://www.gnu.org/software/auctex/preview-latex.html>
illustrating WYSIWYG LaTeX editing in Emacs windows.

So what is your problem?

 

[David Kastrup]

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?!

Because there is a menu called "HELP" and because the "standard"
keybinding for help, f1, brings up help? And because there is that
standard GNOME icon of a lifesaver which you can click?

Not to mention that there is an initial splash screen pointing most of
this out?

 

[David Kastrup]

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.

Oh, but that just means that _YOU_ will have to stop posting such a
high volume here. Others are not affected. Though I have no doubt
they'll welcome a thinning out of this thread (followups directed to
comp.emacs for that reason).

Apparently they've lowered it still further, from 25 in a 24 hour
period to 12 or so in a 24 hour period. Fuckers.

How about making _summary_ answers then? Your whole contributions
boil down to "You must be lying. This can't be Emacs you are talking
about, since I know Emacs intimately because of having looked at an
old version of it for half an hour about 10 years ago." anyway. You
don't need to post this 12 times per day. You don't even need to post
this at all. It does not get any less stupid by repetition.

What _is_ sort of amusing is that years ago you already accused me of
forgery when I pointed you to the Emacs screenshots on the
preview-latex
<URL:http://www.gnu.org/software/auctex/preview-latex.html> page.

It appears that you still have not bothered educating yourself, years
after you were pretty much universally derided in comp.text.tex for
making a spectacle of your self-chosen ignorance.

 

[Cor Gest]

Some entity, AKA Tim Roberts <[email protected]>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)

Boys, do you really not understand that this is a religious issue? You
can't use arguments and logic to convince someone to convert their
religion, and you can't use arguments and logic to convince someone to
change editors.

Nah, nothing beats a nice flame-war on a slow fridaynight & a Pint
of Bitter, while it spares the fingers to keep on manipulating all those nice
keyboard-modifiers to nag the ignorati for an other day ... ;-)

Cor

 

[Bjorn Borud]

[Twisted <[email protected]>]
|
| > 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.

no, Emacs is not among the applications they use. nor are any IDEs or
compilers. I don't think Emacs is that relevant to these users since
what they do is mostly word-processing, spreadsheets, mail and web
browsing. Emacs is not really targeted at Word processing as
such. (although that doesn't stop some people from thinking that it
would be a good idea to turn Emacs into a wordprocessing application
with support for graphics, mixed fonts etc.)

I use Emacs for creating documents, but this is very different since I
use LaTeX and I'm a programmer, so it is very conventient for me to
use a system that allows me to treat documents like code (with respect
to revision control systems etc). outside academia or the technical
community, not that many use LaTeX, but I have seen it in the past.

-Bjørn

 

[Martin Gregorie]

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

A good reference. Thanks.

I like Interface Zen - much sense there.

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.

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.

Where does emacs fit on this grid? My guess would be 3 and 4.

Its very difficult indeed to design an interface that suits both
untrained and expert users. 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.

 

[Bjorn Borud]

[Twisted <[email protected]>]
| 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.

yes you can. you even have a lot of choice as to how you want to do
it and it even works on the simplest of text terminals (which is
useful when you are on the road and only have a computer with a
browser availabe and you've had the foresight to set up the Mindterm
SSH applet on a machine so you can log in and edit code from anywhere
in the world).

I use multiple frames on-screen most of the time. either to edit and
view multiple files at once or to edit different locations of the same
file. if you're a programmer it is often useful to be able to do
this. you can look at more than one file at the same time, have
documentation up on screen etc.

| 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.

following the built-in tutorial in Emacs I understood how to
manipulate buffers and split windows in various ways. there are
basically three commands you need to know. one of them is used to
switch between active buffers in a given window, so it is not specific
to splitting.

it took me minutes to learn and within days I didn't even think about
what I was doing -- I was just using the features.

I think you fail to understand the approach. if you know an editor
like VI or Emacs properly you have a much bigger bag of tricks, that
are applicable to a wide range of scenarios, than what is encouraged
by GUI intensive editors. and you don't think of them as "tricks".
it is just the way you edit text.

| 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.

why don't you learn Emacs before you say what it can and can't do?
it is so frustrating to debate editors with people who haven't even
bothered to make a minimal effort to at least spend a day or two
learning it.

let's look at Word and word processing. how long does it take you to
learn Word properly? to understand how to efficiently edit large
documents, automate common tasks, use the built-in features for
helping you organize documents?


-Bjørn

 

[Martin Gregorie]

Xerox PARC (not Apple nor MIcrosoft) excelled in helping computers fit
in to how people already lived, not the other way around.

I've never got my hands on a genuine Xerox. About the nearest to that I
managed was an ICL PERQ back in 1980, with a portrait-mode black and
white screen and a three button mouse. That was the first GUI I saw
(next was an Apple Lisa in 1984). The PERQ was dead easy to use after
about 5 minutes instruction.

 

[Bjorn Borud]

[Falcolas <[email protected]>]
|
| 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).

as I see it, the debate isn't whether GUI tools are inferior per se,
but whether Emacs is inferior since it has its own interaction
concepts that do not map 1:1 to GUI conventions of Windows and OSX.

the point I am trying to get across is that Emacs (and vi) is its own
niche, and that if you want to improve them, there are more important
things than fiddling around with superficial details (like keybindings
-- which you can customize to your own liking anyway).

for Emacs it would be far more helpful if the Lisp-implementation was
replaced with one that is more efficient and Common Lisp-like.
(indeed several friends of mine would like to see Emacs done in Common
Lisp, and I seem to have some memory of such a project existing
somewhere).

-Bjørn

 

[David Golden]

[Falcolas <[email protected]>]
|
| 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).

as I see it, the debate isn't whether GUI tools are inferior per se,
but whether Emacs is inferior since it has its own interaction
concepts that do not map 1:1 to GUI conventions of Windows and OSX.

I think it worthwile to point out again here that emacs does in fact
have a bitmapped, windowy GUI, has done for years - e.g.
http://oldr.net/emacshelp4.gif ...
Some people in this silly thread (not Bjørn specifically) seem to be
labouring under the impression that it is solely a text-only
interface - "Mouse longcuts" exist for the most basic keyboard commands
when you're using emacs on a WIMP system like X11 or Microsoft Windows
(though you can turn them off to stop wasting screen real estate on
pretty-pretty once you know the keyboard commands)

(indeed several friends of mine would like to see Emacs done in Common
Lisp, and I seem to have some memory of such a project existing
somewhere).

Climacs @
http://common-lisp.net/project/climacs/

 

[Bjorn Borud]

[Twisted <[email protected]>]
|
| 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).

-Bjørn

 

[Matthias Buelow]

Editors are like underwear. We each have our own favorite brand, and
nothing you say will convince me to change mine.

You really should have stopped here....

 

[David Kastrup]

You really should have stopped here....

Well if "It stinks!" is not incentive enough for him to change his
underwear, what will?

 

[Robert Uhl]

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.

You've never actually run emacs, have you?

 

[Robert Uhl]

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?!

Because WHEN YOU START EMACS IT DISPLAYS A MESSAGE TELLING YOU HOW TO
GET TO THE TUTORIAL. ONCE YOU'VE FOLLOWED THE TUTORIAL YOU KNOW
EVERYTHING YOU NEED TO KNOW.

If you had ever actually run emacs you'd know this.

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.

Any modern emacs comes with F1 configured to start the help system too.
Wow!

[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...

The message about the tutorial is displayed by a piece of software
called 'emacs.' It's the piece of software we've talking about this
entire time. It does this every time you start it. Every single time.
Without fail. Of course, if you somehow missed it, you could also go to
the menu titled, helpfully, 'Help'; the first item therein is 'Emacs
tutorial'; the second is 'Emacs tutorial (choose language).'

If you had ever actually run emacs you'd know this.

Do you think that Mercedes are awful cars because their engines don't
start when you turn the key in the ignition? Do you think homemade
burgers are disgusting because cheese doesn't melt on them?

 

[Robert Uhl]

So now we're expected to go on a filesystem fishing expedition instead
of just hit F1?

Interestingly enough, f1 _is_ bound to the help system in emacs. So's
C-h. So's the 'help' key.

 

[blmblm]

[Giorgos Keramidas <[email protected]>]
|
| Educating the user to avoid confusion in this and other cases of made
| up, 'user-friendly' descriptions is not a good enough answer.

there are two types of "user friendly". there's "user friendly" and
then there is "beginner friendly" which is often mislabeled. the
latter is more important for applications which are to be used
casually. like utilities you only use once or twice per year -- those
need to be "beginner friendly".

Maybe this is an okay point at which to mention one of my favorite
bits of commentary on this subject. It's an interview with Leslie
Lamport (originator of LaTeX, among other things) in which he
talks about the needs of beginners versus the needs of experts,
and how the latter are often neglected:

http://research.microsoft.com/users/lamport/pubs/lamport-latex-interview.pdf

(Yes, he works (worked? but this seems current) for Microsoft.
Astonishing.)

Asked whether whether LaTeX is hard to use, he replies "It's easy
to use -- if you're one of the 2% of the population who thinks
logically and can read an instruction manual. [otherwise not]"

for applications you are likely to use for prolonged periods of time
(like programming, video editing, music production etc), it does not
make sense to optimize for "beginner friendly". at least not at the
cost of making the application less "user friendly".

applications you spend a lot of time using are worth an investment in
learning how to use them. what creates friction in an application you
know reasonably well is when common tasks are fiddly. for instance,
while menus are often good for casual use and lower the initial
threshold for absolute beginners, depending heavily on menu navigation
becomes too fiddly if you are performing a certain task 2-3 times per
minute. it is not _user_ friendly.

Sing it, brother.

(I'm a vim fan myself, but my thinking is that these days emacs
and vi(m) people should be banding together against a common enemy
rather than carrying on the fine old tradition of arguing with
each other. We have in common a preference, maybe, for learning
one editor really well and using it for everything.)

 

[Robert Uhl]

for Emacs it would be far more helpful if the Lisp-implementation was
replaced with one that is more efficient and Common Lisp-like.
(indeed several friends of mine would like to see Emacs done in Common
Lisp, and I seem to have some memory of such a project existing
somewhere).

Agreed. Stallman got sidetracked by Scheme, which IMHO was a dead-end.
A Common Lisp emacs would be pretty sweet. There's a Climacs project,
but they're just focused on providing an editor, not on providing a
full-fledged emacs.

--
Robert Uhl <http://public.xdi.org/=ruhl>
Cinder blocks: $100
Mortar: $30
A cask of amontillado: $300
The faint screams of a desperate PHB: priceless. --O. Schwarz