From: David Kastrup <dak@gnu.org>
To: taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer")
Cc: "Ludovic Courtès" <ludo@gnu.org>, "Eli Zaretskii" <eliz@gnu.org>,
emacs-devel@gnu.org
Subject: Re: Emacs rewrite in a maintainable language
Date: Sun, 18 Oct 2015 17:31:33 +0200 [thread overview]
Message-ID: <87si58mbvu.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <87h9los0ic.fsf@T420.taylan> ("Taylan Ulrich \"Bayırlı/Kammer\""'s message of "Sun, 18 Oct 2015 16:40:43 +0200")
taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
> David Kastrup <dak@gnu.org> writes:
>
>> taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
>>
>>> David Kastrup <dak@gnu.org> writes:
>>
>> It is not the job of an extension language to dictate application
>> behavior.
>
> It is the job of programming tools to aid programmers in writing good
> applications.
As long as you call Emacs a bad application because of its support of a
large number of encodings and situations beyond Unicode and utf-8,
support that was driven by user requirements and has been a long series
of improvements, you are not on a good road to sell GuileEmacs to either
Emacs or GUILE developers.
>> It is not the job of an extension language to dictate the concept of
>> "character". Of course, not everything can be supported out of the
>> box and there are limits to what can be supported due to technical
>> reasons. However, the stance of the GUILE developers is to stop
>> people using GUILE from doing things they consider not their problem.
>
> What is a character and what is a string is understood very well, and
> Guile provides clean abstractions for these, as any sane general
> purpose language should.
GUILE does not provide an "abstraction" but rather is Unicode-only to a
degree where (integer->char #xD800) produces an error, making it even
impossible to manipulate CESU-8 strings.
> While I can't speak for the Guile developers, I can assure you that
> their stance is to provide the best possible abstractions a general
> purpose language should provide.
Again: if GUILE is no longer considered an extension language, this
needs to be communicated to GNU in order to adapt its intended and
advertised role in the GNU project.
>> This stance, possibly partly due to only a single developer working
>> in isolation on the "unstable" branch and everybody else confined to
>> changes in the "stable" branch, is going to end a roadblock for
>> projects like GuileEmacs.
>
> You seem to be making wrong assumptions about Guile's development
> model. I don't think the fact that the upcoming 2.2 has been mostly a
> one person project has much to do with the incompatibilities between
> 1.x and 2.x.
That's not what I said. What I said is that work on the encoding
problems of GUILE (and having to do conversions for passing a
GUILE-internal string through a GUILE-internal string port is a problem)
has no place since the "unstable branch" contains just single-person
compiler-focused work while such changes in a "stable branch" would be
uncalled for. This setup leads to a strong defensive stance preferring
the status quo since there is no place for most changes that are not
mere bugfixes or incremental improvements to go to.
>>> For arbitrary byte vectors, Guile has bytevectors (surprise!!).
>>>
>>> If one implemented a text editor from scratch in Guile and wanted to
>>> allow editing files with no proper encoding, one would use an
>>> abstraction on top of bytevectors.
>>
>> It is not the job of an extension language to dictate what
>> constitutes "proper encoding". It is the job of the application.
>
> Yes, it *is* the job of a string library to offer abstractions for
> well-defined encodings of strings.
Shrug. "abstraction" is not the same as "restriction". Unicode is not
an abstraction. It's a reference point for an implementation. And as a
reference it was good and versatile enough that Emacs changed its
multibyte implementation in Emacs 23 to one based on UTF-8 and Unicode
internally. And because Emacs multibyte encodings were rather
well-abstracted at the application layer, this change, while extensive
and pervasive, was surprisingly non-disruptive for applications.
>> GUILE is first and foremost an extension language. That is how it
>> advertises itself on its web page. That it supports the
>> general-purpose programming language Scheme is a boon and
>> implementation choice.
>>
>> If GUILE developers insist on GUILE being foremost a general-purpose
>> programming language rather than an extension language, they should
>> notify the GNU project and change their web page. There is no point
>> in GNU promoting GUILE as an extension language if the GUILE
>> developers are no longer on board with that target.
>
> You seem to be making a strange distinction between a general-purpose
> and an extension language and implying that an "extension language"
> should fill exactly the use-cases of Emacs for some reason...
Not just Emacs. Pretty much every application that requires more
specific error handling than rejecting an entire file or communication.
Like, say, LilyPond.
>> That is a pretty alien concept to established Emacs developers, Emacs
>> being the proverbial glue and shoe string across dozens of different
>> platforms right from the beginning of GNU where POSIX would have been
>> luxury.
>
> Maybe some established Emacs developers should get with the times
> then.
Shrug. Files won't magically convert themselves into only containing
material encodable by proper UTF-8 and nothing else. Dropping
everything achieved in character and string handling since Emacs 20 so
that GUILE must not adapt is not an option that is realistic.
> I'm not interested in continuing this discussion because it's just as
> unproductive as the last time. GuileEmacs has come *very* far, and
> most arguments I hear against it seem based in apocalyptic FUD, and in
> particular spitefulness due to past negative experiences with the
> Guile 1.x/2.x transition, which has really nothing to do with
> GuileEmacs, a Guile 2.x project. That is not to say it's going to be
> fairies and pixies. There's significant work to be done on it and I
> hope I will find some time to contribute to it in the not too distant
> future.
You'll not be able to restrict all changes to Emacs (GuileEmacs being a
branch of Emacs development). There are changes and improvements
necessary in GUILE itself to make it viable as a platform for running
Emacs on. Denying that is doing a disfavor to those who have invested
considerable work into GuileEmacs by now since it makes it less than
more likely that GuileEmacs can sensibly become the main implementation
of Emacs.
--
David Kastrup
next prev parent reply other threads:[~2015-10-18 15:31 UTC|newest]
Thread overview: 250+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-11 8:11 Emacs rewrite in a maintainable language Przemysław Wojnowski
2015-10-11 8:17 ` David Kastrup
2015-10-11 22:02 ` Marcin Borkowski
2015-10-11 22:14 ` John Wiegley
2015-10-11 22:37 ` Óscar Fuentes
2015-10-11 22:37 ` Marcin Borkowski
2015-10-11 22:49 ` John Wiegley
2015-10-11 22:51 ` Óscar Fuentes
2015-10-11 23:12 ` Drew Adams
2015-10-12 2:43 ` Eli Zaretskii
2015-10-12 15:35 ` Eli Zaretskii
2015-10-12 21:30 ` Daniel Colascione
2015-10-12 20:01 ` Richard Stallman
2015-10-11 8:54 ` Alexis
2015-10-11 10:53 ` Przemysław Wojnowski
2015-10-11 11:23 ` Thomas Koch
2015-10-11 13:11 ` Dmitry Gutov
2015-10-11 13:36 ` David Kastrup
2015-10-11 13:39 ` Dmitry Gutov
2015-10-11 13:55 ` David Kastrup
2015-10-11 14:03 ` Dmitry Gutov
2015-10-11 12:52 ` Daniel Colascione
2015-10-11 12:59 ` Fabrice Popineau
2015-10-11 17:25 ` John Wiegley
2015-10-11 18:32 ` Óscar Fuentes
2015-10-11 19:14 ` Eli Zaretskii
2015-10-11 19:43 ` Óscar Fuentes
2015-10-11 19:53 ` Eli Zaretskii
2015-10-11 20:13 ` Óscar Fuentes
2015-10-12 2:33 ` Eli Zaretskii
2015-10-12 3:59 ` Paul Eggert
2015-10-12 8:12 ` Steinar Bang
2015-10-12 9:36 ` Marcin Borkowski
2015-10-12 10:20 ` David Kastrup
2015-10-12 12:23 ` Óscar Fuentes
2015-10-12 16:08 ` Eli Zaretskii
2015-10-12 20:00 ` Richard Stallman
2015-10-13 2:36 ` Rustom Mody
2015-10-12 10:56 ` Michael Heerdegen
2015-10-11 21:52 ` John Wiegley
2015-10-12 7:14 ` David Kastrup
2015-10-12 12:48 ` Oleh Krehel
2015-10-12 13:22 ` Óscar Fuentes
2015-10-12 14:18 ` Oleh Krehel
2015-10-12 15:04 ` David Kastrup
2015-10-12 18:24 ` John Wiegley
2015-10-12 19:21 ` Óscar Fuentes
2015-10-12 19:39 ` John Wiegley
2015-10-12 19:46 ` Eli Zaretskii
2015-10-12 19:58 ` Eli Zaretskii
2015-10-12 20:11 ` John Wiegley
2015-10-12 20:42 ` Marcin Borkowski
2015-10-12 20:46 ` Óscar Fuentes
2015-10-13 14:57 ` Eli Zaretskii
2015-10-13 16:22 ` John Wiegley
2015-10-13 16:40 ` Drew Adams
2015-10-13 16:49 ` John Wiegley
2015-10-12 20:40 ` Drew Adams
2015-10-13 4:18 ` John Wiegley
2015-10-13 6:00 ` immerrr again
2015-10-13 14:59 ` Eli Zaretskii
2015-10-13 1:12 ` Óscar Fuentes
2015-10-13 10:01 ` David Kastrup
2015-10-13 15:12 ` Eli Zaretskii
2015-10-13 15:20 ` David Kastrup
2015-10-14 15:04 ` Chris Patti
2015-10-14 15:34 ` Jay Belanger
2015-10-16 12:25 ` Guile-Emacs Ludovic Courtès
2015-10-16 12:03 ` Emacs rewrite in a maintainable language Ludovic Courtès
2015-10-16 13:30 ` Eli Zaretskii
2015-10-16 14:55 ` Wolfgang Jenkner
2015-10-16 15:14 ` Eli Zaretskii
2015-10-16 15:25 ` Ludovic Courtès
2015-10-16 15:51 ` David Kastrup
2015-10-16 14:29 ` David Kastrup
2015-10-16 15:08 ` Eli Zaretskii
2015-10-16 15:28 ` David Kastrup
2015-10-16 16:05 ` Eli Zaretskii
2015-10-16 15:31 ` Ludovic Courtès
2015-10-16 16:11 ` Eli Zaretskii
2015-10-16 19:34 ` Przemysław Wojnowski
2015-10-16 19:51 ` David Kastrup
2015-10-16 19:52 ` Eli Zaretskii
2015-10-16 20:51 ` Ludovic Courtès
2015-10-17 5:27 ` David Kastrup
2015-10-17 7:20 ` Eli Zaretskii
2015-10-17 9:44 ` Ludovic Courtès
2015-10-17 10:24 ` Eli Zaretskii
2015-10-18 10:22 ` Ludovic Courtès
2015-10-18 11:33 ` David Kastrup
2015-10-18 12:54 ` Taylan Ulrich Bayırlı/Kammer
2015-10-18 13:17 ` David Kastrup
2015-10-18 14:40 ` Taylan Ulrich Bayırlı/Kammer
2015-10-18 15:31 ` David Kastrup [this message]
2015-10-18 16:19 ` Eli Zaretskii
2015-10-18 16:37 ` Taylan Ulrich Bayırlı/Kammer
2015-10-18 16:44 ` Eli Zaretskii
2015-10-18 17:06 ` Taylan Ulrich Bayırlı/Kammer
2015-10-18 17:11 ` David Kastrup
2015-10-18 17:36 ` Eli Zaretskii
2015-10-18 17:52 ` John Wiegley
2015-10-18 18:23 ` Daniel Colascione
2015-10-18 18:35 ` David Kastrup
2015-10-18 18:53 ` Daniel Colascione
2015-10-18 19:03 ` David Kastrup
2015-10-18 19:13 ` Paul Eggert
2015-10-18 19:35 ` Taylan Ulrich Bayırlı/Kammer
2015-10-18 19:49 ` Daniel Colascione
2015-10-19 7:59 ` Taylan Ulrich Bayırlı/Kammer
2015-10-19 10:50 ` Stephen J. Turnbull
2015-10-19 10:59 ` Eli Zaretskii
2015-10-19 11:31 ` David Kastrup
2015-10-19 12:04 ` David Kastrup
2015-10-19 11:24 ` David Kastrup
2015-10-20 4:18 ` Stephen J. Turnbull
2015-10-20 7:36 ` David Kastrup
2015-10-20 10:17 ` Stephen J. Turnbull
2015-10-19 12:26 ` Taylan Ulrich Bayırlı/Kammer
2015-10-19 12:53 ` David Kastrup
2015-10-19 17:43 ` Tom Tromey
2015-10-19 18:06 ` David Kastrup
2015-10-20 2:46 ` Tom Tromey
2015-10-19 8:46 ` David Kastrup
2015-10-19 9:39 ` Przemysław Wojnowski
2015-10-19 5:33 ` Richard Stallman
2015-10-26 11:01 ` Alexis
2015-10-18 19:16 ` Taylan Ulrich Bayırlı/Kammer
2015-10-18 22:38 ` Nicolas Petton
2015-10-20 7:34 ` John Wiegley
2015-10-18 16:40 ` John Wiegley
2015-10-18 16:56 ` David Kastrup
2015-10-18 17:46 ` Stephen J. Turnbull
2015-10-19 7:45 ` Gian Uberto Lauri
2015-10-17 15:38 ` David Kastrup
2015-10-17 16:25 ` Taylan Ulrich Bayırlı/Kammer
2015-10-17 16:43 ` David Kastrup
2015-10-17 17:00 ` Taylan Ulrich Bayırlı/Kammer
2015-10-17 16:48 ` Eli Zaretskii
2015-10-17 17:03 ` Taylan Ulrich Bayırlı/Kammer
2015-10-17 17:08 ` David Kastrup
2015-10-17 17:10 ` Eli Zaretskii
2015-10-17 18:31 ` Stephen J. Turnbull
2015-10-17 17:04 ` David Kastrup
2015-10-17 17:32 ` Taylan Ulrich Bayırlı/Kammer
2015-10-17 17:42 ` David Kastrup
2015-10-17 18:34 ` Taylan Ulrich Bayırlı/Kammer
2015-10-17 19:15 ` Eli Zaretskii
2015-10-17 21:22 ` Taylan Ulrich Bayırlı/Kammer
2015-10-18 0:23 ` John Wiegley
2015-10-18 15:53 ` Richard Stallman
2015-10-18 16:58 ` Tom Tromey
2015-10-18 17:40 ` John Wiegley
2015-10-18 19:40 ` Eli Zaretskii
2015-10-18 20:47 ` David Kastrup
2015-10-19 3:55 ` Tom Tromey
2015-10-20 7:33 ` John Wiegley
2015-10-12 19:43 ` Eli Zaretskii
2015-10-13 8:27 ` Przemysław Wojnowski
2015-10-13 8:52 ` Gian Uberto Lauri
2015-10-13 10:19 ` Tassilo Horn
2015-10-13 15:14 ` Eli Zaretskii
2015-10-13 19:45 ` Tassilo Horn
2015-10-13 15:05 ` Eli Zaretskii
2015-10-13 16:09 ` John Wiegley
2015-10-13 20:43 ` Przemysław Wojnowski
2015-10-13 16:06 ` John Wiegley
2015-10-13 20:20 ` Przemysław Wojnowski
2015-10-13 21:22 ` emacs IDE features (was: Emacs rewrite in a maintainable language) Andrés Ramírez
2015-10-13 22:13 ` emacs IDE features John Wiegley
2015-10-14 11:11 ` Phillip Lord
2015-10-16 23:13 ` John Wiegley
2015-10-17 7:40 ` Eli Zaretskii
2015-10-17 23:51 ` John Wiegley
2015-10-18 0:48 ` Sacha Chua
2015-10-18 2:34 ` Xue Fuqiao
2015-10-18 17:05 ` Sacha Chua
2015-10-18 17:31 ` John Wiegley
2015-10-18 16:21 ` John Wiegley
2015-10-19 16:37 ` Christopher Allan Webber
2015-10-18 16:47 ` Eli Zaretskii
2015-10-18 17:30 ` John Wiegley
2015-10-19 10:30 ` Phillip Lord
2015-10-20 6:56 ` John Wiegley
2015-10-13 22:10 ` Emacs rewrite in a maintainable language John Wiegley
2015-10-12 23:00 ` Camm Maguire
2015-10-13 1:38 ` Alexis
2015-10-13 1:40 ` Daniel Colascione
2015-10-13 23:34 ` Richard Stallman
2015-10-13 23:55 ` John Wiegley
2015-10-13 5:28 ` Ken Raeburn
2015-10-13 5:39 ` John Wiegley
2015-10-13 10:13 ` David Kastrup
2015-10-14 1:43 ` Daniel Colascione
2015-10-13 6:49 ` Stephen J. Turnbull
2015-10-12 13:50 ` David Kastrup
2015-10-12 15:17 ` Oleh Krehel
2015-10-12 15:35 ` David Kastrup
2015-10-12 16:29 ` Eli Zaretskii
2015-10-12 22:39 ` Paul Eggert
2015-10-13 11:27 ` Oleh Krehel
2015-10-13 11:46 ` Alan Mackenzie
2015-10-13 12:02 ` Oleh Krehel
2015-10-13 12:21 ` Alan Mackenzie
2015-10-13 12:22 ` Mathieu Lirzin
2015-10-13 13:52 ` John Yates
2015-10-13 14:30 ` David Kastrup
2015-10-13 16:26 ` Andreas Schwab
2015-10-13 16:40 ` John Wiegley
2015-10-13 14:38 ` Oleh Krehel
2015-10-13 13:06 ` Sergey Organov
2015-10-13 14:19 ` Artur Malabarba
2015-10-13 14:39 ` David Kastrup
2015-10-13 15:21 ` Artur Malabarba
2015-10-13 15:53 ` David Kastrup
2015-10-13 16:09 ` Oleh Krehel
2015-10-13 16:23 ` David Kastrup
2015-10-13 16:31 ` Eli Zaretskii
2015-10-13 16:38 ` David Kastrup
2015-10-13 15:21 ` Eli Zaretskii
2015-10-13 15:42 ` David Kastrup
2015-10-13 15:32 ` Paul Eggert
2015-10-13 16:13 ` Oleh Krehel
2015-10-13 21:02 ` Andy Moreton
2015-10-14 8:15 ` Oleh Krehel
2015-10-14 13:28 ` Andy Moreton
2015-10-14 16:18 ` Eli Zaretskii
2015-10-14 10:22 ` Przemysław Wojnowski
2015-10-14 10:56 ` Tassilo Horn
2015-10-14 11:14 ` Przemysław Wojnowski
2015-10-14 11:33 ` Oleh Krehel
2015-10-14 12:12 ` Tassilo Horn
2015-10-14 11:46 ` David Kastrup
2015-10-14 12:29 ` Tassilo Horn
2015-10-14 11:21 ` Mathieu Lirzin
2015-10-14 16:05 ` John Wiegley
2015-10-13 16:13 ` John Wiegley
2015-10-12 15:09 ` Paul Eggert
2015-10-12 15:24 ` David Kastrup
2015-10-12 15:24 ` Oleh Krehel
2015-10-12 16:31 ` Eli Zaretskii
2015-10-12 17:20 ` Stephen J. Turnbull
2015-10-13 12:02 ` Marcus Harnisch
2015-10-13 23:38 ` Richard Stallman
2015-10-14 1:46 ` Daniel Colascione
2015-10-14 13:08 ` Marcus Harnisch
2015-10-12 16:18 ` Eli Zaretskii
2015-10-12 17:47 ` Steinar Bang
2015-10-12 17:59 ` David Kastrup
2015-10-12 21:28 ` Daniel Colascione
2015-10-11 18:36 ` Przemysław Wojnowski
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=87si58mbvu.fsf@fencepost.gnu.org \
--to=dak@gnu.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=taylanbayirli@gmail.com \
/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.