From: Thomas Lord <lord@emf.net>
To: christian.lynbech@tieto.com
Cc: "bruce.stephens@isode.com" <bruce.stephens@isode.com>,
Christian Lynbech <christian@defun.dk>,
"rms@gnu.org" <rms@gnu.org>,
"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: Guile in Emacs
Date: Wed, 14 Apr 2010 12:07:05 -0700 [thread overview]
Message-ID: <1271272025.6576.49.camel@dell-desktop.example.com> (raw)
In-Reply-To: <ytqpaat6cz2f.fsf@tieto.com>
I really didn't mean to provoke a 20 message
thread about what was, to me, just an idle
thought and an interesting idea I wanted to share.
So, below I'll reply to Christian and I'll also
indirectly reply to some of the other messages -
but unless there is someone or are some people
who, right away, want to start working on a Scheme-based
Emacs - there is probably not a lot to discuss.
If there *is* a non-empty set of people who want
to work on it, they should speak up and we can try
to organize such an effort - the first step of which
would be to convene elsewhere besides this mailing
list.
Otherwise, the whole thing is just a (to me) pretty
thought that I wanted to share with others who might
like to put in the back of their minds and contemplate
it a bit, until perhaps someday when there is an
obvious course of action to take.
On Wed, 2010-04-14 at 08:45 +0200, christian.lynbech@tieto.com wrote:
> I am personally mostly worried about Thomas' points about
> getting scheme and emacs lisp to coexist. I just cannot
> see any evolution of emacs fly in the real world if it
> involves a clean cut away from the existing base
> of emacs lisp libraries. How we would ever get
> all developers and all users to back up such a move
> is beyond me ("all" used here in the sense
> of "enough to form a critical mass").
That's a legitimate concern but there are viable
solutions to the problem:
a) I'm *not* suggesting the idea of abandoning work
on the main development line of GNU Emacs. I would
expect that work to continue and to continue to use
Emacs lisp. There are so many GNU Emacs users and
the program generates such a large amount of good
will for GNU that it seems to me very desirable to
not "fix" what isn't broken.
b) I don't imagine that a Scheme-centric Emacs would
find itself with especially huge numbers of users in
its first few years of life. I would *guess* that what
would happen is that many people would try out the
first release just to see what the fuss was about, that
a much smaller number would stick with it, and that a
slightly smaller number of those initial users would become
contributing developers. My guess is based on the assumption
that the first release is any good.
If things went well in the first few years, then
the Scheme-based Emacs might start becoming seriously
popular.
c) Someone - I think it was Tom Tromey - observed
that Emacs Lisp is hardly something that is holding
Emacs back (so why change at all?, he asks).
I pretty much agree with that, at least in this sense:
If the only serious difference between GNU Emacs and
a new Scheme-based GNU Emacs were a change in extension
language - then there would be little point in bothering.
To succeed, a Scheme-based Emacs project would have to
produce an Emacs with features that users really enjoy
but that would be hard if not impossible to do in
GNU Emacs with Emacs lisp. (In contrast, just replacing
the Emacs lisp interpreter with a version of Guile that
faithfully implements Emacs Lisp can succeed
without needing to produce radically new features.)
What kind of features might a Scheme-based Emacs offer
that would be that important? Some speculation:
Because Emacs Lisp support would be an explicit
non-goal, everyone's favorite lisp package would have
to be re-written (though, yes, often cribbing off
of the Emacs Lisp version). Thus there would be
opportunity (and a forcing function) to reconsider
countless "little annoying details" of those packages
and produce new versions with many improved details.
Because a Scheme engine *should* wind up being
significantly faster, and because such radical
changes to the C code would be needed anyway, there
is an opportunity to write more of the editor in
the extension language, and less in C. In and
of itself that doesn't help users. In practice it
can help users by making more of Emacs much easier
to modify and improve. For example (and, yes, this
is a bit hand-wavy): if more of the display code
were in Scheme, there is a good chance that there
would be more and fancier features and "nice touches"
in the display.
I think that most people would agree that Scheme
is a significantly more powerful language than Emacs
lisp in the sense that it is easier to write more
sophisticated programs in Scheme (with its closures,
its fancy macro systems, and so forth). This, again,
does not directly benefit users. In practice it could
benefit users because in the same number of lines of
code (Scheme vs. Emacs Lisp) an extension package could
often provide more ambitious, fancier features. I've
a few times mentioned the example SCSH (the Scheme shell)
and it's a fine example to use here: a SCSH is not
especially large or complicated. SCSH presents a
subprocess management interface that is light years ahead
of Emacs' and that would be rather painful to write in
Emacs Lisp. The interface to sub-processes is again
of no direct importance to users but what would benefit
users are creative new applications enabled by the new
interface. That is, Scheme's more powerful environment
leads to subsystems like SCSH which leads to extension package
developers using sub-processes more often and in fancier
ways which - one would hope - leads to fancier, user-facing
extension language packages.
You get the idea, I hope.
Scheme isn't some magic bullet that, by its mere presence,
would advance Emacs into a bright new future. It is a
nicer, more comfortable extension language, more standard
than Emacs lisp, and affording more efficient implementations
than Emacs lisp could ever hope to afford - all details that
don't help users directly.
The stubborn decision to start fresh and cannibalize
GNU Emacs to make a Scheme-based Emacs *could* be, in addition
to possibly being fun, a catalyst. By forcing the rewrite or
significant modification of large subsystems, it would force
a careful design review and updating - without the pressure
of being upwards compatible with Emacs lisp. In that
adapt / rewrite process, there is opportunity not just to go
after one or two new "killer features" - but rather to go after
many, many small but noticeable improvements all across the
board. And if more of the editor is written in the extension
language and the extension language is a more powerful language
with a faster implementation - then it *should* (no guarantees)
work out that within a few years the Scheme based version
will have user-facing features that make people say "Wow. The
old Emacs couldn't do that!"
-t
next prev parent reply other threads:[~2010-04-14 19:07 UTC|newest]
Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4B8147A9.7030504@gmail.com>
[not found] ` <87ljemdzxo.fsf@stupidchicken.com>
2010-02-23 5:31 ` Next pretest, and branching plans Jason Rumney
2010-02-23 18:29 ` Eli Zaretskii
2010-02-23 21:12 ` Jason Rumney
2010-02-24 6:04 ` Richard Stallman
2010-02-24 13:34 ` Sean Sieger
2010-02-24 15:05 ` Davis Herring
2010-02-24 15:18 ` Sean Sieger
2010-02-24 14:05 ` Chong Yidong
2010-02-25 14:26 ` Richard Stallman
2010-02-26 18:03 ` manuals [was Re: Next pretest, and branching plans] Glenn Morris
2010-02-27 2:32 ` Richard Stallman
2010-02-27 16:52 ` Next pretest, and branching plans Johan Bockgård
2010-03-03 3:52 ` Glenn Morris
2010-03-05 0:31 ` Johan Bockgård
2010-03-05 19:50 ` integer overflow [was Re: Next pretest, and branching plans] Glenn Morris
2010-03-05 22:35 ` integer overflow Stefan Monnier
2010-03-06 2:55 ` Glenn Morris
2010-03-06 3:11 ` Chong Yidong
2010-03-06 7:03 ` Helmut Eller
2010-03-06 15:45 ` Stefan Monnier
2010-03-06 16:23 ` Davis Herring
2010-03-06 16:33 ` Drew Adams
2010-03-07 7:52 ` Richard Stallman
2010-03-07 16:06 ` David Kastrup
2010-03-07 17:18 ` Stephen J. Turnbull
2010-03-07 17:42 ` David Kastrup
2010-03-08 4:49 ` Jay Belanger
2010-03-08 8:04 ` Richard Stallman
2010-03-08 14:41 ` Guile in Emacs (was: integer overflow) Ted Zlatanov
2010-03-08 17:32 ` Guile in Emacs Ted Zlatanov
2010-03-08 18:42 ` Guile in Emacs (was: integer overflow) Chad Brown
2010-03-09 7:07 ` Ken Raeburn
2010-03-09 16:22 ` Guile in Emacs Ted Zlatanov
2010-03-10 8:07 ` Ken Raeburn
2010-03-10 13:58 ` David Kastrup
2010-03-09 3:19 ` Guile in Emacs (was: integer overflow) Richard Stallman
2010-04-11 23:33 ` Thomas Lord
2010-04-12 12:30 ` Richard Stallman
2010-04-12 20:05 ` Thomas Lord
2010-04-13 12:44 ` Guile in Emacs Bruce Stephens
2010-04-13 15:51 ` Thomas Lord
2010-04-13 16:07 ` Stefan Monnier
2010-04-13 18:56 ` Thomas Lord
2010-04-13 19:22 ` Christian Lynbech
2010-04-14 10:14 ` Bruce Stephens
2010-04-14 14:10 ` joakim
2010-04-13 19:13 ` Christian Lynbech
2010-04-14 1:47 ` Thomas Lord
2010-04-14 3:33 ` Christian Lynbech
2010-04-14 23:33 ` Richard Stallman
2010-04-14 5:02 ` Richard Stallman
2010-04-14 6:45 ` christian.lynbech
2010-04-14 19:07 ` Thomas Lord [this message]
2010-04-14 19:34 ` Bruce Stephens
2010-04-14 20:09 ` Jose A. Ortega Ruiz
2010-04-15 7:34 ` christian.lynbech
2010-04-14 23:33 ` Richard Stallman
2010-04-15 3:52 ` Drew Adams
2010-04-15 6:01 ` David Kastrup
2010-04-15 6:54 ` Drew Adams
2010-04-15 11:59 ` Jeff Clough
2010-04-15 12:49 ` christian.lynbech
2010-04-15 13:54 ` Jeff Clough
2010-04-15 14:03 ` Lennart Borgman
2010-04-15 16:13 ` Drew Adams
2010-04-16 13:48 ` Jeff Clough
2010-04-16 14:03 ` christian.lynbech
2010-04-16 14:25 ` Jeff Clough
2010-04-16 14:25 ` Drew Adams
2010-04-16 14:39 ` David Kastrup
2010-04-16 14:40 ` Jeff Clough
2010-04-16 8:27 ` christian.lynbech
2010-04-17 4:41 ` Richard Stallman
2010-04-19 7:52 ` christian.lynbech
2010-04-16 22:29 ` Emacs Info manuals (was: Guile in Emacs) Juri Linkov
2010-04-15 16:11 ` Guile in Emacs Drew Adams
2010-04-15 7:21 ` christian.lynbech
2010-04-15 7:36 ` David Kastrup
2010-04-15 8:34 ` christian.lynbech
2010-04-15 9:06 ` David Kastrup
2010-04-15 9:45 ` Helmut Eller
2010-04-15 10:39 ` christian.lynbech
2010-04-15 18:47 ` Richard Stallman
2010-04-15 22:42 ` Harald Hanche-Olsen
2010-04-15 22:50 ` Harald Hanche-Olsen
2010-04-17 4:40 ` Richard Stallman
2010-04-15 23:02 ` Helmut Eller
2010-04-17 4:40 ` Richard Stallman
2010-04-17 6:46 ` Helmut Eller
2010-04-17 19:55 ` Richard Stallman
2010-04-14 13:30 ` John Wiegley
2010-04-14 14:18 ` Helmut Eller
2010-04-14 15:40 ` Tom Tromey
2010-04-14 7:51 ` David Kastrup
2010-04-14 8:42 ` christian.lynbech
2010-04-14 9:55 ` immanuel litzroth
2010-04-14 10:28 ` christian.lynbech
2010-04-14 11:25 ` Stephen J. Turnbull
2010-04-14 12:26 ` christian.lynbech
2010-04-14 16:49 ` Ken Raeburn
2010-04-14 18:29 ` Tom Tromey
2010-04-14 20:02 ` Ken Raeburn
2010-04-14 11:23 ` Jeff Clough
2010-04-14 13:11 ` Stephen J. Turnbull
2010-04-14 13:11 ` Stephen Eilert
2010-04-14 13:49 ` Helmut Eller
2010-04-14 15:47 ` Tom Tromey
2010-04-14 16:41 ` Drew Adams
2010-04-14 20:10 ` David De La Harpe Golden
2010-04-15 10:38 ` Leo
2010-03-06 19:04 ` integer overflow Helmut Eller
2010-03-06 21:26 ` Stefan Monnier
2010-03-07 7:51 ` Richard Stallman
2010-03-07 19:05 ` Johan Bockgård
2010-03-06 20:35 ` Chong Yidong
2010-03-13 3:10 ` Next pretest, and branching plans Christoph
2010-03-13 7:42 ` Eli Zaretskii
2010-03-13 14:54 ` Christoph
2010-03-13 18:30 ` Stefan Monnier
2010-03-13 19:06 ` Eli Zaretskii
2010-03-14 2:38 ` Jason Rumney
2010-03-14 2:50 ` Christoph
2010-03-14 3:07 ` Jason Rumney
2010-03-14 17:55 ` Eli Zaretskii
2010-03-17 0:29 ` Christoph
2010-03-17 4:14 ` Eli Zaretskii
2010-03-17 12:44 ` Jason Rumney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1271272025.6576.49.camel@dell-desktop.example.com \
--to=lord@emf.net \
--cc=bruce.stephens@isode.com \
--cc=christian.lynbech@tieto.com \
--cc=christian@defun.dk \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.