do you want a emacs cookbook?
Xah Lee
elisp cookbook on the market. To turn it into a book, it probably will
take half a year at least to add content, convert html to a format
suitable for print, as well as a lot work to improve quality. If i
write a emacs book, are you likely to buy it?
* Yes, if it's good.
* No, am not likely to spend money on emacs/elisp book.
Please vote at http://xahlee.blogspot.com/2010/10/do-you-want-emacs-cookbook.html
Xah
Tony
Why not if its good.
Standish P
There is a lot of demand for good books and you do appear to be an
enthusiastic writer
Marc Mientki
> My emacs tutorial is sizable for a book. There's no emacs cookbook or
> elisp cookbook on the market. To turn it into a book, it probably will
> take half a year at least to add content, convert html to a format
> suitable for print, as well as a lot work to improve quality.
A propos quality - would you still use your camel case and parens on new
line?
regards
Marc
Xah Lee
Which way do you want them?
for some intro pages, it's better to align the parens.
for camelCase, i think it's better to use that for user defined vars.
Can't see a reason not to use them.
Xah
Jason Earl
Personally, I think that in the *perfect* book the style of the code
samples would match the GNU style guide for Emacs Lisp. However, I
would happily pay for even an "imperfect" Emacs Cookbook.
In fact, this thread has reminded me that I have been meaning to send
you a donation. So I sent one. It's not much, but it's something.
Your Emacs Tutorial has been very helpful to me, and I would love to see
something book length.
Jason
Xah Lee
hi jason, thanks for the support.
PS about donation, did you send thru the right email? should be xah@
xahlee.org
Xah
Xah Lee
just want to say thanks to Jason. I got his donation. Very generous.
Was my mistake (the net dog ate the email)
Xah
Elliot Gottleib
>
> - Show quoted text -
Xah Lee is a community conscious and helpful individual, to the lisp
and emacs community.
He deserves our support.
I prefer to send anonymous donation, ie bills in an opaque envelope.
Elena
> If i
> write a emacs book, are you likely to buy it?
>
> * Yes, if it's good.
>
> * No, am not likely to spend money on emacs/elisp book.
I voted "no" because I don't think an Emacs Cookbook is needed: there
is enough information scattered around the Internet already. What I
feel the lack of is a structured in-depth explanation of Emacs' most
complex packages: CEDET, Semantic Bovinator, ecc. which are not
explained in Emacs' manual.
A guide to setup Emacs to its best: that's something I would pay for.
Xah Lee
yeah. CEDET is a beast. But it's also for very advanced elisp coders.
Cookbooks or most programing books (e.g. O'Reilly) don't cover the
really advanced things, because there's little market for it.
CEDET's future status isn't mature though. I think few people, even
senior emacs developers, actually use or know how to make use of it. I
think there are probably less than a hundred people in the world knows
CEDET enough to write elisp package using it.
if writing a cookbook focused on emacs lisp programing, then probably
a chapter introducing CEDET is proper. It also means i'll probably
spend at least a month full time just to study CEDET. :)
O, and Elna, you are a emacs dev for many years right? haha. You
probably can write a chapter on cedet much easier and better than i
can.
Xah ∑ http://xahlee.org/ ☄
Elena
what I would like is not a cookbook. A cookbook is by definition a
set of (quick) recipes, mostly independent one from another. That's a
weakness of Emacs already: there is a lot of code around the Internet
and what most Emacs users have is a "thrown-together" environment
instead of a structured one.
What I think is sorely needed is not a guide to Emacs Lisp, but a
guide to Emacs itself which shows you why and how Emacs is better than
other editors and how you can customize it to your liking. People
come to Emacs and think it lacks all the bells and whistles other
editors offer. Truth is Emacs can do that and more, but it takes a
lot of time to learn how to customize it.
How can I have an Emacs which behaves like other editors on my
platform (hint: your ErgoEmacs package)? How can I have a setup with
a file browser on the left like many editors do? How do I manage
projects? How do I build an IDE on top of Emacs? And so on.
silver light
>
> - Show quoted text -
A Gentle introduction to Cedet
http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html
What is Cedet?
The Cedet package is a collection of several libraries, implementing
different commands, but used for one task — provide functionality for
work with source code written in different programming languages:
Semantic is base for construction of syntactic analyzers for different
programming languages. This allows to provide common representation
for information extracted from code, written in different languages.
Using this information, Cedet & other packages (JDEE and ECB), can
implement commands, required for modern development environment
(something like Eclipse, NetBeans, etc.);
SemanticDB is included into Semantic, and implements interfaces to
different storage modules, that keeps information, needed for names
completion, source code navigation, and so on. Syntactic information
could be saved between Emacs sessions, so it reduce need for re-
parsing of not modified source code.;
Senator implements navigation in source code file, using information,
extracted by Semantic;
Srecode — package for source code generation, using syntactic
information, including information, obtained from Semantic;
EDE implements set of extensions to work with projects — user can
control list of the targets to build, perform build of project, etc.
Besides this, using notion of the project, you can have more precise
control about Semantic's operations — name completions, and so on;
Speedbar is used to display information about current buffer using
different sources of information — Semantic, some specialized
information providers (for texinfo & html, for example), etc.
Eieio is a library, implementating CLOS-like (Common Lisp Object
System) infrastructure for Emacs Lisp;
Cogre is a library for drawing of UML-like diagrams in Emacs buffer,
with basic integration with Semantic.
who is familiar with Cogre and its basic principles ?
Jason Earl
Instead of a setup guide what Emacs really needs is for more of the
bells and whistles to be available an turned on by default. For
example, in the bzr version of Emacs cedet comes pre-installed, and
turning it on is as easy as checking a few checkboxes in a menu. Next
thing I knew cedet (or something) was happily parsing the headers on a C
project I was working on, and providing completion help, and other nifty
features.
Now, I am sure that there is far more that I *could* be doing with
cedet, but it appears that the real obstacle was getting it installed
and configured properly, and in future versions of Emacs that work is
going to be done for the user already. Granted, it should still be
possible for the user to customize how this machinery works, we are
talking about Emacs after all. But more of Emacs' power needs to be
installed and turned on by default.
With the new packaging system, and the addition of CEDET to the core of
Emacs I think that the Emacs devs are making good strides in these
areas. I just wish that I could take advantage of the power of Emacs to
build my own applications without trawling through the entirety of the
Emacs Lisp codebase looking for clues. The /Emacs Lisp Intro/ covers
the basics of elisp, and between the /Emacs Lisp Reference Manual/ and
the built-in documentation strings on the various functions there is a
wealth of knowledge on the specifics of how to use the various
functions.
My problem is usually that I have no idea where to begin looking for the
function I need. Once I find the function, I have no idea how a lisper
(or whatever you call people that use lisp) would go about using the
functions to create a solution.
I have been a happy Emacs *user* for years, and I would like to make the
leap to becoming an Emacs developer. So far Xah's tutorials have been
the most useful single source of information in this quest. I would
*absolutely* buy a book from him if he expanded his tutorial into
something even more substantial.
Of course, if anyone could point me to another good source of
information in the meantime, I would not turn that down either :).
Jason
Elena
> Instead of a setup guide what Emacs really needs is for more of the
> bells and whistles to be available an turned on by default.
> But more of Emacs' power needs to be
> installed and turned on by default.
Exactly. It occurred to me that other editors and environments are
shipped as full-featured structured working tools, albeit you are
allowed little modifications (compared to Emacs).
OTOH, Emacs ships as a bunch of (loosely) coupled pieces, and you are
on your own in building structure. So, the difficulty in using Emacs
comes from having to design your environment for maximum usability on
your own, when very likely you are everything but a skilled usability
designer. I think that's the main reason the learning curve of Emacs
is steep. As a systems programmer, ask me to design a software library
for maximum easiness and flexibility and - subject to my current
knowledge of methodologies - I'll find my way. But if you ask me to
design a software for usability by an end (power) user, then I'm
lost: I'm not an usability designer.
Xah has pointed out many shortcomings in the design of Emacs. That
does not mean Emacs' designers hasn't tried their best - I'm sure they
did - but they simply did not know how to accomplish that.
Sometimes newbies are reproached for asking Emacs to be like other
editors. Now I've realized they are not criticizing Emacs per se,
they are looking for an editor which does not ask them to be usability
designers besides their own expertise.
Alan Mackenzie
In comp.emacs Elena <egar...@gmail.com> wrote:
> On Nov 4, 10:51?pm, Jason Earl <je...@notengoamigos.org> wrote:
>> Instead of a setup guide what Emacs really needs is for more of the
>> bells and whistles to be available an turned on by default.
>> [snip]
>> But more of Emacs' power needs to be
>> installed and turned on by default.
> Exactly. It occurred to me that other editors and environments are
> shipped as full-featured structured working tools, albeit you are
> allowed little modifications (compared to Emacs).
There's the rub. These other editors may well be "full-featured", but
they're the wrong features for nearly everybody - they force people into
a particular way of working rather than adapting to individual needs and
wants.
> OTOH, Emacs ships as a bunch of (loosely) coupled pieces, and you are
> on your own in building structure. So, the difficulty in using Emacs
> comes from having to design your environment for maximum usability on
> your own, when very likely you are everything but a skilled usability
> designer. I think that's the main reason the learning curve of Emacs
> is steep.
Reaching an optimal setup is regarded as a feature, not a bug. The
difficulty in getting that configuration is the flip side of this.
> As a systems programmer, ask me to design a software library for
> maximum easiness and flexibility and - subject to my current knowledge
> of methodologies - I'll find my way. But if you ask me to design a
> software for usability by an end (power) user, then I'm lost: I'm not
> an usability designer.
> Xah has pointed out many shortcomings in the design of Emacs.
Most of the things he's pointed out aren't actually shortcomings.
They're deliberate design choices over several decades of evolution.
Since everybody's needs are different, Emacs is customisable. Xah's
needs are at considerable variance from vanilla Emacs, hence his
customisation is somewhat fundamental.
> That does not mean Emacs' designers hasn't tried their best - I'm sure
> they did - but they simply did not know how to accomplish that.
There is no such thing as a unified best interface for a power user.
We're all different.
> Sometimes newbies are reproached for asking Emacs to be like other
> editors. Now I've realized they are not criticizing Emacs per se,
> they are looking for an editor which does not ask them to be usability
> designers besides their own expertise.
The default configuration of Emacs is really pretty good. There are
other editors around for those whom it doesn't suit at all.
--
Alan Mackenzie (Nuremberg, Germany).
Elena
> There's the rub. These other editors may well be "full-featured", but
> they're the wrong features for nearly everybody - they force people into
> a particular way of working rather than adapting to individual needs and
> wants.
Right. However, they strive to provide a well-designed higher-level
start point, which is a better approach. Afterwards they fail at
allowing users for massive customizability, though.
> Reaching an optimal setup is regarded as a feature, not a bug. The
> difficulty in getting that configuration is the flip side of this.
What configuration? Since you are not an expert at usability issues,
you will not know. It will just be a time consuming journey. And
you'll discover endless times the warm water (as we say in Italy).
> Most of the things he's pointed out aren't actually shortcomings.
> They're deliberate design choices over several decades of evolution.
> Since everybody's needs are different, Emacs is customisable. Xah's
> needs are at considerable variance from vanilla Emacs, hence his
> customisation is somewhat fundamental.
Then they would be deliberate user-hostile choices. I don't think
so. To me, they are the consequence of geeks trying to design an
usable system. An editor which does not handle the Ctrl+ZXCV chords
when *every* other application does is not designed properly if we are
talking about usability.
> There is no such thing as a unified best interface for a power user.
> We're all different.
Less than you would think. What about different interfaces which
would provide a start point for customization?
> The default configuration of Emacs is really pretty good.
Nope. I've talked already about the ZXCV issue, for instance.
> There are
> other editors around for those whom it doesn't suit at all.
Other editors suck at customizability. Emacs sucks too, however you
are allowed to overcome its suckiness.
Alan Mackenzie
In comp.emacs Elena <egar...@gmail.com> wrote:
> On Nov 6, 3:19?pm, Alan Mackenzie <a...@muc.de> wrote:
>> There's the rub. ?These other editors may well be "full-featured", but
>> they're the wrong features for nearly everybody - they force people
>> into a particular way of working rather than adapting to individual
>> needs and wants.
> Right. However, they strive to provide a well-designed higher-level
> start point, which is a better approach. Afterwards they fail at
> allowing users for massive customizability, though.
Emacs strives to provide a W-D H-L S-P too. It largely succeeds.
>> Reaching an optimal setup is regarded as a feature, not a bug. ?The
>> difficulty in getting that configuration is the flip side of this.
> What configuration?
Sorry, that was unclear. I meant the optimal configuration for the
individual hacker.
> Since you are not an expert at usability issues, you will not know. It
> will just be a time consuming journey. And you'll discover endless
> times the warm water (as we say in Italy).
>> Most of the things he's pointed out aren't actually shortcomings.
>> They're deliberate design choices over several decades of evolution.
>> Since everybody's needs are different, Emacs is customisable. ?Xah's
>> needs are at considerable variance from vanilla Emacs, hence his
>> customisation is somewhat fundamental.
> Then they would be deliberate user-hostile choices.
Absolutely not! Emacs is an exceptionally user-friendly program. It's
also exceptionally difficult to learn. Those two aspects shouldn't be
confused. Most other programs are easier to learn but more difficult to
use.
> I don't think so. To me, they are the consequence of geeks trying to
> design an usable system. An editor which does not handle the Ctrl+ZXCV
> chords when *every* other application does is not designed properly if
> we are talking about usability.
That's an opinion on what "usability" means. There are other opinions.
What is good ergonomic design for a basic editor isn't going to be good
for an editor as sophisticated as Emacs. Ctrl+zxcv were designed for
basic editors and ease of learning.
>> There is no such thing as a unified best interface for a power user.
>> We're all different.
> Less than you would think. What about different interfaces which would
> provide a start point for customization?
Sounds like a good idea to me. Why are there so few such interfaces?
Why is Emacs almost alone in offering fully configurable and extensible
editing?
>> The default configuration of Emacs is really pretty good.
> Nope. I've talked already about the ZXCV issue, for instance.
If that's your definition of good, then Emacs's default config is bad for
you. What more can one say? I think ergo-Emacs binds C-zxcv the way you
prefer, so that might be a good starting point for your configuration.
>> ?There are other editors around for those whom it doesn't suit at all.
> Other editors suck at customizability. Emacs sucks too, however you
> are allowed to overcome its suckiness.
Oh, the world is full of vacuum cleaners. ;-) Are there any programs,
sophisticated ones, that don't suck?
Mark Wooding
> An editor which does not handle the Ctrl+ZXCV chords when *every*
> other application does is not designed properly if we are talking
> about usability.
You forget: Emacs was designed /long/ before the C-z/x/c/v convention
was dreamt up. Emacs has its own conventions, and has built on them
extensively. The keystroke C-c C-c is conventionally bound to a
generically `useful' major-mode-specific command (e.g., format a TeX
file, or do magic in Org-mode); this makes no ergonomic sense if C-c
isn't the mode-specific prefix.
If you like the CUA key bindings, by all means turn on `cua-mode' in
your configuration. But turning it on by default is a mistake for two
reasons:
* Firstly, CUA isn't a completely universal convention. It makes
little sense to switch one alien key-binding convention (Emacs) for
another (CUA). But it is also absurd that Emacs should have
different default settings on different platforms: one of Emacs's
benefits is its ubiquity: I can find Emacs on pretty much any system
and know how to drive it. (Indeed, I can fire up Emacs on ITS, and
know how to use it.)
* Secondly, it's the wrong tradeoff. CUA mode, like Viper (and the
other vi emulations) is a set of stabilizer wheels. Eventually,
it's time to take them off and face Emacs in all its glory. Each
user only needs to do this once -- if at all. But it /frequently/
happens that an experienced user wants to run an Emacs on an
unfamiliar system. Under those circumstances, it should Just
Work -- like an Emacs. Having to M-x traditional-key-mode or
something would be an annoyance in what ought to be a completely
serene process.
> On Nov 6, 3:19 pm, Alan Mackenzie <a...@muc.de> wrote:
> > The default configuration of Emacs is really pretty good.
>
> Nope. I've talked already about the ZXCV issue, for instance.
The default configuration is pretty much fine. If new users expect that
Emacs will give them instant gratification, I think they'll be
disappointed. Sorry. Emacs is a tool that rewards dedication: it will
give you many years of excellent service, but you must first invest your
time into learning how /it/ expects the world to be.
-- [mdw]
Pascal J. Bourguignon
> Elena <egar...@gmail.com> writes:
>
>> An editor which does not handle the Ctrl+ZXCV chords when *every*
>> other application does is not designed properly if we are talking
>> about usability.
>
> You forget: Emacs was designed /long/ before the C-z/x/c/v convention
> was dreamt up.
Moreover, the convention is NOT C-z C-x C-c C-v, but Command-z
Command-x Command-c Command-v, as you can check on any Macintosh, and
from which Microsoft copied.
emacs is totally justified in keeping its Control- bindings
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Tim X
> On Nov 6, 3:19 pm, Alan Mackenzie <a...@muc.de> wrote:
>
> Then they would be deliberate user-hostile choices. I don't think
> so. To me, they are the consequence of geeks trying to design an
> usable system. An editor which does not handle the Ctrl+ZXCV chords
> when *every* other application does is not designed properly if we are
> talking about usability.
>
I find this repeated criticism a little weak. Ignoring the fact that
emacs has this support and all you have to do is click a menu item to
get it, it completely overlooks the fact that the emacs keys for copty,
paste, cut etc pre-date the now common standard seen in many (and not
all BTW) applications. Some will argue that emacs support for CUA is
broken because either it destroys other useful key bindings or that it
should be made the default. I don't think there is a solution to the
first issue. Emacs has more shortcut keys than any other application
I've ever used and as a consequence, making substantial changes will
result in either loss of some bindings or the need to remap a lot of
bindings. At least the user has a choice. The second issue ignores the
fact there are a lot of emacs users out there - probably more than the
number o new users who cannot get accustomed to the established key
bindings, who would be frustrated by such a dramatic change in the
default.
This sort of argument often seems to stem from a misguided attempt to
make emacs more popular. As we all know, trying to be popular is seldom
successful and when it is, it is frequently short lived.
So, lets consider the current situation. Emacs has support for CUA mode,
available by simply clicking an option in the options menu. It also has
the ability for the user to remap any of the key bindings they want and
it has modes to support emulation of other editors, such as brief/crisp,
vi etc.
As Alan points out, when you have such a wealth of choice, identifying
the correct combination for everyone is going to be nearly impossible.
>> There is no such thing as a unified best interface for a power user.
>> We're all different.
>
> Less than you would think. What about different interfaces which
> would provide a start point for customization?
What about it? There are already people doing this. The real issue is
with all the critics who fail to actually do anything about the problems
they perceive. this is something where Xah needs to be given some
credit. While I may not agree with all his arguments and suspect that
much of the time, his arguments and tutorials would benefit from more
depth of knowledge rather than breadth, he at least has a go.
>
>> The default configuration of Emacs is really pretty good.
>
> Nope. I've talked already about the ZXCV issue, for instance.
I don't see this as an issue. There are at least two different and
easily obtainable solutions here. One comes with emacs and others are
provided by individuals not directly involved in the development of core
emacs.
The real issue is lazy expectations from users who decide to try out
emacs because they have heard it has lots of really useful advanced
power, particularly for programmers, who are then shocked to find it
isn't the same as notepad or other editors they have used. As Alan
points out, the power comes with a cost. If you jumped into a formula 1
car, are you going to give up because it has no traction on corners if
you are not traveling fast enough to generate sufficient down draft or
that changing gears is much harder than in your family saloon, or the
fuel consumption is high or there is no place to put your golf clubs?
>
>> There are
>> other editors around for those whom it doesn't suit at all.
>
> Other editors suck at customizability. Emacs sucks too, however you
> are allowed to overcome its suckiness.
Saying it 'sucks' is misleading. It doesn't suck, it is just different
to what some users are use to. Yes, it does have terminology that seems
outdated and confusing, but you need to consider this in historical
context. Many of the features it has were first introduced by emacs. New
terminology needed to be developed for these features. However, defining
new names and terminology is a difficult task. All of us have code we
wrote in the past and when we look at it again, we wonder why we chose
particular names for variables, functions, procedures etc when far more
obvious ones would have been better. However, at the time, these
alternatives were not obvious. Language and terminology also changes
over time. For example, key bindings instead of shortcut, window and
frame, 'electric', etc.
Some argue that what is needed is for an update of all these names and
terms to something more 'modern' and familiar and a re-write of the
manual. There are numerous issues this raise which nobody seems to have
a good answer to. Firstly, I think most under estimate the amount of
work this would require. Not only would you need to change the manuals,
but also the names of commands, variables and many other code artifacts.
Just changing the documentation is not enough because using one set of
terms in the documents and another in the program would just cause
confusion. Imagine reading all about windows and 'panes' and then having
to realize that to create windows and 'panes', you deal with variables
and functions with frames and windows etc, A huge job where the effort
probably exceeds the benefits. Then you still have the problem that things
are not static. These terms and their common definitions are likely to
continue to evolve and after another decade or two, we will be back in
the same position. Another problem is that it would frustrate and
likely confuse the existing user base, who are more likely to be long
term users and supporters/maintainers than many of the new users who are
simply trying it out to see what it is all about, many of which are
unlikely to be willing or interested enough to learn and understand what
makes it different. Such users will be just as happy with a different
editor.
Of course, this doesn't mean there isn't a place for other descriptions
or even alternative manuals or possibly a cookbook. All of these things
can have a use and may be beneficial to some users. This is one of the
benefits of an open source system. Anyone who has the interest and drive
can try and address whatever weaknesses they perceive.
I'm not convinced with the argument that you need to be a usability
specialist in order to configure emacs. This argument has merit if your
talking about a default configuration suitable for the majority of
users. However, it is less convincing when considering things from the
individual perspective. It is unlikely any usability expert will
understand my requirements or preferences as well as I do. While it may
be possible that such an expert may recognize a weakness in something
I'm trying to do and would avoid the effort, it is also possible I might
actually do something that works really well for me (and possibly
others) that such an expert would not have tried. Really original ideas
often come from people who were not experts and therefore were not
constrained by conventional ideas or thinking.
The real power in emacs is in the ability to create whatever environment
you want. Yes, sometimes it will seem that things which *you* see as
been obvious defaults appear to be more difficult to achieve than they
should be, but this is often more about unfamiliarity with a new system
rather than it being difficult. Once you understand the system, most
things are actually quite easy to achieve. Often, people go through all
sorts of hoops to do something only to find there was a much easier
solution they were not aware of. This is all part of getting to know
your environment and understand the problems you want to solve. A lot of
the time, the real issue is a mismatch between an individuals
expectations and reality and that part of human nature that tends to
favor the familiar over what is unfamiliar. I think CUA style key
bindings is an example of this. My use of editors pre-dates this now
common standard. I still prefer emacs key bindings and will choose that
option in any application that supports it. For me, these key bindings
had completely different meanings, but over time, I've become familiar
and know when they are relevant or not.
In general, the more powerful a tool is, the greater the effort to learn
how to use it and the less familiar it will likely appear initially. In
some situations, this additional power is worthwhile and I'm prepared to
put in the effort. In other situations, my requirements do not justify
this extra power and the learning curve is difficult to justify. In this
situation, I will likely use a less powerful system. As I spend most of
my time in an editor and as most of what I do is relevant to the
features provided by emacs, the effort was worthwhile. On the other
hand, I am completely lost when running something like 'the gimp', but
doing stuff with images is a very rare task for me and when I do need to
do something like this, other more basic tools get the job done, despite
the fact they are not as powerful or feature rich.
I'm undecided about an emacs cookbook. I personally find such books of
only limited benefit. For example, I found the perl cookbook of some
benefit initially, but only for a very short time. Despite doing quite a
lot of perl over the years, I can't even tell you where my copy of that
book is now. Possibly a useful book would be something a bit like a
cookbook, but which described and gave examples of using many of the
standard libraries/features that come with core emacs. Even after many
years of using emacs daily, I still find packages or features frequently
enough that a good summary of all the features and their use could be
useful. Probably the most important initial point for such a book would
be clearly defining the targeted audience. Like emacs itself, trying to
meet the needs of all emacs users will fail. It needs to either target
beginners (though I think there are other books that do this quite well,
such as the two O'Reilly books or the Introduction to Emacs Lisp.
Advanced users are probably happy with just the available source code,
so maybe aiming at the intermediate user - one familiar with the basic
concepts and terms, but possibly less familiar with some of the more
advanced features, libraries etc.
Tim
--
tcross (at) rapttech dot com dot au
Jean-Baptiste Bourgoin
Elena
> > Right. However, they strive to provide a well-designed higher-level
> > start point, which is a better approach. Afterwards they fail at
> > allowing users for massive customizability, though.
>
> Emacs strives to provide a W-D H-L S-P too. It largely succeeds.
Nope. Emacs' start point is not higher level. For instance, vanilla
Emacs lacks a file browser, unlike any other code editor does. Emacs
is well designed, but not when it comes to usability. Let me tell you
that not meeting new users' expectations is bad design, no matter how
much you can try to justify it.
> Absolutely not! Emacs is an exceptionally user-friendly program. It's
> also exceptionally difficult to learn. Those two aspects shouldn't be
> confused. Most other programs are easier to learn but more difficult to
> use.
I agree that Emacs is an exceptionally user-friendly program. Instead
of saying it's exceptionally difficult to learn, I'd rather say it's
*uselessly* difficult to learn.
> That's an opinion on what "usability" means. There are other opinions.
> What is good ergonomic design for a basic editor isn't going to be good
> for an editor as sophisticated as Emacs. Ctrl+zxcv were designed for
> basic editors and ease of learning.
Again, not meeting users' basic expectations is bad design. That's
not an opinion. Ask any usability designer.
Elena
> You forget: Emacs was designed /long/ before the C-z/x/c/v convention
> was dreamt up. Emacs has its own conventions, and has built on them
> extensively. The keystroke C-c C-c is conventionally bound to a
> generically `useful' major-mode-specific command (e.g., format a TeX
> file, or do magic in Org-mode); this makes no ergonomic sense if C-c
> isn't the mode-specific prefix.
I know Emacs has longer history than many OSes which are laying around
nowadays.
> * Firstly, CUA isn't a completely universal convention. It makes
> little sense to switch one alien key-binding convention (Emacs) for
> another (CUA).
I was not saying you should turn CUA on on every platform. You should
turn it on on platforms which embrace it.
> But it is also absurd that Emacs should have
> different default settings on different platforms: one of Emacs's
> benefits is its ubiquity: I can find Emacs on pretty much any system
> and know how to drive it. (Indeed, I can fire up Emacs on ITS, and
> know how to use it.)
Not an absurd idea at all, I think. When in Rome, do as Romans do:
it's an old wise proverb. I think Emacs favors advanced users at the
expense of beginners for no reason. Why the heck can't we have our
cake and eat it too? For instance, a variable with a corresponding
command-line flag could be devised which would disable beginner-
friendly features. So, instead of typing "emacs" you would just have
to type "emacs -x" and you are in your world everywhere.
>
> * Secondly, it's the wrong tradeoff. CUA mode, like Viper (and the
> other vi emulations) is a set of stabilizer wheels. Eventually,
> it's time to take them off and face Emacs in all its glory. Each
> user only needs to do this once -- if at all. But it /frequently/
> happens that an experienced user wants to run an Emacs on an
> unfamiliar system. Under those circumstances, it should Just
> Work -- like an Emacs. Having to M-x traditional-key-mode or
> something would be an annoyance in what ought to be a completely
> serene process.
Nope. As soon as you leave Emacs - because you have to more than once
a while since there are other programs you have to use - then you have
to switch key bindings. This is just wasting your brain. Why the
heck should I know a different keybinding to achieve basic operations
for each program I use? That's why, among other systems, CUA has been
devised.
> The default configuration is pretty much fine. If new users expect that
> Emacs will give them instant gratification, I think they'll be
> disappointed.
Stated in another way: if you expect Emacs to be designed with
usability issues in mind, you'll meet disappointment.
However, guys, I think discussing these points is useless. You can't
teach an old dog new tricks, they say. And you can't teach old Emacs
users new ways, either. They will always think older ways are better,
and having paid their dues already, they have little incentive to
change things. We will wait for a generation shift in Emacs'
maintainers. XEmacs pushed GNU Emacs forth, but a fork it's too high
a price to pay, I think. XEmacs had a package system, as GNU Emacs is
going to... after how many years?
Pascal J. Bourguignon
> On Nov 6, 10:08 pm, Alan Mackenzie <a...@muc.de> wrote:
>> > Right. However, they strive to provide a well-designed higher-level
>> > start point, which is a better approach. Afterwards they fail at
>> > allowing users for massive customizability, though.
>>
>> Emacs strives to provide a W-D H-L S-P too. It largely succeeds.
>
> Nope. Emacs' start point is not higher level. For instance, vanilla
> Emacs lacks a file browser, unlike any other code editor does.
But this is plain wrong! Vanilla emacs has a perfectly good file browser.
Try it: C-x C-f TAB
> Emacs is well designed, but not when it comes to usability. Let me
> tell you that not meeting new users' expectations is bad design, no
> matter how much you can try to justify it.
Again, you're plain wrong!
Emacs is very usable, the most usable of all.
What it is not, is displaying splashy icons, and having you mousing
around all the time.
>> Absolutely not! Emacs is an exceptionally user-friendly program. It's
>> also exceptionally difficult to learn. Those two aspects shouldn't be
>> confused. Most other programs are easier to learn but more difficult to
>> use.
>
> I agree that Emacs is an exceptionally user-friendly program. Instead
> of saying it's exceptionally difficult to learn, I'd rather say it's
> *uselessly* difficult to learn.
And really, emacs is not difficult at all to learn. Compared to vi. If
you go thru the GUI editors.
vi < GUI editors < emacs
Which, by the way is exactly the progression I went thru, since
TextEdit.app (in NeXTstep, then, but now on MacOSX), implements the
standard control keys of emacs. So after vi, I had a little time of
adaptation with TextEdit, and when I realized that I was passing most of
my editing time writting little filters (which could be invoked in
TextEdit as easily as in vi) to ease my work, I finally switched to
emacs, without any difficulty.
The main thing to understand with emacs, is that it is modeless. The
normal characters you type at the keyboard are always inserted into the
buffer, like in any other GUI editor. You have to use modifier keys to
give commands, like in any other GUI editor (Command- something on
Mac). You also have menus, scroll bars, tooltips, buttons, etc, just
like in any other GUI editor.
>> That's an opinion on what "usability" means. There are other opinions.
>> What is good ergonomic design for a basic editor isn't going to be good
>> for an editor as sophisticated as Emacs. Ctrl+zxcv were designed for
>> basic editors and ease of learning.
>
> Again, not meeting users' basic expectations is bad design. That's
> not an opinion. Ask any usability designer.
Well, while emacs has encountered great success with normal users, such
as secretaries (they even have been taught to "configure it" (actually
they learned to program emacs lisp, but nobody told them they were
programming, so they could learn to "configure it" without blocking
themselves)), I would consider that it is more a programmer tool than a
user tool. If you're not editing 8 hours a day, you should probably
better use a GUI editor, or even a word processor.
But a programmer, or a secretary, or anybody typing all day long will
benefit clearly from emacs from day one.
Pascal J. Bourguignon
>> * Firstly, CUA isn't a completely universal convention. It makes
>> little sense to switch one alien key-binding convention (Emacs) for
>> another (CUA).
>
> I was not saying you should turn CUA on on every platform. You should
> turn it on on platforms which embrace it.
That's a point of view. Since I don't use only those platforms, I
prefer to keep an homogeneous UI on all the platforms I use, so I put
emacs and X11 on all the platforms I use, and I configure as much as I
want the platforms to adapt to myself, instead of losing time adapting
to the platforms. Which would be time lost anyways, since platforms
change every few years, or evolve with the fashion too fast to be doing
anything else than following them.
Now, I can tell you what platform is really user friendly: it's the
platform that can adapt itself the most easily to my work patterns and
my idiosyncrasies. I can guarantee you that's not platforms where you
find CUA preconfigured...
> I think Emacs favors advanced users at the expense of beginners for no
> reason.
You have no scientific data about this fact. Please to the HMI
experiments required and gather some fact, or stop talking.
> Why the heck can't we have our
> cake and eat it too? For instance, a variable with a corresponding
> command-line flag could be devised which would disable beginner-
> friendly features. So, instead of typing "emacs" you would just have
> to type "emacs -x" and you are in your world everywhere.
There are less beginners than proficient users, and they stay beginners
for less time than being proficient. Therefore you obviously want to
make the proficient user the default, and add rather a beginner option.
1- CUA-mode exists for emacs.
2- You can wrap emacs in a script for beginners that would activate it.
3- You can do that only in emacs (and a few other imitators), so emacs
is again the obvious choice of an editor.
> Nope. As soon as you leave Emacs - because you have to more than once
> a while since there are other programs you have to use - then you have
> to switch key bindings.
Read again my first two paragraphs. About the only other program I have
to use (because of lack of javascript in w3m), is firefox. You never
leave emacs! Heresy! And of course, there's a configuration of firefox
giving you emacs key bindings. Which is not the case of Safari or IE
(AFAIK).
> This is just wasting your brain. Why the heck should I know a
> different keybinding to achieve basic operations for each program I
> use?
This is exactly what we are wondering! Why would you want us to know
different key bindings than those of emacs? Why do you think we use
emacs to read email, news, chat on irc or jabber, browse the interesting
parts of the web, listen music, compute spreadsheets, manage databases,
organize workflows and files, whatever you may do with a computer?
> That's why, among other systems, CUA has been devised.
No. CUA has not been devised for that. I'll tell you what CUA has been
devised for. CUA has been devised so that it be so simple as to appeal
to people not knowing the first thing about computers, and to entice
then to fork $12,000 on a Lisa (CUA wasn't enough for that), or $5,000
on a Macintosh (CUA seems to have been successfully at that). (I know,
I did).
Now, if CUA means a lifetime of pain and suffering, nobody cares, Jobs
and his shareholders are on holidays in the Caraibes!
(In the meantime, I recovered early, when I got my MacII, I installed
A/UX, started to use vi, and then switched to TextEdit and emacs with
NeXT.)
>> The default configuration is pretty much fine. If new users expect that
>> Emacs will give them instant gratification, I think they'll be
>> disappointed.
>
> Stated in another way: if you expect Emacs to be designed with
> usability issues in mind, you'll meet disappointment.
I had a friend who was a fencer. The standard foil handle is
rectilinear, and quite unusable. There are for advanced fencers,
"ergonomic" handles, that purposedly are more adapted to the hands. Of
course, there's one model for all, the company selling them having the
good business sense of caring its R.O.I. is quite successful. But then,
instead of buying such handles, my friend made his own with some resin,
to match his own hand.
So there you have, the old square computers that could not adapt to
people, because they didn't have the resources (and anyways, people
didn't approach them, only IT priests). Then you have "designer"
computers, made to appeal to the unwashed masses, basically, the
Macintosh, and it's copier Microsoft Windows. Finally, you have the
advanced and demanding users, who want the computer to really adapt to
their own hand, and who use emacs.
** EMACS, THE COMPUTER SYSTEM FOR THE DISCRIMINATING AND DEMANDING MAN **
> However, guys, I think discussing these points is useless. You can't
> teach an old dog new tricks, they say. And you can't teach old Emacs
> users new ways, either.
We also have a hard time making you learn something, it seems...
> They will always think older ways are better, and having paid their
> dues already, they have little incentive to change things. We will
> wait for a generation shift in Emacs' maintainers. XEmacs pushed GNU
> Emacs forth, but a fork it's too high a price to pay, I think. XEmacs
> had a package system, as GNU Emacs is going to... after how many
> years?
Yes, that is another question. Instead of losing time talking about
CUA, perhaps you could spend it in writing an emacs lisp VM in CL so
that we could use the old emacs lisp code on a new implementation of
emacs in Common Lisp (such as climacs).
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
Thad Floryan
> [...]
> Well, while emacs has encountered great success with normal users, such
> as secretaries (they even have been taught to "configure it" (actually
> they learned to program emacs lisp, but nobody told them they were
> programming, so they could learn to "configure it" without blocking
> themselves)), I would consider that it is more a programmer tool than a
> user tool. If you're not editing 8 hours a day, you should probably
> better use a GUI editor, or even a word processor.
>
> But a programmer, or a secretary, or anybody typing all day long will
> benefit clearly from emacs from day one.
Very true. I remember at Hewlett-Packard Labs (Palo Alto CA) back during
the late 1970s and the 1980s when they had a bunch of DECsystem 20s that
everyone was using Emacs from secretaries on up. Most people there were
reasonably proficient simply after running the builtin Emacs tutorial.
Elena
wrote:
> That's a point of view. Since I don't use only those platforms, I
> prefer to keep an homogeneous UI on all the platforms I use, so I put
> emacs and X11 on all the platforms I use, and I configure as much as I
> want the platforms to adapt to myself, instead of losing time adapting
> to the platforms. Which would be time lost anyways, since platforms
> change every few years, or evolve with the fashion too fast to be doing
> anything else than following them.
Pascal, we are power users. We don't have an hard time customizing
our platforms to our liking.
>
> > I think Emacs favors advanced users at the expense of beginners for no
> > reason.
>
> You have no scientific data about this fact. Please to the HMI
> experiments required and gather some fact, or stop talking.
Do I really need scientific data? The principle of least surprise is
a basic usability design principle.
> > Why the heck can't we have our
> > cake and eat it too? For instance, a variable with a corresponding
> > command-line flag could be devised which would disable beginner-
> > friendly features. So, instead of typing "emacs" you would just have
> > to type "emacs -x" and you are in your world everywhere.
>
> There are less beginners than proficient users, and they stay beginners
> for less time than being proficient. Therefore you obviously want to
> make the proficient user the default, and add rather a beginner option.
No. There are more beginners than proficient users. Unless we think
usability design is intuitive (I don't think so).
> 1- CUA-mode exists for emacs.
Yes, but it's disabled.
> 2- You can wrap emacs in a script for beginners that would activate it.
But that's not how Emacs is shipped. What matters to newcomers is how
a product is shipped.
> Read again my first two paragraphs. About the only other program I have
> to use (because of lack of javascript in w3m), is firefox. You never
> leave emacs! Heresy!
I'd very much use Emacs for everything too, but it's such a PITA to
configure complex packages that I gave up.
> This is exactly what we are wondering! Why would you want us to know
> different key bindings than those of emacs?
You are agreeing with me at last: users should not be forced to learn
new keybindings. Viper takes a nice route: at first startup, it asks
you what kind of users you are, and configures itself accordingly once
for all (you can change later, of course). That would be nice of
Emacs too: unless you have an .emacs file, you obviously are a
newcomer, and Emacs could behave accordingly by allowing you to setup
things.
> Yes, that is another question. Instead of losing time talking about
> CUA, perhaps you could spend it in writing an emacs lisp VM in CL so
> that we could use the old emacs lisp code on a new implementation of
> emacs in Common Lisp (such as climacs).
Such a work has already been done with MIT Scheme's Edwin editor, but
it has been forgotten. What would make me sure that my hard work will
not be forgotten as well? Who cares?
Pascal, despite its obvious shortcomings, Emacs is still my preferred
editor and piece of software. However, I do not kid myself in
thinking it's the greatest tool ever made.
P.S.: Sorry, I have to go and I don't have time to edit this post
before posting.
Pascal J. Bourguignon
> No. There are more beginners than proficient users. Unless we think
> usability design is intuitive (I don't think so).
>
>> 1- CUA-mode exists for emacs.
>
> Yes, but it's disabled.
>
>> 2- You can wrap emacs in a script for beginners that would activate it.
>
> But that's not how Emacs is shipped. What matters to newcomers is how
> a product is shipped.
>> Yes, that is another question. �Instead of losing time talking about
>> CUA, perhaps you could spend it in writing an emacs lisp VM in CL so
>> that we could use the old emacs lisp code on a new implementation of
>> emacs in Common Lisp (such as climacs).
>
> Such a work has already been done with MIT Scheme's Edwin editor, but
> it has been forgotten. What would make me sure that my hard work will
> not be forgotten as well? Who cares?
>
> Pascal, despite its obvious shortcomings, Emacs is still my preferred
> editor and piece of software. However, I do not kid myself in
> thinking it's the greatest tool ever made.
If that's really what you think, that there are enough beginners
interested who would need an emacs configured like Microsoft Office or
AppleWorks, (or BBEdit if you want, I hear it's a quite good editor),
then it is a simple matter to make an emacs distribution targetted to
this market. This is free software, and it is exceedingly
configurable. So again, just package it, pre-configure it, and
distribute it:
emacs-for-mac-users.dmg
emacs-for-ms-windows-users.exe
emacs-for-mac-users-on-linux.rpm
emacs-for-ms-windows-users-on-linux.rpm
emacs has already been packaged and pre-configured for specific
markets. For examples, beginners in lisp programming have been able to
download the LispBox, which was emacs preconfigured with slime and sbcl,
and a set of preloaded CL libraries, to start studying lisp programming
with "Practical Common Lisp" without having to configure anything.
http://www.gigamonkeys.com/lispbox/
http://common-lisp.net/project/lispbox/
You can do something similar, and if it's good, it could even be
included upstream.
Elena
wrote:
> Elena <egarr...@gmail.com> writes:
> > On Nov 6, 10:08 pm, Alan Mackenzie <a...@muc.de> wrote:
> >> > Right. However, they strive to provide a well-designed higher-level
> > Emacs lacks a file browser, unlike any other code editor does.
>
> But this is plain wrong! Vanilla emacs has a perfectly good file browser.
>
> http://imagebin.org/122149
>
> Try it: C-x C-f TAB
I apologize for not having been clearer. I was thinking about a file
tree for projects, like that one on the left here:
http://drnicwilliams.com/wp-content/uploads/2006/08/radrails-with-textmate-theme.png
Yes, I know, there is Speedbar, but last time I tried, you couldn't
get around it opening a new frame. Oh, and even if you succeeded in
achieve that, then Emacs would mess your nicely arranged windows with
its popups. Oh, and what about having different projects opened at
once?
Pascal J. Bourguignon
> On Nov 7, 10:39�am, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Elena <egarr...@gmail.com> writes:
>> > On Nov 6, 10:08�pm, Alan Mackenzie <a...@muc.de> wrote:
>> >> > Right. �However, they strive to provide a well-designed higher-level
>> > Nope. �Emacs' start point is not higher level. �For instance, vanilla
>> > Emacs lacks a file browser, unlike any other code editor does. �
>>
>> But this is plain wrong! �Vanilla emacs has a perfectly good file browser.
>>
>> http://imagebin.org/122149
>>
>> Try it: �C-x C-f TAB
>
> I apologize for not having been clearer. I was thinking about a file
> tree for projects, like that one on the left here:
>
> http://drnicwilliams.com/wp-content/uploads/2006/08/radrails-with-textmate-theme.png
>
I understood the first time. My point is that you don't need to have a
tree being displayed at all times to be able to work efficiently.
Actually, when I work on a project, I can type the paths to all the files
I want without even having to use TAB to get the list of existing files.
When you work with a graphical file manager, you have to limit the number
of children (it's advised to have between 5 and 9 icons per folder), so
that you can easily navigate with mouse clicks down the hierarchy.
Well, if you avoid the graphical file managers, you will realize that
you can very well have thousands of files per directory (eg. in your
home directory) and find the one you want by typing directly its path,
without having to search in a list.
Again, this is not something that a casual user would be able to do.
You have to be working with your files all day long, so that your brains
record their path automatically and effortlessly.
Now, if you're asking yourself what emacs can do for the casual
programmer or the casual user in general, it's clear: nothing. Today,
the casual users will use an iPad.
> Yes, I know, there is Speedbar, but last time I tried, you couldn't
> get around it opening a new frame. Oh, and even if you succeeded in
> achieve that, then Emacs would mess your nicely arranged windows with
> its popups. Oh, and what about having different projects opened at
> once?
Some may prefer it like that. Otherwise, you are free to scratch that itch.
I tried it once, and I wasn't more efficient than with C-x C-f, so I
quickly dropped it.
Mark Wooding
> For instance, vanilla Emacs lacks a file browser, unlike any other
> code editor does.
Lies. Emacs had dired (C-x d DIRECTORY RET) back when it was mainly
written in Teco and ran on ITS. Nowadays there's also the Speedbar.
> Again, not meeting users' basic expectations is bad design. That's
> not an opinion. Ask any usability designer.
Wrong. A real usability engineer (I've met them) knows the difference
between a tool for casual or occasional use and a tool that'll be used
intensively for years. The former ought to be rapidly learnable after a
minimum of orientation and reading of manuals.
Fortunately, Emacs is in the latter category. It requires a heavy
investment by a new user to become familiar with its distinctive
conventions and culture -- but it derives power from its distinctiveness
and the user's investment is repaid many times over the years.
Muddling the two gives you, on the one hand programs like Word, which
are easy for a novice to use to produce poor quality documents but
devastatingly inconvenient for an advanced user; and on the other hand
godawful corporate systems which require user training but provide users
with no lasting reward.
They used to make motor cars with reins, like you'd use when driving a
carriage pulled by horses. Fortunately, this was rapidly replaced by an
idiosyncratic control interface for motor cars which (inevitably)
requires user training but is better suited to the control of motor
vehicles.
-- [mdw]
Mark Wooding
> Nope. As soon as you leave Emacs - because you have to more than once
> a while since there are other programs you have to use - then you have
> to switch key bindings. This is just wasting your brain.
Leave Emacs? What a bizarre idea! Why should I do a thing like that?
> Stated in another way: if you expect Emacs to be designed with
> usability issues in mind, you'll meet disappointment.
Again, there is more (much, much more) to usability than how rapidly a
new user can sit down with an unfamiliar tool and use it badly.
-- [mdw]
Mark Wooding
> No. CUA has not been devised for that. I'll tell you what CUA has been
> devised for. CUA has been devised so that it be so simple as to appeal
> to people not knowing the first thing about computers, and to entice
> then to fork $12,000 on a Lisa (CUA wasn't enough for that), or $5,000
> on a Macintosh (CUA seems to have been successfully at that). (I know,
> I did).
Actually this is all a muddle. CUA is later than the Mac interface, and
Apple weren't involved in it. CUA was dreamt up by IBM, Microsoft and
(I think) DEC, to cover interfaces such as Windows, OS/2 Presentation
Manager, Motif, and various mainframe full-screen terminal interfaces.
In fact, CUA's keystrokes for cutting, copying and pasting weren't
C-z/x/c/v at all, but C-INS, C-DEL, and others I can't remember. I
think those were a later copying from Apple by Microsoft.
Other stuff, like the S-left/right text selection model, is really CUA.
-- [mdw]
Elena
wrote:
> I understood the first time. My point is that you don't need to have a
> tree being displayed at all times to be able to work efficiently.
>
> Actually, when I work on a project, I can type the paths to all the files
> I want without even having to use TAB to get the list of existing files.
Pascal, maybe we are after something now. Could it be that what is
needed more in the Emacs community is knowing *how* Emacs power users
use Emacs? It's not that we need more Emacs Lisp tutorials, it's not
that we need more .emacs files.
You have stated you use Emacs for almost everything? Would you
consider posting a video of an Emacs session of yours. It does not
need to be something specialized or carefully edited tutorial. Just
fire up Emacs and show us how you move around files, ecc.
That's roughly what I was trying to say when I stated that we need
more higher-level usage suggestions than some low-level Emacs lisp
snippets.
Elena
> Wrong. A real usability engineer (I've met them) knows the difference
> between a tool for casual or occasional use and a tool that'll be used
> intensively for years. The former ought to be rapidly learnable after a
> minimum of orientation and reading of manuals.
Oh, no, I'm having an hard time explaining what I mean. Please refer
to my last response to PJB.
Mark Wooding
> That would be nice of Emacs too: unless you have an .emacs file, you
> obviously are a newcomer, and Emacs could behave accordingly by
> allowing you to setup things.
Wrong. Lack of ~/.emacs simply means that you haven't run Emacs on this
machine yet. It frequently happens that I want to use Emacs on a
machine I've not logged into before, and (usability!) it should behave
like Emacs and let me edit files immediately rather than making me wade
through some wretched wizard thing first.
-- [mdw]
David Kastrup
> emacs is totally justified in keeping its Control- bindings
Being right does not buy you friends.
--
David Kastrup
small Pox
He is korrekt. You have to be a sycophant. and not post things like
this
*** FBI gets a warm welcome in Chicago for their EXCELLENT performance
- cheers to NEW CONS ***
http://www.youtube.com/watch?v=eq2ZvSd-z0M&feature=player_embedded&related
http://www.youtube.com/watch?v=eq2ZvSd-z0M&feature=player_embedded&related
http://www.youtube.com/watch?v=eq2ZvSd-z0M&feature=player_embedded&related
http://www.youtube.com/watch?v=eq2ZvSd-z0M&feature=player_embedded&related
http://www.youtube.com/watch?v=eq2ZvSd-z0M&feature=player_embedded&related
On Nov 2, 2:30 pm, silver light <lightsilv...@gmail.com> wrote:
> On Nov 2, 1:58 pm, Rich Grise <richgr...@example.net> wrote:
>
> > On Tue, 02 Nov 2010 14:17:29 -0700, Gunner Asch wrote:
>
> > > But...shrug..there will be far less after the Great Cull........
>
> > I think some people might be surprised as to exactly _who_ gets "culled".
>
> > Good Luck!
> > Rich
>
> On Nov 2, 11:03 am, t...@sevak.isi.edu (Thomas A. Russ) wrote:
>
> > silver light <lightsilv...@gmail.com> writes:
> > > *** FBI gets a warm welcome in Chicago for their EXCELLENT performance
> > > - cheers to NEW CONS ***
>
> > Oh geez. Just when we've beaten back the infix hordes, someone comes up
> > and suggests replacing CONS with something, new different and most
> > likely inferior.
>
> > - Grumpy Old Programmer.
>
> > --
> > Thomas A. Russ, USC/Information Sciences Institute
>
> Google censored my post and deleted it not because they are trying to
> defend the FBI or cover them up. They just dont like silverlight which
> is from Microsoft.
>
> It is well known that google and oracle are trying to get control of
> the whole cyberspace either alone or in alliance with each other.
>
> This way they can control the federal government. Most senators and
> congressmen are pea brain and go along with whatever the corporations
> show them with music, viagra, champagne, food, cruise tickets, girls
> and pocket money.
>
> ==========
> Submitted by jkeogh on Tue, 11/02/2010 - 6:44am
>
> http://911blogger.com/news/2010-10-20/foia-funds-request
>
> Litigation seeking the release of never before seen 9/11 FBI records
> is currently underway in the federal courts. There is a immediate need
> for a FOIA attorney to assist with the case. The defendants are
> operating with a nearly unlimited funding and have a large body of
> legal experts working to prevent the release of these records. A
> public interest FOIA attorney has offered their services at a reduced
> public interest rate. We need the research communities help to raise
> the required funds. Release of these requested records may help settle
> questions surrounding the Pentagon and Shanksville controversies, as
> well as others. Release of these records could also help overcome
> future claims of release exemption by the FBI for other 9/11 records
> requests.
Tim X
> On Nov 6, 10:08 pm, Alan Mackenzie <a...@muc.de> wrote:
>> > Right. However, they strive to provide a well-designed higher-level
>> > start point, which is a better approach. Afterwards they fail at
>> > allowing users for massive customizability, though.
>>
>> Emacs strives to provide a W-D H-L S-P too. It largely succeeds.
>
> Nope. Emacs' start point is not higher level. For instance, vanilla
> Emacs lacks a file browser, unlike any other code editor does. Emacs
> is well designed, but not when it comes to usability. Let me tell you
> that not meeting new users' expectations is bad design, no matter how
> much you can try to justify it.
Huh? Emacs has dired, a powerful file browser that is standard in all
vanilla emacs. Then there is also speedbar, which provides both file
browsing and more sophisticated features, such as tag browsing etc.
Furthermore, if you use the mouse to open a file, by default it will
open up a standard GUI 'find file' dialogue, allowing you to click
through directories of files to open the file you want.
>
>
>> Absolutely not! Emacs is an exceptionally user-friendly program. It's
>> also exceptionally difficult to learn. Those two aspects shouldn't be
>> confused. Most other programs are easier to learn but more difficult to
>> use.
>
> I agree that Emacs is an exceptionally user-friendly program. Instead
> of saying it's exceptionally difficult to learn, I'd rather say it's
> *uselessly* difficult to learn.
>
>> That's an opinion on what "usability" means. There are other opinions.
>> What is good ergonomic design for a basic editor isn't going to be good
>> for an editor as sophisticated as Emacs. Ctrl+zxcv were designed for
>> basic editors and ease of learning.
>
> Again, not meeting users' basic expectations is bad design. That's
> not an opinion. Ask any usability designer.
>
Define those basic expectations. So far, you have mentioned lack of
support for the common cut/copy/paste commands on the CUA
bindings, but that is available with one click in the options menu. You
mention lack of a file browser, yet emacs has two in its vanilla
configuration.
Tim X
> On Nov 6, 11:32 pm, m...@distorted.org.uk (Mark Wooding) wrote:
>> You forget: Emacs was designed /long/ before the C-z/x/c/v convention
>> was dreamt up. Emacs has its own conventions, and has built on them
>> extensively. The keystroke C-c C-c is conventionally bound to a
>> generically `useful' major-mode-specific command (e.g., format a TeX
>> file, or do magic in Org-mode); this makes no ergonomic sense if C-c
>> isn't the mode-specific prefix.
>
> I know Emacs has longer history than many OSes which are laying around
> nowadays.
>
>> * Firstly, CUA isn't a completely universal convention. It makes
>> little sense to switch one alien key-binding convention (Emacs) for
>> another (CUA).
>
> I was not saying you should turn CUA on on every platform. You should
> turn it on on platforms which embrace it.
I think there is a flaw in this suggestion. While this could be a good
idea if turning on CUA mode came at no cost, the problem is that it does
come at considerable cost. If CUA was enabled by default, many new users
would never be aware of the additional functionality that has to be lost
in order to get this level of compatibility. They would also be less
likely to pick up the overall scheme that underlies much of Emacs' key
bindings.
Having it so that it is easy to turn on for those who insist on it is a
good compromise. New users will be aware they have explicitly changed
things when they do it and other new users will likely decide to go with
the defuaults and may get the full benefit of those defaults and
exposure to an alternative which may actually be better.
>
>> But it is also absurd that Emacs should have
>> different default settings on different platforms: one of Emacs's
>> benefits is its ubiquity: I can find Emacs on pretty much any system
>> and know how to drive it. (Indeed, I can fire up Emacs on ITS, and
>> know how to use it.)
>
> Not an absurd idea at all, I think. When in Rome, do as Romans do:
> it's an old wise proverb. I think Emacs favors advanced users at the
> expense of beginners for no reason. Why the heck can't we have our
> cake and eat it too? For instance, a variable with a corresponding
> command-line flag could be devised which would disable beginner-
> friendly features. So, instead of typing "emacs" you would just have
> to type "emacs -x" and you are in your world everywhere.
>
Again, this cripples much of the power of emacs that actually represents
what makes it stand out from the crowd. If we make emacs default to
being just like all other editors, we don't expose new users to what
makes it different.
Sure, XEMacs introduced some ideas which have been adopted by emacs and
many predicted the demise of Emacs. However, now around 15 years down
the track, we see emacs powering forward and xemacs somewhat
languishing.
You could say that the issue is you can't teach old emacs users new ways
because they are invested in the status quo and don't want that effort
lost. Alternatively, you could say that those who have stuck with it
have experienced the difference and are now aware of its benefits and
don't want to see those benefits compromised for short term gain.
I don't disagree completely with a 'novice' mode. However, my suggestion
would be to reverse your proposal. Have a command line switch that sets
things up in a way that would possibly make things more familiar to a
new user and include warnings when you start emacs that using this mode
will result in resrictions/limitations to the power of emacs and
encourage the user to stop using novice mode as soon as they feel
comfortable.
Pascal J. Bourguignon
Before that, we need an essential tool for emacs videos: we need
something that displays on the screen the keychords used. Something
like scrolling subtittles, but with keys instead of words.
[ C-] [ M-]
[ e ] [ h ] [ t ] [ l ] [ l ] [ p ] [DEL] [ o ] [SPC ] [DEL] [ H ] [ i ]
or perhaps just:
eh C-t llp DEL o SPC M-DEL Hi
There are already videos demonstrating emacs or various package use in
emacs (eg. slime). For example:
http://video.google.com/videoplay?docid=-2572085463585491742#docid=-3999246037945224442
http://www.guba.com/watch/3000054867/
But we don't see the keys pressed.
Pascal J. Bourguignon
> Fortunately, Emacs is in the latter category. It requires a heavy
> investment by a new user to become familiar with its distinctive
> conventions and culture -- but it derives power from its distinctiveness
> and the user's investment is repaid many times over the years.
No, no! Emacs does not require a heavy investment by a new users. This
is a misconception!
The learning curve of emacs can be as gradual as you want. You're a
'new user' only for a short period of time. The objective cannot be to
know everything there is to know about emacs after this short period of
time, this is not possible. A life time would not be enough. It's like
the Internet, more web pages are produced every day than you can
hopefully read in a life time.
Indeed, over long periods of time, an emacs user will have invested more
in learning emacs than perhaps a user of vi or notepad. But this is not
an upfront investment, it's done a little every day while using emacs,
and its R.O.I. is everyday worth it.
For a beginner, the emacs tutorial is half an hour to learn the basics
of emacs. From this, you can edit texts like you do in any other
editor. Already, from day one they will benefit from the emacs modes to
edit various kinds of text files. That alone, for a half-an-hour
investment is an enormous R.O.I.
Then the rest will be learn along. When you need to use a new mode, you
may spend an hour to read its documentation and experiment before using
it, but since you will use it for years, it's a very little investment.
> Muddling the two gives you, on the one hand programs like Word, which
> are easy for a novice to use to produce poor quality documents but
> devastatingly inconvenient for an advanced user; and on the other hand
> godawful corporate systems which require user training but provide users
> with no lasting reward.
>
> They used to make motor cars with reins, like you'd use when driving a
> carriage pulled by horses. Fortunately, this was rapidly replaced by an
> idiosyncratic control interface for motor cars which (inevitably)
> requires user training but is better suited to the control of motor
> vehicles.
>
> -- [mdw]
--
Pascal J. Bourguignon
> Elena <egar...@gmail.com> writes:
>
>> Nope. As soon as you leave Emacs - because you have to more than once
>> a while since there are other programs you have to use - then you have
>> to switch key bindings. This is just wasting your brain.
>
> Leave Emacs? What a bizarre idea! Why should I do a thing like that?
We should rebind C-x C-c to something else! :-)
>> Stated in another way: if you expect Emacs to be designed with
>> usability issues in mind, you'll meet disappointment.
>
> Again, there is more (much, much more) to usability than how rapidly a
> new user can sit down with an unfamiliar tool and use it badly.
>
> -- [mdw]
--
Pascal J. Bourguignon
Ah, sorry, I thought CUA was Macintosh standard Command keys. Indeed,
IBM Common User Access keys are even worse. Why would anybody consider
them?
Cut = S-DEL
Copy = C-Ins
Paste = S-Ins
Hello? Anybody home?
Pascal J. Bourguignon
> p...@informatimago.com (Pascal J. Bourguignon) writes:
>
>> emacs is totally justified in keeping its Control- bindings
>
> Being right does not buy you friends.
No, it buys you Paradize.
Pascal J. Bourguignon
> I don't disagree completely with a 'novice' mode. However, my suggestion
> would be to reverse your proposal. Have a command line switch that sets
> things up in a way that would possibly make things more familiar to a
> new user and include warnings when you start emacs that using this mode
> will result in resrictions/limitations to the power of emacs and
> encourage the user to stop using novice mode as soon as they feel
> comfortable.
A good novice mode would be some system that would detect what the user
is doing and giving him advice on alternative more efficients ways to
archive it. When you watch over the shoulder of a newbie, you can tell
him: "Hey, don't do this like that, there's this command or this key
that will let you do it easier.".
Bob Felts
> David Kastrup <d...@gnu.org> writes:
>
> > p...@informatimago.com (Pascal J. Bourguignon) writes:
> >
> >> emacs is totally justified in keeping its Control- bindings
> >
> > Being right does not buy you friends.
>
> No, it buys you Paradize.
Paradise isn't for sale.
Pascal J. Bourguignon
Elena
> I think there is a flaw in this suggestion. While this could be a good
> idea if turning on CUA mode came at no cost, the problem is that it does
> come at considerable cost. If CUA was enabled by default, many new users
> would never be aware of the additional functionality that has to be lost
> in order to get this level of compatibility. They would also be less
> likely to pick up the overall scheme that underlies much ofEmacs' key
> bindings.
Tim, what functionality do you think would be lost? Bindings which
start with C-c and C-x? CUA-mode does a nice job already of making
them available when no region is active. For commands which require a
region, an alternative prefix could be devised (as a CUA-mode user,
I've done this).
> They would also be less
> likely to pick up the overall scheme that underlies much ofEmacs' key
> bindings.
This will not be a fault of Emacs, however. What if they will more
likely stay in Emacs more, instead? At least, that's been my
experience: if it weren't for CUA-mode, I don't think I would have
stayed in Emacs. To me, a program which does not understands ZXCV, Alt
+F4 (close app), ecc. on Windows is just broken. Yes, I know Emacs
pre-dates CUA, and maybe its editing model is even better, however I
have to get things done and having a keybinding which in one
applications copies text while in another closes a window will be
confusing and/or frustrating. It's easier to customize Emacs than to
customize every other app out there.
Am I too lazy? I don't think so. I'm an old dog too, but I'm willing
to learn new tricks when there is no way around it. For instance, I
don't even care that much for CUA anymore, since nowadays I've
switched to Viper + Vimpulse.
> Having it so that it is easy to turn on for those who insist on it is a
> good compromise. New users will be aware they have explicitly changed
> things when they do it and other new users will likely decide to go with
> the defuaults and may get the full benefit of those defaults and
> exposure to an alternative which may actually be better.
I would agree if we had some suggestions on Emacs' welcome screen,
then. Let's not forget that Emacs requires you to save options
between sessions too, which is a confusing design choice I think.
> Again, this cripples much of the power ofemacsthat actually represents
> what makes it stand out from the crowd. If we makeemacsdefault to
> being just like all other editors, we don't expose new users to what
> makes it different.
Again, I don't think so. Emacs is much much more than its
keybindings. Already, I've told about me switching to Emacs *because*
I found a way to have CUA enabled (back in the days when it wasn't a
menu option, neither transient-mark-mode was the default).
> Sure, XEMacs introduced some ideas which have been adopted byemacsand
> many predicted the demise ofEmacs. However, now around 15 years down
> the track, we seeemacspowering forward and xemacs somewhat
> languishing.
Yeah. However, what I was suggesting is that sometimes we have
progress because some new dog disagrees and follow her own way. I
hate forks, because they are a waste of focus and resources, but I'm
convinced that having a "competitor" pushed GNU Emacs to improve.
> I don't disagree completely with a 'novice' mode. However, my suggestion
> would be to reverse your proposal. Have a command line switch that sets
> things up in a way that would possibly make things more familiar to a
> new user and include warnings when you startemacsthat using this mode
> will result in resrictions/limitations to the power ofemacsand
> encourage the user to stop using novice mode as soon as they feel
> comfortable.
However, a command-line switch would be awkward for novices and
annoying for power users. Moreover, in GUI environments, users do not
routinely launch applications from the command line, thus you'd have
to create two links to launch Emacs. In this case, I think the KISS
principle would dictate to put such information in the welcome screen,
making it easy to power users to ignore it as well as to novices to
know it. And making options persistent by default, while maybe giving
users who lack a .emacs yet a chance to erase all customization.
Elena
> Define those basic expectations. So far, you have mentioned lack of
> support for the common cut/copy/paste commands on the CUA
> bindings, but that is available with one click in the options menu.
A basic expectation is that CUA does not require you to hunt for an
option to enable it. It just works out of the box.
> You
> mention lack of a file browser, yetemacshas two in its vanilla
> configuration.
Oh, no, this was an unrelated observation. I was saying that all
editors I've tried which target programmers have a project file tree
on the left and output windows on the bottom. OTOH, Emacs is known to
being used by programmers, still setting up such a configuration is
awkward, then popups are disrupting your windows layout all the time,
ecc. Confusing, confusing.
Currently my preferred file browser is that offered by IDO, but I
depended for a long time on the basic GUI one.
Elena
> because they are invested in the status quo and don't want that effort
> lost.
That's fine. No effort should ever be lost, if possible. We should
strive to protect the investment of old-timers, while striving to ease
transition to novices.
> Alternatively, you could say that those who have stuck with it
> have experienced the difference and are now aware of its benefits and
> don't want to see those benefits compromised for short term gain.
No. I would say that those who have invested a lot of time already in
something are not motivated to make things easier. They are not nasty
people, that's a common human trait. First, there is a phenomenon
known as the curse of knowledge (http://idratherbewriting.com/
2007/01/24/the-curse-of-knowledge-the-more-you-know-the-worse-
communicator-you-become/), which makes hard for experts to understand
the struggles novices face. Second, there is a phenomenon known as
Cognitive Dissonance (http://en.wikipedia.org/wiki/
Cognitive_dissonance) that makes you believe that if you think you are
smart and you have thrown a lot of time into something, then it must
have been worth it.
Or maybe, I'm just alone in thinking Emacs is not its default
keybindings, and binding for instance C-c to something else to make C-
c available for copying does not impact its effectiveness in any way.
Again, CUA-mode designer have made the very smart decision of
overriding only keybindings which work on a region. Maybe, I'm just
alone in thinking that OTOH renaming "buffers" to "frames" and
"frames" to "windows" is not worth it because it would break all
existing APIs and documentation for no real benefit, because when you
are reading you can easily do such renaming on the fly, albeit doing a
remapping on the fly while fast editing will not work as well.
Richard Kettlewell
> Ah, sorry, I thought CUA was Macintosh standard Command keys. Indeed,
> IBM Common User Access keys are even worse. Why would anybody consider
> them?
>
> Cut = S-DEL
> Copy = C-Ins
> Paste = S-Ins
>
> Hello? Anybody home?
Incidentally, the standard Macintosh keys (⌘C, ⌘V, ⌘A, etc) _do_ work in
Emacs.app (i.e. Emacs using the Mac's native GUI).
Pascal J. Bourguignon
Perhaps the problem here is that you're trying to organize the windows
yourself. Let emacs pop the windows for your, and organize them for
you. You'll spend less time moving windows around, and more time
programming or debugging. Hence emacs will increase your productivity.
Pascal J. Bourguignon
> Or maybe, I'm just alone in thinking Emacs is not its default
> keybindings, and binding for instance C-c to something else to make C-
> c available for copying does not impact its effectiveness in any way.
> Again, CUA-mode designer have made the very smart decision of
> overriding only keybindings which work on a region. Maybe, I'm just
> alone in thinking that OTOH renaming "buffers" to "frames" and
> "frames" to "windows" is not worth it because it would break all
> existing APIs and documentation for no real benefit, because when you
> are reading you can easily do such renaming on the fly, albeit doing a
> remapping on the fly while fast editing will not work as well.
The reason why it's not useful to rename frames and windows, is that
soon there will remain no windows in the other systems used by people.
Namely, iOS or Android.
Elena
> I find this repeated criticism a little weak. Ignoring the fact thatemacshas this support and all you have to do is click a menu item to
> get it, it completely overlooks the fact that theemacskeys for copty,
> paste, cut etc pre-date the now common standard seen in many (and not
> all BTW) applications.
Such a retort can be easily reversed by saying Emacs overlooks the
fact that nowadays the overwhelming majority of applications on any
given platform agree on many keybindings, making life easier for
users. Old dogs vs young dogs, you know ;-)
> Some will argue thatemacssupport for CUA is
> broken because either it destroys other useful key bindings or that it
> should be made the default.
Smart people recognize the difference between a broken design and a
trade-off.
> I don't think there is a solution to the
> first issue.Emacshas more shortcut keys than any other application
> I've ever used and as a consequence, making substantial changes will
> result in either loss of some bindings or the need to remap a lot of
> bindings.
I think an easy solution exists. First, here is a one liner for each
binding:
;; C-, is unbound on my "emacs -q" and using it should not be life-
threatening ;-)
(global-set-key (kbd "C-,") (lookup-key global-map (kbd "C-x")))
;; C-.is unbound on my "emacs -q" and using it should not be life-
threatening ;-)
(global-set-key (kbd "C-.") (lookup-key global-map (kbd "C-x")))
Now, you have to deal with any legacy package which overwrites these
bindings, for instance by means of an hook to "load-library".
> The second issue ignores the
> fact there are a lot ofemacsusers out there - probably more than the
> number o new users who cannot get accustomed to the established key
> bindings, who would be frustrated by such a dramatic change in the
> default.
Making it easy for novices is easy. Making it easy for experts is
easy. Balancing those two things is what great design is. ;-)
Jack Welch admonished managers: "Anybody can manage short. Anybody can
manage long. Balancing those two things is what management is."
> This sort of argument often seems to stem from a misguided attempt to
> makeemacsmore popular. As we all know, trying to be popular is seldom
> successful and when it is, it is frequently short lived.
No popularity seeking at work here. Just over-simplification and
requiring adaptation from software instead of from users.
> As Alan points out, when you have such a wealth of choice, identifying
> the correct combination for everyone is going to be nearly impossible.
I don't think so. There could be different starting points.
> Saying it 'sucks' is misleading. It doesn't suck, it is just different
> to what some users are use to.
OK, I said "sucks", but it was too much (foreigner writing in an
hurry).
> Some argue that what is needed is for an update of all these names and
> terms to something more 'modern' and familiar and a re-write of the
> manual. There are numerous issues this raise which nobody seems to have
> a good answer to. Firstly, I think most under estimate the amount of
> work this would require. Not only would you need to change the manuals,
> but also the names of commands, variables and many other code artifacts.
> Just changing the documentation is not enough because using one set of
> terms in the documents and another in the program would just cause
> confusion. Imagine reading all about windows and 'panes' and then having
> to realize that to create windows and 'panes', you deal with variables
> and functions with frames and windows etc, A huge job where the effort
> probably exceeds the benefits. Then you still have the problem that things
> are not static. These terms and their common definitions are likely to
> continue to evolve and after another decade or two, we will be back in
> the same position. Another problem is that it would frustrate and
> likely confuse the existing user base, who are more likely to be long
> term users and supporters/maintainers than many of the new users who are
> simply trying it out to see what it is all about, many of which are
> unlikely to be willing or interested enough to learn and understand what
> makes it different. Such users will be just as happy with a different
> editor.
I've answered already I agree on this. I think the only fix to this
is a preamble to Emacs' manual.
> I'm not convinced with the argument that you need to be a usability
> specialist in order to configure emacs.
You don't need to be a usability specialist to configure Emacs, you
need to be it to configure your environment. I think all this
discussion stems from me talking about human interaction issues, while
others are concerned about Emacs Lisp and keybindings.
> This argument has merit if your
> talking about a default configuration suitable for the majority of
> users.
What about having different starting points users can improve on? At
least for keybindings, we are already there: there are vanilla Emacs,
vanilla Emacs + CUA, Viper + Vimpulse, ErgoEmacs...
> However, it is less convincing when considering things from the
> individual perspective. It is unlikely any usability expert will
> understand my requirements or preferences as well as I do. While it may
> be possible that such an expert may recognize a weakness in something
> I'm trying to do and would avoid the effort, it is also possible I might
> actually do something that works really well for me (and possibly
> others) that such an expert would not have tried.
OTOH, it is unlikely you will have the knowledge an usability designer
has to get you a better starti
> Really original ideas
> often come from people who were not experts and therefore were not
> constrained by conventional ideas or thinking.
Yes. We do need more mundane ideas too.
> The real power inemacsis in the ability to create whatever environment
> you want.
Yes. The weakness lies in having to do that without proper knowledge
about usability and with very basic building blocks. Moreover, users
think they do not need any training on usability issues, since they
*know* what's better for them than anyone else. They are mostly wrong
of course, since someone who spends a lot of time studying usability
issues is in a better position to help you find your way.
Pascal J. Bourguignon
> On 7 Nov, 02:40, Tim X <t...@nospam.dev.null> wrote:
>> I find this repeated criticism a little weak. Ignoring the fact thatemacshas this support and all you have to do is click a menu item to
>> get it, it completely overlooks the fact that theemacskeys for copty,
>> paste, cut etc pre-date the now common standard seen in many (and not
>> all BTW) applications.
>
> Such a retort can be easily reversed by saying Emacs overlooks the
> fact that nowadays the overwhelming majority of applications on any
> given platform agree on many keybindings, making life easier for
> users. Old dogs vs young dogs, you know ;-)
No, this has nothing to do with that.
What you don't understand, is that emacs is not a mere application
running on MacOSX or on MS-Windows or on Linux.
emacs is actually an operating system, with its own window manager, and
it's own consistent user interface.
It just happens that nobody makes the hardware to run the emacs OS
anymore. It was the LispMachines. So it has to run as a virtual
machine (ever since it was conceived, admitedly and regretably).
When you run MS-Windows in a virtual machine on MacOSX, you don't
complain that it doesn't respect the MacOSX User Interface Guidelines!
And when you run MS-Windows in a virtual machine on Linux, you don't
complain that it doesn't do things like normal unix applications!
Same here.
http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
Perhaps what makes you lose sight that emacs is an OS, is because there
are not a lot of applications that run on both emacs and other systems.
Of the tip of my head, I can cite only two:
- info(1) and M-x info.
- w3m(1) and M-x w3m.
Try them in a MacOSX Terminal.app window, or on MS-Windows, and then try
them on the emacs OS.
Now, for example, I don't like the MS-Windows system, so I don't use it.
If you don't like the emacs system, you can just forget it and don't use
it ever. You can still choose amongst half a dozen other OSes, and for
each emacs application, there are tons of equivalent applications on
these other OSes.
> I think an easy solution exists. First, here is a one liner for each
> binding:
This is something for you to do, not for the reference distribution of
emacs.
And as I mentionned, it's free software, you are even free to make your
own distribution of emacs.
> Now, you have to deal with any legacy package which overwrites these
> bindings, for instance by means of an hook to "load-library".
Yes, being a distribution creator is not easy life.
> I've answered already I agree on this. I think the only fix to this
> is a preamble to Emacs' manual.
What could be added in the preamble if it's not already there, is what
all emacser knows very well even if it's not often mentionned in public,
is that emacs is an OS running on a VM, and it would be nice if Intel,
AMD, or some other founder woud make a LispMachine processor again.
With some microprogramming, it could even be made to run as well
LispMachine microcode as JVM as a few others similar 'V'Ms.
> What about having different starting points users can improve on? At
> least for keybindings, we are already there: there are vanilla Emacs,
> vanilla Emacs + CUA, Viper + Vimpulse, ErgoEmacs...
Why don't you try Emacs.app or Aquamacs.app?
Mark Wooding
> I was saying that all editors I've tried which target programmers have
> a project file tree on the left and output windows on the bottom.
Your experience of other editors is obviously so meagre as to be
worthless. I don't know of any versions of vi which behave as you
describe; and certainly none of the editors I used on an IBM mainframe
did either.
Indeed, I think you might be confusing `editor' with `integrated
development environment'. Such things are also prone to insisting on
showing you only one file at a time, filling your screen with junk other
than the text you're actually working on, and making it hideously
inconvenient to work on more than one `project' at a time, whatever that
means.
> OTOH, Emacs is known to being used by programmers, still setting up
> such a configuration is awkward, then popups are disrupting your
> windows layout all the time, ecc. Confusing, confusing.
It sounds to me like you want BlubEdit. It's over there.
-- [mdw]
Mark Wooding
> On 7 Nov, 22:07, Tim X <t...@nospam.dev.null> wrote:
> > You could say that the issue is you can't teach oldemacsusers new ways
> > because they are invested in the status quo and don't want that effort
> > lost.
>
> That's fine. No effort should ever be lost, if possible. We should
> strive to protect the investment of old-timers, while striving to ease
> transition to novices.
The point is that most users of Emacs spend most of their time being
`old-timers'. This is therefore the period of use that should receive
the most effort.
Users who don't graduate to `old-timer' status -- well, I guess Emacs
isn't for them. Sorry. To be honest, the best thing we can do for such
people is to help them stop wasting more of their time than necessary.
> Again, CUA-mode designer have made the very smart decision of
> overriding only keybindings which work on a region.
Yes. Because having keystrokes randomly do completely different things
depending on whether the region is active isn't at all confusing.
> Maybe, I'm just alone in thinking that OTOH renaming "buffers" to
> "frames"
Yes, I think that probably makes you unique.
> and "frames" to "windows" is not worth it because it would break all
> existing APIs and documentation for no real benefit, because when you
> are reading you can easily do such renaming on the fly, albeit doing a
> remapping on the fly while fast editing will not work as well.
It's not about doing a `remapping'. It's about undertanding concepts
like layering. Concepts have a scope: Emacs windows aren't the same as
X windows (or whatever window system you use): Emacs has its own
conceptual framework, which it maps onto the surrounding environment:
this is part of what makes it able to work in so many different
environments. It's unfortunate that there's some confusion, but the
underlying lesson is important and worth learning.
-- [mdw]
Elena
> The reason why it's not useful to rename frames and windows, is that
> soon there will remain no windows in the other systems used by people.
I'm not saying it's not useful, I'm saying it cannot be done. Period.
Thanks for letting me know about usefulness, though.
Elena
> Users who don't graduate to `old-timer' status -- well, I guessEmacs
> isn't for them. Sorry. To be honest, the best thing we can do for such
> people is to help them stop wasting more of their time than necessary.
So, since:
- I've never learned C-c and C-x shortcuts - neither I will - because:
* I remapped all of them since they confuse me all the time while
being outside Emacs
* they are optimized for Qwerty, while I'm a Dvorak typist...
- I try to learn as little bindings as possible by mapping similar
commands in different Emacs modes or different applications to same
keychords...
- I try to learn from old-timers' experience instead of scavenging for
Emacs Lisp scraps...
then I will never be an old-timer. Well, I'm accepting it and
stopping complaining right now.
> Yes. Because having keystrokes randomly do completely different things
> depending on whether the region is active isn't at all confusing.
Reality is much simpler: remap commands which start with either C-c or
C-x to something else when they work on region.
> It's not about doing a `remapping'. It's about undertanding concepts
> like layering. Concepts have a scope:Emacswindows aren't the same as
> X windows (or whatever window system you use):Emacshas its own
> conceptual framework, which it maps onto the surrounding environment:
> this is part of what makes it able to work in so many different
> environments. It's unfortunate that there's some confusion, but the
> underlying lesson is important and worth learning.
Well, even more power to Emacs' terms, then.
Mark Wooding
> So, since:
> - I've never learned C-c and C-x shortcuts - neither I will - because:
> * I remapped all of them since they confuse me all the time while
> being outside Emacs
> * they are optimized for Qwerty, while I'm a Dvorak typist...
Ah! Now that makes a difference, yes! I can see some value in a
carefully thought out package for making effective use of Emacs with a
Dvorak keyboard layout.
(The `CUA' undo/cut/copy/paste bindings no longer make any sense with a
Dvorak keyboard. What happens to those bindings on, say, French Azerty
and German Qwertz keyboards?)
> - I try to learn as little bindings as possible by mapping similar
> commands in different Emacs modes or different applications to same
> keychords...
There's usually some underlying logic to the mode-specific bindings. I
can't say that I've worked out what the logic is for outline-mode,
though.
> - I try to learn from old-timers' experience instead of scavenging for
> Emacs Lisp scraps...
That's fine. Piecing together small bits of Lisp oneself is a useful
skill, though. Indeed, exposing users to Lisp, however antiquated, is
one of Emacs's great contributions.
> Reality is much simpler: remap commands which start with either C-c or
> C-x to something else when they work on region.
That's a never-ending job, though -- and it makes all of the (external)
documentation wrong. Emacs itself is clever enough to print the right
key bindings in its help, but the manual will still be wrong.
-- [mdw]
Elena
> (The `CUA' undo/cut/copy/paste bindings no longer make any sense with a
> Dvorak keyboard. What happens to those bindings on, say, French Azerty
> and German Qwertz keyboards?)
I do not use CUA anyway, since I use Viper + Vimpulse. Thus I'm not
aware of Emacs' key-sequences for commands which have a corresponding
for Vi-like mapping, either. I was arguing over CUA in principle,
since I think that every applications should conform to it, Emacs
included, even when Emacs pre-dates it and even if there are trade-
offs to be made to avoid hurting old-timers, existing packages,
documentation. It is rather unfortunate that CUA bindings are two
among the most important in Emacs, but still...
> There's usually some underlying logic to the mode-specific bindings.
Agreed, however, there is no reason to prefer a packages' bindings to
another one's. For instance, in my configuration C-c C-c compiles
current function in both SLIME and Emacs Lisp modes, and if I were to
use some other interactive REPL, I'd rebind the command right away to
corresponding "compile current function" command. No reason to have
two different keychords.
> > - I try to learn from old-timers' experience instead of scavenging for
> > Emacs Lisp scraps...
>
> That's fine. Piecing together small bits of Lisp oneself is a useful
> skill, though. Indeed, exposing users to Lisp, however antiquated, is
> one of Emacs's great contributions.
Agreed. I just wished it would easier not to miss the forest for the
trees. I would love watching some master "Emacser" at work. I'm sure
there is a lot to learn which I don't feel has been poured into the
many tutorials and posts which many old-timers have been kind enough
to contribute to Emacs' community.
> > Reality is much simpler: remap commands which start with either C-c or
> > C-x to something else when they work on region.
>
> That's a never-ending job, though -- and it makes all of the (external)
> documentation wrong. Emacs itself is clever enough to print the right
> key bindings in its help, but the manual will still be wrong.
If you were seeking perfection, that would be correct. I was
suggesting a trade-off instead, like a warning to users which enable
alternative keybindings that then they would have to make a mental
translation to follow shared documentation, just like they have to
understand and/or "remap" the meanings of "buffer", "window", "frame",
"kill", "yank", ecc. I think Emacs and "modern" novices should meet
in the middle.
David Kastrup
> On Nov 8, 3:40 pm, m...@distorted.org.uk (Mark Wooding) wrote:
>> (The `CUA' undo/cut/copy/paste bindings no longer make any sense with a
>> Dvorak keyboard. What happens to those bindings on, say, French Azerty
>> and German Qwertz keyboards?)
>
> I do not use CUA anyway, since I use Viper + Vimpulse. Thus I'm not
> aware of Emacs' key-sequences for commands which have a corresponding
> for Vi-like mapping, either. I was arguing over CUA in principle,
Please don't. Arguing for the sake of imaginary users distorts the
meaningfulness of feedback.
--
David Kastrup
Elena
> Please don't. Arguing for the sake of imaginary users distorts the
> meaningfulness of feedback.
I apologize for not being precise. I was not talking in theory. That
has been my own experience while learning Emacs. I still keep CUA-
mode enabled for convenience, even when nowadays I have much less need
for it, and I would advice learning better ways to novices.
Jason Earl
> Elena <egar...@gmail.com> writes:
>
>> So, since:
>> - I've never learned C-c and C-x shortcuts - neither I will - because:
>> * I remapped all of them since they confuse me all the time while
>> being outside Emacs
>> * they are optimized for Qwerty, while I'm a Dvorak typist...
>
> Ah! Now that makes a difference, yes! I can see some value in a
> carefully thought out package for making effective use of Emacs with a
> Dvorak keyboard layout.
>
> (The `CUA' undo/cut/copy/paste bindings no longer make any sense with
> a Dvorak keyboard. What happens to those bindings on, say, French
> Azerty and German Qwertz keyboards?)
The useful thing about Xah's tutorials is that they show you how to
leverage the power of Emacs by writing Emacs Lisp. Personally, I think
that his keybinding and keyboard re-mapping ideas are madness, but his
lisp tutorials are great.
I decided long ago that the best way to use Emacs was to simply drink
the Kool-Aid and accept the fact that the hackers that wrote Emacs knew
what they were doing when it came to text editing. I have been pretty
happy with that decision. In fact, I lurk on Emacs-devel almost
entirely for the editing tips that come out when keymapping discussions
come up. Someone invariably complains about any new change, and their
complaints are generally full of clues for ways that I can leverage
Emacs in my own editing.
Sure, the other applications that I use employ different key bindings.
I deal with this by using other applications as infrequently as
possible. I spend most of my day editing text, and with Emacs I can use
the same application (and the same editor tricks) for *all* of my
editing. Not just my coding, but email and document creation as well.
These days I practically live in org-mode.
>> - I try to learn as little bindings as possible by mapping similar
>> commands in different Emacs modes or different applications to same
>> keychords...
>
> There's usually some underlying logic to the mode-specific bindings.
> I can't say that I've worked out what the logic is for outline-mode,
> though.
Yeah, tell me about it. However, org-mode is better than outline-mode
in basically every way, and its keybindings make sense (at least to
me).
>> - I try to learn from old-timers' experience instead of scavenging for
>> Emacs Lisp scraps...
>
> That's fine. Piecing together small bits of Lisp oneself is a useful
> skill, though. Indeed, exposing users to Lisp, however antiquated, is
> one of Emacs's great contributions.
Which is why I would like to see Xah write a Elisp cookbook. I am to
the point in my Emacs career where what I really want is to become a
competent Emacs developer. Unfortunately, the going on this front has
been very slow. Emacs is very well documented, but there is a large gap
between the /Emacs Lisp Intro/ and being able to write something like
magit. The /Emacs Lisp Reference Manual/ covers Emacs Lisp in detail,
but it does not give the high level overview that I would like.
Xah's tutorials have been very helpful, but I would certainly be willing
to pay for more.
>> Reality is much simpler: remap commands which start with either C-c or
>> C-x to something else when they work on region.
>
> That's a never-ending job, though -- and it makes all of the
> (external) documentation wrong. Emacs itself is clever enough to
> print the right key bindings in its help, but the manual will still be
> wrong.
Besides, I do not think that anyone needs a new book to teach them to do
this. All the tools that you need to remap keybindings are well covered
in the Emacs manual.
Jason
Mark Wooding
> On Mon, Nov 08 2010, Mark Wooding wrote:
> > I can't say that I've worked out what the logic is for outline-mode,
>
> Yeah, tell me about it. However, org-mode is better than outline-mode
> in basically every way, and its keybindings make sense (at least to
> me).
Oh, org-mode is completely winning in almost every way. But I find
outline-minor-mode very useful (e.g., when writing Serious TeX
documents), if only I can remember the damned bindings...
-- [mdw]
Tim X
> On 7 Nov, 22:07, Tim X <t...@nospam.dev.null> wrote:
>> I think there is a flaw in this suggestion. While this could be a good
>> idea if turning on CUA mode came at no cost, the problem is that it does
>> come at considerable cost. If CUA was enabled by default, many new users
>> would never be aware of the additional functionality that has to be lost
>> in order to get this level of compatibility. They would also be less
>> likely to pick up the overall scheme that underlies much ofEmacs' key
>> bindings.
>
> Tim, what functionality do you think would be lost? Bindings which
> start with C-c and C-x? CUA-mode does a nice job already of making
> them available when no region is active. For commands which require a
> region, an alternative prefix could be devised (as a CUA-mode user,
> I've done this).
>
Yes, it can be done, but I thought we were talking about trying to make
it easier for new users who found things too unfamiliar. The number of
things that get broken with CUA mode is quite large, especially once you
start installing additional useful packages that use some of these
prefixes.
>> They would also be less
>> likely to pick up the overall scheme that underlies much ofEmacs' key
>> bindings.
>
> This will not be a fault of Emacs, however. What if they will more
> likely stay in Emacs more, instead? At least, that's been my
> experience: if it weren't for CUA-mode, I don't think I would have
> stayed in Emacs. To me, a program which does not understands ZXCV, Alt
> +F4 (close app), ecc. on Windows is just broken. Yes, I know Emacs
> pre-dates CUA, and maybe its editing model is even better, however I
> have to get things done and having a keybinding which in one
> applications copies text while in another closes a window will be
> confusing and/or frustrating. It's easier to customize Emacs than to
> customize every other app out there.
>
For every person who may have an issue with it, we can likely find
someone who doesn't. I don't find it an issue and find the consistency
with the defaults far more beneficial.
Note that I'm not saying we should not have CUA mode and I have no issue
with it being easy to enable via the options menu. What I feel would be
a mistake is making that the default. To be honest, I really think that
as an issue, it is over stated.
> Am I too lazy? I don't think so. I'm an old dog too, but I'm willing
> to learn new tricks when there is no way around it. For instance, I
> don't even care that much for CUA anymore, since nowadays I've
> switched to Viper + Vimpulse.
>
>> Having it so that it is easy to turn on for those who insist on it is a
>> good compromise. New users will be aware they have explicitly changed
>> things when they do it and other new users will likely decide to go with
>> the defuaults and may get the full benefit of those defaults and
>> exposure to an alternative which may actually be better.
>
> I would agree if we had some suggestions on Emacs' welcome screen,
> then. Let's not forget that Emacs requires you to save options
> between sessions too, which is a confusing design choice I think.
Huh? Not what I find. Provided a select 'Save Options' once I make any
changes to options in that menu, they persist over sessions.
>
>> Again, this cripples much of the power ofemacsthat actually represents
>> what makes it stand out from the crowd. If we makeemacsdefault to
>> being just like all other editors, we don't expose new users to what
>> makes it different.
>
> Again, I don't think so. Emacs is much much more than its
> keybindings. Already, I've told about me switching to Emacs *because*
> I found a way to have CUA enabled (back in the days when it wasn't a
> menu option, neither transient-mark-mode was the default).
>
>> Sure, XEMacs introduced some ideas which have been adopted byemacsand
>> many predicted the demise ofEmacs. However, now around 15 years down
>> the track, we seeemacspowering forward and xemacs somewhat
>> languishing.
>
> Yeah. However, what I was suggesting is that sometimes we have
> progress because some new dog disagrees and follow her own way. I
> hate forks, because they are a waste of focus and resources, but I'm
> convinced that having a "competitor" pushed GNU Emacs to improve.
>
Given only one significant fork and all others being short lived and
soon forgotten, I'm not convinced there is sufficient data points to
make such a claim. There are a number of features Emacs refused to
incorporate from XEmacs for various reasons and various that were done
in a completely different manner because Emacs maintainers saw
weaknesses or incompatibilities that were likely to cause more long term
issues than the short-term benefits. It is also difficult to know what
the relative priorities and targets were. All development happens within
an environment of limited resources. Therefore features and bug
resolution needs to be prioritised. From the posts I've seen over the
years, to a large extent, the differences between GNU Emacs and XEmacs
seem to be largely about priorities.
Differences in agreement concerning how a feature should be implemented
often arise because we don't yet fully understand the issues and have
consensus over the priorities. I think a good example of this is the
struggle over getting one single widely accepted framework for managing
libraries and dependencies within CL. I've lost count of the number of
different approaches and implementations we have. While it would be
great if all the effort being put into these different solutions were
focused on one single implementation, I suspect this has not occured
because we don't have a clear consensus on exactly what such a framework
should do and what the priorities are.
I don't see a problem with forks of software. Frequently they are the
only way to get a new idea incorporated. Even more important, I would
suggest such forks help us to better understand the problems and issues
involved. Sometimes, the only way we really understand the dritty
details of a problem is to implement it the wrong way.
The growth in distributed version control really encourages forks. More
critically, it provides an easier way to cherry pick the good ideas from
these forks. While it still may not be the most efficient use of
resources, the ability to pick bits out may reduce the level of lost
effort.
>> I don't disagree completely with a 'novice' mode. However, my suggestion
>> would be to reverse your proposal. Have a command line switch that sets
>> things up in a way that would possibly make things more familiar to a
>> new user and include warnings when you startemacsthat using this mode
>> will result in resrictions/limitations to the power ofemacsand
>> encourage the user to stop using novice mode as soon as they feel
>> comfortable.
>
> However, a command-line switch would be awkward for novices and
> annoying for power users. Moreover, in GUI environments, users do not
> routinely launch applications from the command line, thus you'd have
> to create two links to launch Emacs. In this case, I think the KISS
> principle would dictate to put such information in the welcome screen,
> making it easy to power users to ignore it as well as to novices to
> know it. And making options persistent by default, while maybe giving
> users who lack a .emacs yet a chance to erase all customization.
Obviously, the command switch would not have any annoying impact for the
existing user as they would just ignore it. Extending your suggestion
further, put the details on how to run in 'novice' mode in the welcome
screen.
Claiming the need for two links to launch emacs is over stating maters.
Either the user wants novice mode or they don't. You are not going to want
both and lets face it, creating a link, a launcher, etc is a trivial
task. Anyone who has not mastered that level of basic usage is almost
certainly going to be out of their depth with emacs and unable to
appreciate its strengths. Emacs is not an editor for anyone who only
does a litle casual editing. For these users, notepad, nano, pico, or
any of hundreds of other editors will be more than sufficient.
I also like Pascal's idea of having emacs alert you to better ways to do
things. It already does this to a limited extent when you issue a M-x
command that also has a key binding by alerting you to the fact you can
execute that command with a key. There have been other modes developed
to help with this, such as the key binding quiz mode that tests your
knowledge of emacs key bindings
I'm still unsure if the novice issue is that big a problem. I regularly
come across new users and based on their questions etc, few seem to have
more than a transient issue with things like key bindings. Yes, there
is a group that end up not likeing Emacs and often, one of the reasons
they state will be the key bindings, but when you look at most of the
other reasons, it becomes obvious they were not the sor tof user who was
ever going to really like emacs regardless of largely 'surface issues'
such as key bindings. Those who find emacs suits their way of thinking
and working, who find its customization and extensibility useful also
tend to be those who will adjust fairly readily as well. They also tend
to be the users who will stay with emacs.
It is probably obvious that my perspective is that the long term users
are far more important than new users. Emacs is not an editor for
everyone and I personally have no desire or expectation that it should
become the default editor for any particular group. It is the long term
users that keep it alive. I'm not against any improvements that may make
the transition easier for new users, but not at any cost.
Tim
--
tcross (at) rapttech dot com dot au
Tim X
> On 7 Nov, 21:24, Tim X <t...@nospam.dev.null> wrote:
>> Define those basic expectations. So far, you have mentioned lack of
>> support for the common cut/copy/paste commands on the CUA
>> bindings, but that is available with one click in the options menu.
>
> A basic expectation is that CUA does not require you to hunt for an
> option to enable it. It just works out of the box.
I think it is difficult to make such a claim when you are referring to
what is essentially a programmers editor. Such a basic expectation may
be expected for a novice computer user, but less compelling for a more
experienced user searching for a power editor that will enhance their
programming environment. Essentiallly, I don't believe you can use a
single yard stick to measure expectations. Emacs is not targeted at all
users. To define the reasonable set of expectations, I think you need to
define your expected user base and then examine what those expecations
are. While I would expect there would be some experienced programmers
who find the new key bindings a surprise and some of those may even find
the lack of CUA style bindings annoying, I suspect the number who both
find it anoying and cannot work out how to enable CUA mode from the
options menu is very small.
>
>> You
>> mention lack of a file browser, yetemacshas two in its vanilla
>> configuration.
>
> Oh, no, this was an unrelated observation. I was saying that all
> editors I've tried which target programmers have a project file tree
> on the left and output windows on the bottom. OTOH, Emacs is known to
> being used by programmers, still setting up such a configuration is
> awkward, then popups are disrupting your windows layout all the time,
> ecc. Confusing, confusing.
>
> Currently my preferred file browser is that offered by IDO, but I
> depended for a long time on the basic GUI one.
Are you talking about speedbar? I use to use it a bit, but rarely do any
more. To some extent, I suspect many of tghe differences will depend on
whether someone is a keyboard oriented person or a mouse oriented
person. I personally find the mouse to be inefficient and frustrating.
For me, keyborad navigation has always been faster and I guess as such,
GUI browsable/scrollable file trees are less beneficial.
I tried ido. Lasted about 6 weeks. In the end, got rid of it. I found it
kept getting in the way. It tried to be helpful and often it was, but
more often, I had to jump through extra hoops to stop it from trying to
be so helpful.
I still find this all quite trivial and to some extent very minor side
issues. Key bindings and GUI file browsers are minor bits of sugar
compared to the core functionality that I expect to find in a
programmers editor.
The majority of what I do is editing code. I rarely need to browse trees
of directories or files. Using tags and well structured directory
layouts for projects and I find I rarely have to browse or need such a
feature. When I do, dired provides what I need and a lot more.
Far more important is the ability to navigate code efficiently,
automatic and consistent indentation, close integration with my
programming tools and languages, the ability to have powerful code
templates, dynamic completion, efficient edit -> compile -> debug cycles
for those languages that need them or a powerful interface to the repl
for those that don't and most importantly, the ability to establish an
environment which works with the project I'm dealing with and not one
that forces me to munge my project to fit with the development
environment.
Elena
> For every person who may have an issue with it, we can likely find
> someone who doesn't. I don't find it an issue and find the consistency
> with the defaults far more beneficial.
>
> Note that I'm not saying we should not have CUA mode and I have no issue
> with it being easy to enable via the options menu. What I feel would be
> a mistake is making that the default. To be honest, I really think that
> as an issue, it is over stated.
Well, I admit I could be a minority.
> Huh? Not what I find. Provided a select 'Save Options' once I make any
> changes to options in that menu, they persist over sessions.
All other applications I can think of do not require you to save
options as a separate step. Once you've given OK to a dialog, your
settings are going to stay. Even the humble MS Notepad behaves like
that.
> Obviously, the command switch would not have any annoying impact for the
> existing user as they would just ignore it. Extending your suggestion
> further, put the details on how to run in 'novice' mode in the welcome
> screen.
I don't understand whether this is a question. Since all novice users
will meet the welcome screen, I thought it would make sense to put
there information relevant to novices, as it is the case already. You
could even offer the chance to run a wizard from there. I think the
welcome screen, or a screen accessible from it, should try to let the
user know about any Emacs behavior which could go against what is
common practice on a give platform. You could inform the user about
existing emulation modes (Viper, ecc.) which he could find handy.
> I'm still unsure if the novice issue is that big a problem. I regularly
> come across new users and based on their questions etc, few seem to have
> more than a transient issue with things like key bindings.
I think keybindings are the tip of the iceberg.
> I'm not against any improvements that may make
> the transition easier for new users, but not at any cost.
I share your view.
Pascal J. Bourguignon
> Sure, the other applications that I use employ different key bindings.
> I deal with this by using other applications as infrequently as
> possible. I spend most of my day editing text, and with Emacs I can use
> the same application (and the same editor tricks) for *all* of my
> editing. Not just my coding, but email and document creation as well.
>
> These days I practically live in org-mode.
What's more, other applications tend to adopt basic emac keybindings
too.
For example, the NSText object used by applications for most editable
text zones interprets like emacs most of the Control- keys.
Antony
> But this is plain wrong! Vanilla emacs has a perfectly good file browser.
>
> Try it: C-x C-f TAB
>
Thank you.
I usually avoid opening directories since I end with lots of buffers.
But, the above is a neat trick to browse to the dir of interest without
opening directories as buffers.
-Antony
Tassilo Horn
> Before that, we need an essential tool for emacs videos: we need
> something that displays on the screen the keychords used.
Simply set `echo-keystrokes' to a sufficiently low value. Hm, ok, after
finishing the keystroke you'd normally want to keep it displayed a
second or so, even if the invoked command uses the minibuffer...
Bye,
Tassilo
Jean-Baptiste Bourgoin
> No, this has nothing to do with that.
>
> What you don't understand, is that emacs is not a mere application
> running on MacOSX or on MS-Windows or on Linux.
>
> emacs is actually an operating system, with its own window manager, and
> it's own consistent user interface.
I agree, more precisely : emacs is a lisp environment that run lisp's
programs specialized in text processing.
Jean-Baptiste Bourgoin
> Read again my first two paragraphs. About the only other program I have
> to use (because of lack of javascript in w3m), is firefox. You never
> leave emacs! Heresy! And of course, there's a configuration of firefox
> giving you emacs key bindings. Which is not the case of Safari or IE
> (AFAIK).
>
Do you know Conkeror ? It's a good alternative to Firefox :
* based on xulrunner.
* Emacs keybindings.
* Easily programmable in javascript.
* Don't use your mouse !
Elena
wrote:
> What you don't understand, is that emacs is not a mere application
> running on MacOSX or on MS-Windows or on Linux.
>
> emacs is actually an operating system, with its own window manager, and
> it's own consistent user interface.
>
> It just happens that nobody makes the hardware to run the emacs OS
> anymore. It was the LispMachines. So it has to run as a virtual
> machine (ever since it was conceived, admitedly and regretably).
Come on, Pascal, this is a bit of a stretch. Emacs is an Emacs Lisp
interpreter, no more than that. I see your point though.
> When you run MS-Windows in a virtual machine on MacOSX, you don't
> complain that it doesn't respect the MacOSX User Interface Guidelines!
>
> And when you run MS-Windows in a virtual machine on Linux, you don't
> complain that it doesn't do things like normal unix applications!
If I were to use an application on a virtual machine heavily, I would
look for ways to shape the hosted environment like the hosting one. I
run Windows at work, Linux at home, and I strive to get a consistent
environment. Luckily, Gnome shares the same idea about CUA.
>
> Same here.
>
> http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
Very nice attempt ^_^
I like the idea of Eshell as shell. I'll give it a spin.
> Now, for example, I don't like the MS-Windows system, so I don't use it.
> If you don't like the emacs system, you can just forget it and don't use
> it ever.
No, Pascal. Real world is different. I don't like the MS-Windows
system, but I make a living out of it, thus I'm using it. I think
Emacs has warts, but there's nothing better out there, therefore I
work around them.
> > I think an easy solution exists. First, here is a one liner for each
> > binding:
>
> This is something for you to do, not for the reference distribution of
> emacs.
Why? Novices are more likely to flock to the reference distribution,
thus it would be better if helpful directions were given there.
> And as I mentionned, it's free software, you are even free to make your
> own distribution of emacs.
That's never going to happen. I dislike distributions. IMO, they
either show a weakness into the extendibility of a system or a
weakness into the supporting community.
> > I've answered already I agree on this. I think the only fix to this
> > is a preamble to Emacs' manual.
>
> What could be added in the preamble if it's not already there, is what
> all emacser knows very well even if it's not often mentionned in public,
> is that emacs is an OS running on a VM, and it would be nice if Intel,
> AMD, or some other founder woud make a LispMachine processor again.
> With some microprogramming, it could even be made to run as well
> LispMachine microcode as JVM as a few others similar 'V'Ms.
If Lispers teamed up to make Lisp Machines a worthwhile platform,
manufacturers would resurrect Lisp machines, no doubt. This is never
going to happen, however, since Lispers seem more worried about their
keybindings than about - God forbid! - Lisp becoming mainstream.
Nothing wrong with that, mind you. Just let's not kid ourselves
things are different.
> > What about having different starting points users can improve on? At
> > least for keybindings, we are already there: there are vanilla Emacs,
> > vanilla Emacs + CUA, Viper + Vimpulse, ErgoEmacs...
>
> Why don't you try Emacs.app or Aquamacs.app?
Because they are not GNU Emacs.
Pascal J. Bourguignon
> On Nov 8, 1:40 pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> What you don't understand, is that emacs is not a mere application
>> running on MacOSX or on MS-Windows or on Linux.
>>
>> emacs is actually an operating system, with its own window manager, and
>> it's own consistent user interface.
>>
>> It just happens that nobody makes the hardware to run the emacs OS
>> anymore. It was the LispMachines. So it has to run as a virtual
>> machine (ever since it was conceived, admitedly and regretably).
>
> Come on, Pascal, this is a bit of a stretch. Emacs is an Emacs Lisp
> interpreter, no more than that. I see your point though.
Study the history!
>> When you run MS-Windows in a virtual machine on MacOSX, you don't
>> complain that it doesn't respect the MacOSX User Interface Guidelines!
>>
>> And when you run MS-Windows in a virtual machine on Linux, you don't
>> complain that it doesn't do things like normal unix applications!
>
> If I were to use an application on a virtual machine heavily, I would
> look for ways to shape the hosted environment like the hosting one. I
> run Windows at work, Linux at home, and I strive to get a consistent
> environment. Luckily, Gnome shares the same idea about CUA.
You should strive to make MS-Windows more like emacs.
> Why? Novices are more likely to flock to the reference distribution,
> thus it would be better if helpful directions were given there.
Depend on the novice. I would have been the kind of novice who would
have used the reference distribution, to be sure to be learning the true
emacs way, as a long-term investment. I would hate to learn emacs with
some massacred keybinding, that I would have to relearn once I switch to
the real thing.
>> Why don't you try Emacs.app or Aquamacs.app?
>
> Because they are not GNU Emacs.
Yes, they are. Emacs.app compiles directly from gnu sources.
And aquamacs is basically gnu emacs, with a custom site-start.el
Elena
wrote:
> > Come on, Pascal, this is a bit of a stretch. Emacs is an Emacs Lisp
> > interpreter, no more than that. I see your point though.
>
> Study the history!
I did already: "But, along the way, I wrote a ***text editor***,
Emacs." http://www.gnu.org/gnu/rms-lisp.html
> > If I were to use an application on a virtual machine heavily, I would
> > look for ways to shape the hosted environment like the hosting one. I
> > run Windows at work, Linux at home, and I strive to get a consistent
> > environment. Luckily, Gnome shares the same idea about CUA.
>
> You should strive to make MS-Windows more like emacs.
Indeed I could. However, the other way around is easier. If I were
to make MSW behave like some editor, I would prefer it Vi-like.
> > Why? Novices are more likely to flock to the reference distribution,
> > thus it would be better if helpful directions were given there.
>
> Depend on the novice. I would have been the kind of novice who would
> have used the reference distribution, to be sure to be learning the true
> emacs way, as a long-term investment. I would hate to learn emacs with
> some massacred keybinding, that I would have to relearn once I switch to
> the real thing.
You would not: "GNU Emacs is an extensible, ***customizable*** text
editor...". Once you have learned it, customizing it is a breeze.
The hurdle is learning it, that's why novices should have it easier
(without hurting power users).
> >> Why don't you try Emacs.app or Aquamacs.app?
>
> > Because they are not GNU Emacs.
>
> Yes, they are. Emacs.app compiles directly from gnu sources.
> And aquamacs is basically gnu emacs, with a custom site-start.el
You just said the opposite a few lines above ^_^
Mark Wooding
> On Nov 8, 1:40 pm, p...@informatimago.com (Pascal J. Bourguignon)
> > It just happens that nobody makes the hardware to run the emacs OS
> > anymore. It was the LispMachines. So it has to run as a virtual
> > machine (ever since it was conceived, admitedly and regretably).
>
> Come on, Pascal, this is a bit of a stretch. Emacs is an Emacs Lisp
> interpreter, no more than that. I see your point though.
It a slight stretch because Emacs predated the Lisp machines: it ran
first on ITS, and next (I think) on Multics. But the Lisp machine
versions, EINE and ZWEI were highly influential.
> > When you run MS-Windows in a virtual machine on MacOSX, you don't
> > complain that it doesn't respect the MacOSX User Interface Guidelines!
> >
> > And when you run MS-Windows in a virtual machine on Linux, you don't
> > complain that it doesn't do things like normal unix applications!
>
> If I were to use an application on a virtual machine heavily, I would
> look for ways to shape the hosted environment like the hosting one.
I think that's a serious mistake. Firstly, tools inevitably come with a
preconceived notion about how they're meant to be used: trying to use
them otherwise is often difficult, requiring more skill and knowledge
than you'd need if you conformed to the tools' worldview; and more
likely than not prevents you from using the tools to their fullest
potential. Secondly, it blurs the boundaries between things which are
best kept separate: a virtual machine is distinct from its host, and if
you don't keep that in mind, you will get a nasty surprise when you come
across one of the essential differences.
> I run Windows at work, Linux at home, and I strive to get a consistent
> environment. Luckily, Gnome shares the same idea about CUA.
I always thought that adopting conventions from Windows was a mistake in
Gnome. In particular, they missed an opportunity to popularize Emacs
keybindings and conventions. (Why should we have a clipboard when we
could have a kill ring?)
> > Now, for example, I don't like the MS-Windows system, so I don't use
> > it. If you don't like the emacs system, you can just forget it and
> > don't use it ever.
>
> No, Pascal. Real world is different. I don't like the MS-Windows
> system, but I make a living out of it, thus I'm using it.
You get to choose how you make a living. Besides, if you dislike it so
much, why are you trying to make Emacs mould itself to the Windows way
of working rather than the other way around? ;-)
> Why? Novices are more likely to flock to the reference distribution,
> thus it would be better if helpful directions were given there.
Why is it good that novices flock to anything? Popularity and quality
aren't well correlated. Windows is awful: much of the awfulness is
actually because it's trying to meet the requirements of an enormous
number of unskilled users.
> If Lispers teamed up to make Lisp Machines a worthwhile platform,
> manufacturers would resurrect Lisp machines, no doubt. This is never
> going to happen, however, since Lispers seem more worried about their
> keybindings than about - God forbid! - Lisp becoming mainstream.
I think becoming mainstream would be one of the worst things that could
possibly happen to Lisp! All the people who currently can only write
Java because they're copying `design patterns' out of a book, trying to
use Lisp? Ugh.
> > Why don't you try Emacs.app or Aquamacs.app?
>
> Because they are not GNU Emacs.
Neither is cua-mode.
-- [mdw]
Pascal J. Bourguignon
> Elena <egar...@gmail.com> writes:
>
>> On Nov 8, 1:40�pm, p...@informatimago.com (Pascal J. Bourguignon)
>> > It just happens that nobody makes the hardware to run the emacs OS
>> > anymore. �It was the LispMachines. �So it has to run as a virtual
>> > machine (ever since it was conceived, admitedly and regretably).
>>
>> Come on, Pascal, this is a bit of a stretch. Emacs is an Emacs Lisp
>> interpreter, no more than that. I see your point though.
>
> It a slight stretch because Emacs predated the Lisp machines: it ran
> first on ITS, and next (I think) on Multics. But the Lisp machine
> versions, EINE and ZWEI were highly influential.
AN emacs predated the Lisp machines.
But GNU emacs was started after the experience RMS had with Lisp
machines.
>> If I were to use an application on a virtual machine heavily, I would
>> look for ways to shape the hosted environment like the hosting one.
>
> I think that's a serious mistake. Firstly, tools inevitably come with a
> preconceived notion about how they're meant to be used: trying to use
> them otherwise is often difficult, requiring more skill and knowledge
> than you'd need if you conformed to the tools' worldview; and more
> likely than not prevents you from using the tools to their fullest
> potential. Secondly, it blurs the boundaries between things which are
> best kept separate: a virtual machine is distinct from its host, and if
> you don't keep that in mind, you will get a nasty surprise when you come
> across one of the essential differences.
Indeed.
>> I run Windows at work, Linux at home, and I strive to get a consistent
>> environment. Luckily, Gnome shares the same idea about CUA.
>
> I always thought that adopting conventions from Windows was a mistake in
> Gnome. In particular, they missed an opportunity to popularize Emacs
> keybindings and conventions. (Why should we have a clipboard when we
> could have a kill ring?)
And as an alternative, you can run X on all these systems, and use emacs
X11 on all of them, with exactly the same user interface, down to the
key bindings.
Or, you could run a MS-Windows in a VM and with vnc have the MS-Windows
experience on either Linux or MacOSX.
Unfortunately, for the MacOSX experience, you will have to buy a
Macintosh, but otherwise, you can do similarly.
>> No, Pascal. Real world is different. I don't like the MS-Windows
>> system, but I make a living out of it, thus I'm using it.
>
> You get to choose how you make a living. Besides, if you dislike it so
> much, why are you trying to make Emacs mould itself to the Windows way
> of working rather than the other way around? ;-)
>
>> Why? Novices are more likely to flock to the reference distribution,
>> thus it would be better if helpful directions were given there.
>
> Why is it good that novices flock to anything? Popularity and quality
> aren't well correlated. Windows is awful: much of the awfulness is
> actually because it's trying to meet the requirements of an enormous
> number of unskilled users.
This must be repeated.
"Much of the awfulness is actually because it's trying to meet the
requirements of an enormous number of unskilled users."
>> If Lispers teamed up to make Lisp Machines a worthwhile platform,
>> manufacturers would resurrect Lisp machines, no doubt. This is never
>> going to happen, however, since Lispers seem more worried about their
>> keybindings than about - God forbid! - Lisp becoming mainstream.
>
> I think becoming mainstream would be one of the worst things that could
> possibly happen to Lisp! All the people who currently can only write
> Java because they're copying `design patterns' out of a book, trying to
> use Lisp? Ugh.
>
>> > Why don't you try Emacs.app or Aquamacs.app?
>>
>> Because they are not GNU Emacs.
>
> Neither is cua-mode.
>
> -- [mdw]
--
Richard Kettlewell
> Pascal J. Bourguignon wrote:
>> Why don't you try Emacs.app or Aquamacs.app?
> Because they are not GNU Emacs.
The Emacs.app project was merged into GNU Emacs some time ago.
Consequently the Emacs.app application now builds directly from
unmodified GNU sources. (There are binary downloads available too.) If
it's not GNU Emacs then I 'm not sure what is.
Elena
> > If I were to use an application on a virtual machine heavily, I would
> > look for ways to shape the hosted environment like the hosting one.
>
> I think that's a serious mistake. Firstly, tools inevitably come with a
> preconceived notion about how they're meant to be used: trying to use
> them otherwise is often difficult, requiring more skill and knowledge
> than you'd need if you conformed to the tools' worldview; and more
> likely than not prevents you from using the tools to their fullest
> potential.
I don't understand how this relates to keybindings. Binding "C-c" for
yanking and remapping "C-c" prefix to something else, in my opinion
doesn't make Emacs any less powerful. It seems I'm the only Emacs
user here which doesn't bind Emacs' power to its keybindings.
> Secondly, it blurs the boundaries between things which are
> best kept separate: a virtual machine is distinct from its host, and if
> you don't keep that in mind, you will get a nasty surprise when you come
> across one of the essential differences.
Yeah, I know the Law of Leaky abstractions. I got such a nasty
surprise when I tried SSHing from Emacs on Windows.
> > I run Windows at work, Linux at home, and I strive to get a consistent
> > environment. Luckily, Gnome shares the same idea about CUA.
>
> I always thought that adopting conventions from Windows was a mistake in
> Gnome. In particular, they missed an opportunity to popularize Emacs
> keybindings and conventions. (Why should we have a clipboard when we
> could have a kill ring?)
And why should we have a kill ring when we could have both? I think
the real mistake is not giving users choice. Do they like Emacs'
bindings? Let them have their way. Do they like CUA? Let them have
their way.
> > > Now, for example, I don't like the MS-Windows system, so I don't use
> > > it. If you don't like the emacs system, you can just forget it and
> > > don't use it ever.
>
> > No, Pascal. Real world is different. I don't like the MS-Windows
> > system, but I make a living out of it, thus I'm using it.
>
> You get to choose how you make a living.
Where there's muck there's brass, they say.
> Besides, if you dislike it so
> much, why are you trying to make Emacs mould itself to the Windows way
> of working rather than the other way around? ;-)
Because it's more practical to mold a single application than a ton of
applications on two operating systems, you know. Moreover, as I've
stated already, I'm not fussy about keybindings, provided they stay
the same across applications. Have I told enough times that I prefer
modal over modeless editing? Yeah, it has its learning curve, but
it's totally worth the effort. I fail to be mesmerized by the
empowerment of using "C-y" instead of "C-c", though.
> > Why? Novices are more likely to flock to the reference distribution,
> > thus it would be better if helpful directions were given there.
>
> Why is it good that novices flock to anything? Popularity and quality
> aren't well correlated.
They aren't always uncorrelated, either.
> Windows is awful: much of the awfulness is
> actually because it's trying to meet the requirements of an enormous
> number of unskilled users.
Windows has more merits than you think. You have to see through the
skin.
> > If Lispers teamed up to make Lisp Machines a worthwhile platform,
> > manufacturers would resurrect Lisp machines, no doubt. This is never
> > going to happen, however, since Lispers seem more worried about their
> > keybindings than about - God forbid! - Lisp becoming mainstream.
>
> I think becoming mainstream would be one of the worst things that could
> possibly happen to Lisp!
Yeah, maybe because then all of its shortcomings would become
blindingly clear ^_^
Moreover, companies could jump at the opportunity of building Lisp
machines again, and that would be awful indeed, wouldn't it? We love
the Intel platform so much, don't we?
> All the people who currently can only write
> Java because they're copying `design patterns' out of a book, trying to
> use Lisp? Ugh.
We can bitch about Java how much we want, but being mainstream has
made the JVM the most stable and performant VM out there.
Tim Bradshaw
> It a slight stretch because Emacs predated the Lisp machines: it ran
> first on ITS, and next (I think) on Multics. But the Lisp machine
> versions, EINE and ZWEI were highly influential.
I'm pretty sure that EINE was the first Emacs whose implementation
language was Lisp - the older ones were (all?) TECO-based. And EINE I
assume ran on the CONS or the CADR?
Tim Bradshaw
> Moreover, companies could jump at the opportunity of building Lisp
> machines again, and that would be awful indeed, wouldn't it? We love
> the Intel platform so much, don't we?
I don't love Intel systems, but it's really quite important to avoid
the romanticisation of Lisp machines (which is unfortunately prevelant
on CLL as I expect followups to this article will now demonstrate).
Elena
> We can bitch about Java how much we want, but being mainstream has
> made the JVM the most stable and performant VM out there.
Not to mention how rich the Java SDK API is and how much battle-tested
the Java platform as a whole is. But we would hate having these
features into our Lisp systems, wouldn't we? Much more fun hunting
for libraries and scavenging for scraps of code.
Mark Wooding
> I'm pretty sure that EINE was the first Emacs whose implementation language
> was Lisp - the older ones were (all?) TECO-based. And EINE I assume ran on
> the CONS or the CADR?
Hmm. According to http://www.multicians.org/mepap.html, Multics Emacs
was implemented in Multics MacLisp; implementation started in March
1978. Wikipedia says that Weinreb's thesis on EINE was published in
January 1979. The Emacs wiki page on Multics Emacs
(http://www.emacswiki.org/emacs/MulticsEmacs) says that it was the first
to use Lisp as an extension language.
I think this is close one to call.
-- [mdw]
Espen Vestre
> I'm pretty sure that EINE was the first Emacs whose implementation
> language was Lisp - the older ones were (all?) TECO-based. And EINE I
> assume ran on the CONS or the CADR?
FINE (Fine Is Not Emacs), which was one of the first Emacsen I used (in
1981 or -82), was written in BLISS-10, which I guess was a quite common
language back then.
Just googled it up, and it is still available here:
ftp://ftp.ultimate.com/pdp10/fine/
--
(espen)
Pascal J. Bourguignon
> We can bitch about Java how much we want, but being mainstream has
> made the JVM the most stable and performant VM out there.
Isn't it what we would want for Lisp?
Elena
wrote:
> Isn't it what we would want for Lisp?
Exactly. We ***would want***, not we ***want***.
Tim Bradshaw
> Isn't it what we would want for Lisp?
I suspect it's not. The JVM may be universal and all but how many
instances of it are running on your machine right now? I checked my
laptop and the answer is 0 (and I write stuff in Java relatively
frequently).
So, well, Java's failed on the desktop/laptop, I guess we know that.
For servers, well, there's a lot of it about of course, but it seems to
me that virtualised x86 systems are now so common that you would not
lose much by just targetting x86 (and of course we have a load of good
x86-targetting CL systems).
I suppose the argument might be that you get all the good libraries
that come with the JVM, and that might be a good argument, so long as
the impedance mismatch from Lisp is not too high.
(And I guess another important market is going to be Android, which is
at least Javaoid).
Elena
> So, well, Java's failed on the desktop/laptop, I guess we know that.
> For servers, well, there's a lot of it about of course, but it seems to
> me that virtualised x86 systems are now so common that you would not
> lose much by just targetting x86 (and of course we have a load of good
> x86-targetting CL systems).
>
> I suppose the argument might be that you get all the good libraries
> that come with the JVM, and that might be a good argument, so long as
> the impedance mismatch from Lisp is not too high.
>
> (And I guess another important market is going to be Android, which is
> at least Javaoid).
Oh, I wish CL had failed like Java did ;-)
Tim Bradshaw
> Oh, I wish CL had failed like Java did ;-)
On the desktop, it did. And, actually, I wouldn't wish Java's fate on CL
TheFlyingDutchman
> On 2010-11-11 16:43:13 +0000, Elena said:
>
> > Oh, I wish CL had failed like Java did ;-)
>
> On the desktop, it did.
If Java failed on the desktop, what has Common Lisp done on the
desktop?
> And, actually, I wouldn't wish Java's fate on CL
You wouldn't want Common Lisp #1 on the Tiobe index?
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Elena
> The JVM may be universal and all but how many
> instances of it are running on your machine right now? I checked my
> laptop and the answer is 0 (and I write stuff in Java relatively
> frequently).
How do you know? Java applications can be packaged in a native
executable (Eclipse comes to mind). They can even "disguise"
themselves by using native GUIs (again, Eclipse comes to mind).
Tim Bradshaw
> If Java failed on the desktop, what has Common Lisp done on the
> desktop?
Failed, as I said.
>
>> And, actually, I wouldn't wish Java's fate on CL
>
> You wouldn't want Common Lisp #1 on the Tiobe index?
No.
Tim Bradshaw
> How do you know? Java applications can be packaged in a native
> executable (Eclipse comes to mind). They can even "disguise"
> themselves by using native GUIs (again, Eclipse comes to mind).
I'm reasonably sure.
TheFlyingDutchman
>
> If Java failed on the desktop
Java is not being used to write most commercial apps like Quicken or
mainstream free apps like browsers or OpenOffice. I believe those are
almost all C++. But I don't think it has failed on the desktop for
internal apps inside corporations. At least I have seen it being used
to write corporate desktop business and scientific GUI apps.
Developers appear to find it easier to use than C++ on Windows with
MFC or C++ on Unix with Motif. However, there are newer GUI library
alternatives, most notably QT, with increased functionality and ease
of use over Motif/MFC, and that may be influencing corporate GUI
desktop app development to the benefit of C++.
Thomas A. Russ
> Java is not being used to write most commercial apps like Quicken or
> mainstream free apps like browsers or OpenOffice.
Incorrect for OpenOffice. That is a Java project.
--
Thomas A. Russ, USC/Information Sciences Institute
TheFlyingDutchman
> > Java is not being used to write most commercial apps like Quicken or
> > mainstream free apps like browsers or OpenOffice.
>
> Incorrect for OpenOffice. That is a Java project.
>
I thought Eclipse was slow but that OpenOffice - "another Java app" -
seemed to have good performance. But when I later looked to verify it
was a Java app I found out it is not a Java project:
http://contributing.openoffice.org/programming.html
Contribute to a core module
Core components are written in C++. If you know C++ you can start by
finding the project or component that interests you. Join that
project's mailing list and introduce yourself. You will probably need
to familiarize yourself with the Developers Guide.
TheFlyingDutchman
http://wiki.services.openoffice.org/wiki/Java_and_OpenOffice.org
Java and OpenOffice.org
Java is required for complete OpenOffice.org functionality. Java is
mainly required to use the new embedded Java technology based HSQLDB
database engine, or to make use of accessibility and assistive
technologies. If you do not require database tables or accessibility
integration or some wizards, then you do not need to download and
install Java. Base (the database component) for example completely
relies on Java technologies to run, but other programs (like Writer,
Calc, and Impress) only need Java for special functionality (see
below).