A new project on emacs, here:
http://code.google.com/p/emacs2010/
For some detail, see:
http://code.google.com/p/emacs2010/wiki/DeveloperIntro
Hope you can join in. Thanks.
Here's a plain text version of the plan
----------------------------
=Plan=
The goal is to have a downloadable binary for Windows, Mac (and
possibly Linux too later).
This binary, will have init file somewhere that loads a bunch of elisp
files. These elisp files over-ride the emacs default behavior.
For any existing emacs installation, people should be able to load the
emacs2 files and have the emacs2 behavior.
The plan is subject to minor change depending on how things go. The
project is gonna be do-oriented. Don't want to plan too much and do
nothing.
===Summary===
• *Goal*: Average programer download emacs, use it, happy. They don't
have to suffer some “emacs way”. Emacs's power, is *fully* retained,
however.
• *Method*: simple few elisp files in a folder emacs2 that over-ride
emacs's defaults. The project should be entirely compatible with GNU
emacs's latest release. The elisp code must not be complex. Most will
just be turning on a existing emacs feature, changing a keyboard
shortcut, or removing a menu or providing some other elisp commands.
No change whatsoever is to the elisp system.
• *Emacs based modernization*. Any change, is based on emacs
operation. There will not be such things as pop-up dialogues (as in
AquaEmacs, Carbon Emacs), opening every file in new window
(AquaEmacs), having the Alt key popup menus as in (EmacsW32). The
“modernization” is just to get rid of emacs's 1980's terminologies,
keybindings, doc writings.
== Items to change ==
Here's explicit detail of items to change. List roughly from most
important to less. The importance is roughly based on the ratio
“impact” over “ease of fix”.
• Update emacs default keybinding. *Done*. For detail, see: [Why
Emacs's Keyboard Shortcuts Are Painful] and [ergoemacs]
• Have Z X C V as default shortcut for undo, cut, copy, paste. *Done*.
Use CUA-mode. Just need to turn it on. The undo shortcut is not in CUA
mode, but in [ergoemacs].
• Have text selection highlight. *Done*. Just need to turn on cua mode
or transient-mark-mode. (transient-mark-mode is on in emacs 23.)
• Have up/down arrow move by visual line. *Done*. (emacs 23 does this
by default)
• change undo and redo to behave like modern applications. *Done*.
(just include redo mode. Though, technically the redo mode has some
problems. It sometimes corrupt undo record or behave bad, and does not
attempt to get rid of emacs's undo of undos. However, redo mode is
considered good enough for emacs2.)
For some detailed rationale, see: [The Modernization of Emacs]
• Support minimum of standard shortcut set, for open, close, save,
save as, new, print, select all. *Done*. Part of [ergoemacs].
• Remove some menu items that are redundant, never used, out dated.
For example: games, psycho-therapist, 4 menus on one-time search
that's not used by anyone, lots of items under Help that are outdated
info and FSF propaganda. Only menu items that most useful should
remain (e.g. by usage statistics).
Mostly *Done*. See clean_menus.el in emacs2 bundle.
• Replace the abbreviations C-‹key› and M-‹key› by Ctrl+‹key› and Alt
+‹key› in all menus and inline doc. Should not be difficult. Look into
how describe-function's source.
• Replace all in Emacs manual's “Meta key” to “Alt key”. Basically,
replace only display issues and terminology visible for user. The
elisp system and its manual, will stick with (kbd "M-x") etc
notations. Because such change would be practically not workable, it
requires large rewrite of emacs. The logical basis of consistency
after the change is easy: emacs uses Alt. For historically reasons,
they are called Meta in elisp docs. (for some detail see
[Why Emacs's Keyboard Shortcuts Are Painful] and [Emacs's M-‹key›
Notation vs Alt+‹key› Notation]
)
This manual change should be trivial to do. I can do in few hours.
• in emacs manual, change the terminology of kill to cut, yank to
paste. Throughout. Easy to fix.
• in emacs manual, change the terminology of keybinding to keyboard
shortcut. Only when discussing “assign a shortcut” for programing
emacs contexts (read by programers), then use binding or keybinding.
Easy to fix.
• in emacs manual, switch the terminology of Window and Frame. Takes
some diligence to fix this correctly. The logic after this change is
this: for elisp coders or power users, they will learn than underneath
the terms window and frame are switched in elisp, because of
historical reasons. For most users who are not coding elisp, they
wouldn't need to know this terminology switch. To them, a window is
just a window like in every other app.
• fix emacs mode line. [Emacs's Mode Line Modernization Suggestions]
Probably not too difficult. Need to look into how mode line works.
• Get rid of the “scratch” buffer. Not trivial. Detail: [Suggestions
on Emacs's Scratch Buffer].
==less important==
the following are less important, their ratio of “impact”/“ease to
fix” is low.
• fix emacs letter case change commands. *Done*. Code in ergoemacs.
[Usability Problems With Emacs's Letter-Case Commands]
• Fix emacs's mark-word commands. Partially done. [Suggestions on
Emacs's mark-word Command]. The plan is that this a kbd shortcut
should progressively select larger semantic unit. [Extend Selection
By Semantic Unit]
• Fix emacs's fill- commands. See [Suggestions on Emacs's Line-
Cutting Commands]. The plan is that user should just press a button to
invoke a fill- command that automtically format the current semantic
unit. A semantic unit can be paragraph of english as done by fill-
paragraph, or can be code block, typically C-like lang's {} or
function definition, or delimited by two newline chars. For some
detail on how this would work for lisp code, see: [A Simple Lisp Code
Formatter]. For lisp code, this is currently in the works by Andy
Stewart.
• elisp's describe-function should work in all languages, not just
lisp. If the lang's doc does not come in info format, send user to
browser with pertinent url. Partially done. See: [Dictionary and
Reference Lookup with Emacs]
===small items==
• elisp-index-search should use current word for prompt. *Done* See:
[Suggestions on Emacs's Inline Doc]
• describe-function should include some links. See: [Suggestions on
Emacs's Inline Doc]
• Change Meta+Tab for command name completion to some other key. The
meta is alt, and alt+tab is used by windows, mac, linux for switching
apps. The fix is a bit tricky. When done, this should be part of the
ergoemacs file.
• change meta+tab in describe-function's result buffer to shift-tab,
for moving to the previous link. Because meta+tab is used by all 3
major OS to switch app. The fix is a bit tricky. When done, this
should be part of the ergoemacs file.
==Remote Future Plans==
Here are more items, they are in general just fancy thinking. Listed
here only as a record for communication of general ideas for this
project.
• Something urgently needs to be done with emacs html mode. This is a
MAJOR need, however, the fix is very difficult. See [Emacs's HTML Mode
Sucks]. nxhtml and nxml modes are currently work in progress by emacs
dev, good luck to them.
• Reduce emacs documentation by at least 1/3 of its bulk. Remove all
things modern users already know, such as concepts of copy, cut,
paste, paste board, opening files... etc. e.g. remove or reduce manual
nodes on: Basic, Minibuffer, M-x, Help, Mark, Killing, Yanking,
Accumulating Text, Major Modes, Indentation, Text, ... just about
every node in emacs manual. Most of them can be replaced with one
single paragraph, and possibly another single paragraph on tech detail
when appropriate (such as command name, elisp code, things having to
do with the emacs system).
• provide interface to gmail, yahoo, msn mail. (kinda as a replacement
of rmail's role in emacs) Also provide interface to google groups.
(can be added as part of gnus) Some detail here: [Emacs Should Support
HTML Mail].
These are modern ways. Nobody is using plain text clients today. Rmail
& gnus stays in emacs, of course, for those geekers.
• bundle e-blog and lj-update for easy update to google blogs and
livejournal. • possibly bundle nxhtml mode and quite a few others
really good ones and important, some of which are likely never to be
in GNU emacs due to author unwilling or other.
• relpace emacs doc from texinfo to html. A eventual ideal. [Emacs
Should Adopt HTML To Replace Texinfo].
Xah
∑ http://xahlee.org/
☄
Xah Lee <······@gmail.com> writes:
> • in emacs manual, switch the terminology of Window and Frame. Takes
> some diligence to fix this correctly. The logic after this change is
> this: for elisp coders or power users, they will learn than underneath
> the terms window and frame are switched in elisp, because of
> historical reasons. For most users who are not coding elisp, they
> wouldn't need to know this terminology switch. To them, a window is
> just a window like in every other app.
This will break as soon as a user runs describe-key on whatever key you
assign to `make-frame-command'. The underlying Emacs commands (and
their names) aren't just for Elisp programmers -- they are also part of
Emacs' extensive self-documentation. So if the user is looking at the
list of keybindings for a mode, or other documentation sources outside
the manual, they'll be looking at "switched" terminology.
One further minor point: if you do want to change terminology for
windows and frames, I think "pane" and "window" is better than just
switching "window" and "frame". Windows in real life are subdivided
into panes, so this usage strengthens the metaphor invoked by the terms.
- Michael
--
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files? I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.
Well, good luck with that. Though I believe you're fighting windmills...
Xah Lee escreveu:
> http://code.google.com/p/emacs2010/
> The goal is to have a downloadable binary for Windows, Mac (and
> possibly Linux too later).
That'll surely piss Stallman... ;)
> This binary, will have init file somewhere that loads a bunch of elisp
> files. These elisp files over-ride the emacs default behavior.
We all know that bunch of simple elisp files eventually become most of
emacs itself... at least as far as an extensible editor should permit...
> • *Goal*: Average programer download emacs, use it, happy. They don't
> have to suffer some “emacs way”. Emacs's power, is *fully* retained,
> however.
That is something to be seen.
> • Replace all in Emacs manual's “Meta key” to “Alt key”.
Ok, just please don't call this editor M-x anymore. ;)
> These are modern ways. Nobody is using plain text clients today.
I beg to differ.
On Feb 3, 10:33 am, namekuseijin <············@gmail.com> wrote:
> Well, good luck with that. Though I believe you're fighting windmills...
>
> Xah Lee escreveu:
>
> >http://code.google.com/p/emacs2010/
> > The goal is to have a downloadable binary for Windows, Mac (and
> > possibly Linux too later).
> > • *Goal*: Average programer download emacs, use it, happy. They don't
> > have to suffer some “emacs way”. Emacs's power, is *fully* retained,
> > however.
>
> That is something to be seen.
It already happened in a verifiable way: AquaEmacs. The “problem” with
AquaEmacs is that it's for Mac only, and Mac is only ~5% of personal
computers. AquaEmacs has become a success in mere a couple of years,
significant number of emacs users on the mac, uses AquaEmacs, if not
majority. If not for AquaEmacs, majority of these people would never
use emacs.
about 20 years ago, this also happened, with Lucid Emacs (aka Xemacs).
It almost killed GNU emacs, and it kick started GNU Emacs from
dozzing, and took GNU emacs about 15 years to catch up. (note: Lucid
Emacs is made by a commercial org during lisp era, with several
programers working on it full time for a number of years. Its change
and impact to emacs is a magnitude more than AquaEmacs. (AquaEmacs
mostly just changed some UI by patching a layer of elisp, and bundling
some elisp package in the wild. Xemacs had great focus on UI and
usability, but also made major improvement to elisp core... it is
politics that made Richard Stallman not to adopt or accept its elisp
changes, and rolled its own that took 5 or so years))
For some side history of lucid emacs, see the book:
• Book Review: Patterns of Software
http://xahlee.org/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html
----------------
I made some addition near the bottom about existing similar projects,
here:
http://code.google.com/p/emacs2010/wiki/DeveloperIntro
here's the excerpt:
-----------------------
About half of these ideas are officially communicated to gnu emacs's
dev thru emacs bug report system, in 2007, 2008. Almost all are either
placed on wish list, or dismissed as unimportant or unnecessary. Some
emacs 23 changes, such as moving up/down by visual line, and transient-
mark-mode on by default, might be influence by some of the essay
linked here. But overall, for many reasons good or bad, the above
ideas are likely to be slow in showing up in GNU Emacs.
If you think these are good ideas, either send in a “bug” report to
FSF in emacs thru the menu “Help ‣ Send Bug Report...”, or help
contribute here.
There are a number of existing similar projects.
• AquaEmacs is fantastic. However, it runs on Mac only, and some of
its Apple GUI behavior is not suitable for emacs. e.g. popping up
dialog boxes when user tries to open a file. Opening every file in its
own window (i.e. emacs's “frame”), launching Apple's Helper App when
pulling some help menu item. In the end, if you have used emacs in a
text terminal, AquaEmacs's ways can't be applicable.
• EmacsW32 is Emacs for Windows. It is great, but there are 2 major
problems: (1): the project is thought of as a emacs patch. So, users
doesn't just go there to download and run out of box. But has to read
a bunch of philosophy, how to install the patch, extra bundle, stuff.
Basically, you must already have spent perhaps months to become a
emacs insider to be able to find or use EmacsW32 much as a choice.
(2): The Alt key pops up the Window's menu. This is how app behaves in
MS Windows. This is great for Windows compatibility just as AquaEmacs
is great for Mac compatibility, but this operation is incompatible
with emacs's ways, where Meta is heavily used thus convenient to be at
the location of Alt key.
• Easymacs. This project is similar here, but Easymacs is again a
bunch of patchs, with complex info about how to install, philosophy,
manifesto, FAQ. This project seems also to be not maintained.
None of the above projects attempts to fix the emacs's keybinding
problem. (they assume either people are happ with the arrow keys or
Ctrl+arrow in most editors, or adopt the emacs bad keybinding) None
attepms to fix emacs's old terminology problem (AquaEmacs tries, by
writing its own Mac style docs launched in Apple's Help Application,
which function as layer that relies on top of GNU Emacs manual.)
One most critical aspect of ease of use is a brainless downloadable
binary. This is done for essentially EVERY major software (think of
all major browsers, every software released by Apple, every software
released by Microsoft, every gaming software, and every software
released for windows.) However, emacs, much with its unix history, has
the mentality that user is to compile the software himself.
Downloadable binary is maybe available for 1% of time, and when
available, often outdated or crash. The only exception to this, is the
Mac version of emacs (Carbon emacs and AquaEmacs), which is that way
due to the Mac culture. However, they only run on Mac. Some 95% of
computer users can't use emacs. (because Windows has ~95% market
share).
----------------------------------
For some notes about Xemacs, see:
• My Experience of Emacs vs XEmacs
http://xahlee.org/emacs/emacs_vs_xemacs.html
Xah
∑ http://xahlee.org/
☄
Xah Lee <······@gmail.com> writes:
> On Feb 3, 10:33 am, namekuseijin <············@gmail.com> wrote:
>> Well, good luck with that. Though I believe you're fighting windmills...
>>
>> Xah Lee escreveu:
>>
>> >http://code.google.com/p/emacs2010/
>> > The goal is to have a downloadable binary for Windows, Mac (and
>> > possibly Linux too later).
>
> It already happened in a verifiable way: AquaEmacs. The “problem” with
> AquaEmacs is that it's for Mac only, and Mac is only ~5% of personal
> computers. AquaEmacs has become a success in mere a couple of years,
> significant number of emacs users on the mac, uses AquaEmacs, if not
> majority.
Not a majority I guess.
> If not for AquaEmacs, majority of these people would never use emacs.
Probably: the AquaEmacs user interface idiosyncrasies don't appeal to
users with an Emacs workflow/mindframe. So the AquaEmacs audience will
tend to be additional to the Emacs audience.
> about 20 years ago, this also happened, with Lucid Emacs (aka Xemacs).
Different beasts. XEmacs was the successor of Lucid, in particular with
a different development model.
> It almost killed GNU emacs, and it kick started GNU Emacs from
> dozzing, and took GNU emacs about 15 years to catch up.
Come off it. GNU Emacs never was anywhere close to be killed. The
developers who went to XEmacs were developers not thrilled with the
prospect of working with Stallman. They would likely have stopped on
Emacs altogether anyway.
> Xemacs had great focus on UI and usability,
More on UI gizmos. But they often turn out unusable and/or
unprogrammable and/or non-working (try balloon-help-mode for a while:
there is a reason its default is off, while the equivalent on Emacs is
on).
> but also made major improvement to elisp core... it is politics that
> made Richard Stallman not to adopt or accept its elisp changes, and
> rolled its own that took 5 or so years))
Actually, there were more than one reason. The extent code was a mess
only its author could reasonably understand, and there was no intent to
change that, and the Lucid Emacs developers demanded control of
development.
You might call it "politics" that Stallman did not accept those
conditions. Whatever you want to call it, it was not entirely
arbitrary.
I think Jamie Zawinski has on his web page a large collection of
relevant postings about this from the Emacs developer list at that point
of time.
--
David Kastrup
> > If not for AquaEmacs, majority of these people would never use emacs.
>
> Probably: the AquaEmacs user interface idiosyncrasies don't appeal to
> users with an Emacs workflow/mindframe.
I'm not so sure about that. Many LaTeX/AUCTeX users in academia have
switched to Aquamacs from Emacs. I've been an Emacs users for 15 years
or so, and I now use Aquamacs exclusively. Rich Hickey's Clojure demos
are all given using Aquamacs, and I suspect he's used Emacs
before :-).
antirealist <···········@gmail.com> writes:
>> > If not for AquaEmacs, majority of these people would never use
>> > emacs.
>>
>> Probably: the AquaEmacs user interface idiosyncrasies don't appeal to
>> users with an Emacs workflow/mindframe.
>
> I'm not so sure about that. Many LaTeX/AUCTeX users in academia have
> switched to Aquamacs from Emacs.
I don't think that the statement "academic aquamacs users use an Emacs
workflow / have an Emacs mindframe" is true for all academic users. I
think it's not even true for most of them.
I know some colleagues that own a mac and run aquamacs, but they are far
from using it as effectively as they could. For example, some of them
use the mouse (wheel) for scrolling and moving point! Can you believe
it?!?
My hypothesis is: Because aquamacs makes emacs comparable to other mac
editors (UI-wise) most users don't explore the things that can make
emacs very effective.
Bye,
Tassilo
Tassilo Horn escreveu:
> antirealist <···········@gmail.com> writes:
>
>>>> If not for AquaEmacs, majority of these people would never use
>>>> emacs.
>>> Probably: the AquaEmacs user interface idiosyncrasies don't appeal to
>>> users with an Emacs workflow/mindframe.
>> I'm not so sure about that. Many LaTeX/AUCTeX users in academia have
>> switched to Aquamacs from Emacs.
>
> I don't think that the statement "academic aquamacs users use an Emacs
> workflow / have an Emacs mindframe" is true for all academic users. I
> think it's not even true for most of them.
>
> I know some colleagues that own a mac and run aquamacs, but they are far
> from using it as effectively as they could. For example, some of them
> use the mouse (wheel) for scrolling and moving point! Can you believe
> it?!?
>
> My hypothesis is: Because aquamacs makes emacs comparable to other mac
> editors (UI-wise) most users don't explore the things that can make
> emacs very effective.
You nailed it.
Indeed GUI users with the notepad mentality will always subutilize both
emacs and vim. That's why I see no point in giving these editors a
familiar face and current standard keybindings among GUI systems: it's
like attaching tentacles to a dog and calling it a squid.
Emacs and vim are alien technology and you either explore and learn
their way it or use notepad and similars. Going all the effort just so
that new users can get a chance to subutilize emacs as if it was notepad
is not worth it, IMO.
namekuseijin <············@gmail.com> writes:
> Tassilo Horn escreveu:
> > antirealist <···········@gmail.com> writes:
> >
> >>> Probably: the AquaEmacs user interface idiosyncrasies don't appeal to
> >>> users with an Emacs workflow/mindframe.
I would disagree. I happily use AquaMacs and undoubtedly qualify as
having an Emacs mindframe. I've only been using Emacs for about 30
years now.
> > I know some colleagues that own a mac and run aquamacs, but they are
> > far from using it as effectively as they could. For example, some
> > of them use the mouse (wheel) for scrolling and moving point! Can
> > you believe it?!?
Well, I'll assume you mean that in jest.
The mouse wheel is certainly easier for scrolling than the middle button
on the mouse in the scroll bars on X windows.
> > My hypothesis is: Because aquamacs makes emacs comparable to other mac
> > editors (UI-wise) most users don't explore the things that can make
> > emacs very effective.
Well, it also has the benefit of allowing one to use Emacs in a more
natural environment when using a number of other different
applications. In particular, I find that not having to switch "modes"
during cut-and-paste between Emacs and other applications is a big
cognitive win.
> You nailed it.
>
> Indeed GUI users with the notepad mentality will always subutilize both
> emacs and vim. That's why I see no point in giving these editors a
> familiar face and current standard keybindings among GUI systems: it's
> like attaching tentacles to a dog and calling it a squid.
>
> Emacs and vim are alien technology and you either explore and learn
> their way it or use notepad and similars. Going all the effort just so
> that new users can get a chance to subutilize emacs as if it was notepad
> is not worth it, IMO.
Well, some alignment with both worlds makes it a lot easier to work with
multiple applications productively. One of the nice benefits of
AquaMacs (or indeed Emacs on Macs at all) is that none of the
traditional Emacs commands make use of the Command key. So the
integration with the Macintosh conventions is fairly seemless for the
major key commands. Command-V for paste doesn't at all interfere with
Control-V for scrolling. ;-)
Now, if there were a nice way to integrate Emacs with Eclipse* or (even
better) Netbeans, that would be grand. Their keybinding hacks are too
limited and only mislead Emacs users into thinking they can use more
features than are actually present.
* There used to be an Eclipse plugin, but it doesn't seem to be
maintained anymore. Sigh.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
>> > I know some colleagues that own a mac and run aquamacs, but they
>> > are far from using it as effectively as they could. For example,
>> > some of them use the mouse (wheel) for scrolling and moving point!
>> > Can you believe it?!?
>
> Well, I'll assume you mean that in jest.
No, not at all. You almost never want to scroll without knowing what
you're looking for. And then `isearch' will bring you there within a
second. When you don't know what you're looking for, C-v and M-v are
still much faster than switching to the mouse.
> The mouse wheel is certainly easier for scrolling than the middle button
> on the mouse in the scroll bars on X windows.
Sure, scrollbars are even unemacsier than mouse wheels.
>> > My hypothesis is: Because aquamacs makes emacs comparable to other
>> > mac editors (UI-wise) most users don't explore the things that can
>> > make emacs very effective.
>
> Well, it also has the benefit of allowing one to use Emacs in a more
> natural environment when using a number of other different
> applications.
Using other applications is the first error. ;-)
> In particular, I find that not having to switch "modes" during
> cut-and-paste between Emacs and other applications is a big cognitive
> win.
If you emacs extensively you still have to switch modes, even when the
keybindings are equal, because the concepts are still different.
Killing and yanking is much more than cutting and pasting.
> One of the nice benefits of AquaMacs (or indeed Emacs on Macs at all)
> is that none of the traditional Emacs commands make use of the Command
> key. So the integration with the Macintosh conventions is fairly
> seemless for the major key commands. Command-V for paste doesn't at
> all interfere with Control-V for scrolling. ;-)
That's nice indeed.
> Now, if there were a nice way to integrate Emacs with Eclipse* or
> (even better) Netbeans, that would be grand. Their keybinding hacks
> are too limited and only mislead Emacs users into thinking they can
> use more features than are actually present.
That's so true...
Bye,
Tassilo
>>>>> namekuseijin <············@gmail.com> writes:
[...]
>> I know some colleagues that own a mac and run aquamacs, but they are
>> far from using it as effectively as they could. For example, some
>> of them use the mouse (wheel) for scrolling and moving point! Can
>> you believe it?!?
>> My hypothesis is: Because aquamacs makes emacs comparable to other
>> mac editors (UI-wise) most users don't explore the things that can
>> make emacs very effective.
> You nailed it.
> Indeed GUI users with the notepad mentality will always subutilize
> both emacs and vim. That's why I see no point in giving these
> editors a familiar face and current standard keybindings among GUI
> systems: it's like attaching tentacles to a dog and calling it a
> squid.
> Emacs and vim are alien technology and you either explore and learn
> their way it or use notepad and similars. Going all the effort just
> so that new users can get a chance to subutilize emacs as if it was
> notepad is not worth it, IMO.
Usually, I tend to agree with the statements like this.
However, when considering the ``cost'' of switching from Notepad
to Emacs versus switching from Emacs-used-as-notepad to Emacs,
the latter would be probably noticeable lower. Thus, it /may/
make a sense to provide a configuration which makes another dumb
text editor from Emacs, as the Emacs-like-notepad user will have
a little bit better chance into going into this ``alien
territory''.
Of course, it shouldn't be the first priority task. Neither
should it take too much effort to implement (luckily, Emacs is
quite flexible, isn't it?)
Surely, it shouldn't be advertized as an ``even better Emacs.''
--
FSF associate member #7257
In comp.emacs Xah Lee <······@gmail.com> wrote:
> A new project on emacs, here:
> http://code.google.com/p/emacs2010/
> For some detail, see:
> http://code.google.com/p/emacs2010/wiki/DeveloperIntro
> Hope you can join in. Thanks.
> Here's a plain text version of the plan
> ----------------------------
[ ~200 lines of explicit detail. ]
Excellent! Whilst I don't agree with your detailed proposals, I
sincerely wish you all success in this venture.
> Xah
--
Alan Mackenzie (Nuremberg, Germany).