The Modernization of Emacs

[Bjorn Borud]

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

-Bjørn

 

[Giorgos Keramidas]

on my tombstone will say
"here lies the last Emacs user on earth. M-x rip".

Hahaha! Very good one

 

[Bjorn Borud]

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

-Bjørn

 

[Bjorn Borud]

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

-Bjørn

 

[Bjorn Borud]

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

-Bjørn

 

[Joel J. Adamson]

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

 

[Bjorn Borud]

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

-Bjørn

 

[Joost Kremers]

[Followup-To: header set to comp.emacs]

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

 

[Robert Uhl]

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

 

[Falcolas]

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?

 

[Giorgos Keramidas]

I did not know that. That will save me huge amounts of time. You're
my hero.

If you like `C-x C-f /sudo::...', then it may also please you to know
that Tramp supports other remote access methods too, i.e.:

C-x C-f /ftp:
C-x C-f /ssh:

and it lets Emacs edit files in remote locations, as long as you have a
valid set of username/password credentials for the remote host

 

[Twisted]

It has not occured to you that actually thousands of people read those
postings?

Yes, but 82 read it and downrate it within seconds of it being posted?
I find that difficult to believe. Also, I'm an optimist by nature. I
find it unlikely that 82 people would all decide to respond nastily
and in such a short span of time, all independently of one another.

I notice also that GG has apparently caught you and stopped letting
your multiple votes be counted as more than one. The same post now
shows a one-star rating by just 3 users. The others that had highly
inflated unique-user counts have also dropped to the low single
digits.

And you have really nothing worthwhile to contribute.

That isn't for you to decide. If that's your opinion, you're welcome
to it, but I'd be happy if you'd keep such opinions to yourself. You
certainly have no right to insist that it is "the truth" or that
everyone must agree with you.

your postings would certainly be good candidates for downrating.

This is your conclusion, from the premise that you hold a low opinion
of me? What school of logic did you go to? I recommend you ask them
for your money back.

Remainder of posting ignored. Attempt to make my response disappear
(get misdirected away from comp.lang.java.programmer) neutralized.
Sorry, but if I have a response to make in an unmoderated newsgroup
YOU do not get a veto, and I've seen that trick used a few times
before when someone like you wants to have the last word. You'll just
have to try harder next time -- or give up and decide to play fair.

 

[Twisted]

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

 

[Twisted]

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?

 

[Pascal Bourguignon]

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.

 

[Falcolas]

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.

 

[BartlebyScrivener]

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

 

[Twisted]

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.

 

[Twisted]

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

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

 

[Twisted]

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