The Modernization of Emacs

[David Golden]

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.

 

[Twisted]

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.

 

[Pascal Bourguignon]

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.

 

[Pascal Bourguignon]

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.

 

[David Golden]

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.

 

[Cor Gest]

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

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:

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

 

[Twisted]

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

 

[Falcolas]

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

 

[nebulous99]

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.

 

[nebulous99]

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.

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.

 

[Lew]

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.

 

[Cor Gest]

Some entity, AKA (e-mail address removed),
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)

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.

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

 

[Matthias Buelow]

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?

 

[David Golden]

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.

"emacs or most other text-mode editors" sounds very much like you
believe emacs works in a pure text mode too? It can, of course, and
that's a good thing, but that's certainly not how I usually use it -
it has a GUI, you know.

 

[Tim Roberts]

bah, UNIX is not user hostile; it is just selective about its
friends.

Right. My favorite Unix quote is from the same source (Dennis Ritchie):

Unix is the answer. You just have to phrase the
question very carefully.

 

[Tim Roberts]

Some entity, AKA (e-mail address removed),
wrote this mindboggling stuff:


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 ?

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.

Editors are like underwear. We each have our own favorite brand, and
nothing you say will convince me to change mine. Editor, that is. I do
occasionally change my underwear.

 

[Robert Uhl]

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?

You're making the assumption that Mac OS in 1984 offered some textual
capability (textual, since we're discussing text editing) which emacs
did not. It didn't.

 

[Robert Uhl]

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.

Of course, emacs doesn't take years of mastery. It takes 30, 40
minutes. And a functioning intellect, of course.

Incidentally, a violin requires years of mastery, and is hardly cranky.
Granted, there are few people with the talent to play a violin well.
Maybe an automobile is a better example...

Besides, ANY interface that involves fumbling around in the dark
trying to find a light switch is clunky.

That sounds like vi, not emacs.

Applications that not only eschew normal methods of navigation of the
interface, but force you to fumble your way between the help and the
task you're trying to do, are definitely clunky.

a) emacs doesn't 'eschew normal methods of navigation'; it's been doing
its own thing since before there _were_ Mac OS or Windows

b) I believe you've never used the emacs tutorial, which is quite
definitely designed for you _not_ to have to fumble around between
windows

The interface never improved over that time -- the biggest problem
consistently being that whenever focus was successfully transferred to
the document window, the help window was invariably open to the
instructions for switching windows, so you could never be doing
something with the document and have the help for that something
available at a glance.

That doesn't even make sense. Either your memory is faulty, you've
never actually used emacs (something I'm beginning to suspect more and
more) or you're just making things up. If I'm browsing the manual
online, I can switch from said manual to my document buffer without
making the manual scroll to the documentation for switch-to-buffer. In
fact, I am not aware of any package which auto-changes the *info* or
*Help* buffers to reflect the last keyboard command.

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.

Dude, you hit C-s; you're prompted for a search string; you hit C-s to
search for the next match. From line 899 of the tutorial:
type the word 'cursor', pausing after you type each
character to notice what happens to the cursor.
Now you have searched for "cursor", once.
If you had actually, you know, actually _read_ it this would not be a
surprise. I hate to be rude, but I just don't see how you could ever
have actually done what you claim to have done.

Infrequently used commands you can stand to hunt for in menus. When
you find you use one frequently, you can try to learn the keyboard
shortcut -- and you can find it without even consulting the help,
simply by finding the command's menu item.

This is no different from emacs. There's a menu bar; it displays
commands and shortcuts next to them; one can learn to use them instead,
at one's own pace.

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.

You've actually hit on another advantage of emacs: consider emacs itself
as an operating system hosting multiple applications, in which the vast
majority of commands are the same. I can use the same text-editing
commands for reading & writing emails, reading & writing Usenet posts,
reading & writing code, browsing the web, organising my schedule and so
forth.

The vast majority of what we do on a computer is reading & writing
text--wouldn't it be cool to have a full-fledged text editing
environment always available for that sort of thing? Wouldn't it be
cool not to have one program implement search in one way, and another a
second way, and yet another a third? Wouldn't it be cool to have access
to a proper text editor when editing text on a web page?

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.

That's how I learnt emacs. I was 13, and had only ever used Mac
software up until that point. I had a fairly limited command set
(basically, C-x C-f, C-x C-s & C-x C-c).

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.

Do you realise that emacs has a GUI these days? I'm writing this in a
70-line window, with gtk+ widgets. Which means full-resolution,
full-colour.

 

[Robert Uhl]

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

Tramp can be used to access files on other hosts. It even supports
multi-hop stuff like 'ssh to $HOST and su to root.'

One thing GNU emacs needs to support is the ability to open a new X or
terminal window via a command. I think Xemacs can already do this.

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.

M-x shell, or M-x terminal

 

[David Kastrup]

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.

Again, you are talking nonsense out of ignorance. When you are _not_
using filename completion, any case entry on a case insensitive file
system will work (even when we are talking about a FAT/NT file system
mounted on Unix). And _when_ you are using filename completion, on
_those_ systems where case insensitive file names are standard
(DOS/Windows/VMS/MacOSX), Emacs will notice and replace stuff with the
proper case _when completing_ (in all other cases, there is no problem
in mixing up case in the context of case insensitive file systems).

If you want a different standard than that of your operating system,
customize the variable `read-file-name-completion-ignore-case'.

It would probably be most clever if Emacs completed case-independently
only on those parts of a file name which are on a case-independent
file system (or a case independent context) so that a file name like

/[email protected]:/media/usbstick/Photos/nice.jpg
~~~~~~~~~~~ ~~~~~~~~~~~~~~~

would get case-insensitive completion just on the underlines areas.
In practice, it is actually more the users than the operating systems
which are or are not comfortable with the consequences of case
sensitivity, and so making the default depend on the default
convention of the system seems reasonable.

So please: before you continue spewing about a system you don't even
know, could you educate yourself about the state of affairs?