[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Return
From: |
Samuel Bronson |
Subject: |
Re: Return |
Date: |
Tue, 7 Dec 2010 18:21:32 -0500 |
On Mon, Dec 6, 2010 at 9:42 PM, MON KEY <address@hidden> wrote:
> On Mon, Dec 6, 2010 at 2:20 AM, Stephen J. Turnbull <address@hidden> wrote:
>> MON KEY writes:
>> > What would be interesting to learn is whether there is any will for a
>> formal
>> > incorporation of the C in Clisp w/ the E in elisp?
>>
>> {...}
>> Hrvoje Niksic and Martin Buchholz advocated a Common Lisp as the
>> appropriate way to evolve elisp, and IIRC Erik Naggum was in that camp
>> too. But they've all long since left the development community.
>
> The slime users/developers are _actively_ incorporating Common Lisp
> (of various implementations) with Emacs/Emacs lisp (unfortunately they
> have to resort to a different RPC per implementation to do
> so). Regardless, the Slime user/devel community is hardly an
> insignificant group.
I thought they used a common CL-side codebase known as "swank" for all
of the Common Lisp implementations, and that something else was only
needed when talking with some other kind of Lisp (or a non-Lisp)?
> This said, I suspect most of them only actively engage elisp in lieu
> of Common Lisp out of necessity not preference.
>> > the closed/proprietary control maintained on the FSF Emacs source
>> > tree.
>>
>> Hardly closed *or* proprietary.
>
> Tomato/Potato[1]
Obviously the meaning here was not precisely "the opposite of Open
Source / Free Software", which *is* what those words most often mean
when they describe software in these parts, but note that here they
describe the *control* over a *particular* source tree, which is a
distinctly different thing, though many effects may be similar.
(Thankfully, not all: no matter how much of MS's .NET Framework source
code may be available for me to (hypothetically) single-step through,
I doubt I will ever be permitted to fork it or incorporate it into my
own programs beyond trivial-fair-use copy/paste/modify of tiny bits.
Not that I use .NET or anything; it's just the only example of a
totally proprietary codebase which nevertheless has more-or-less
publicly-visible code that I could think of -- where public == people
with access to Windows systems w/ sufficient free hard drive space to
install a recent enough Visual Foo Express Edition (at least, I think
it's supposed to work on Express Editions), admittedly.)
>> Remember XEmacs in your prayers, and
>> rest assured that any work you do on Emacs remains free for others to
>> use, whether GNU chooses to distribute it or not.
>
> No doubt. :)
>
>> If they choose not, you can always do it yourself, as we do.
>
> Yes but there is an accord to maintain some mutual consensus. AIUI your
> presence on this list is indicative of such an effort no?
> To paraphrase JWZ, "Now you have two problems."
You mean, maintaining the feature and dealing with the pain that is
non-core autoloads?
>> But ... I wouldn't bet that you'll have more luck peddling your warez
>> at xemacs.org or sxemacs.org for that matter.
>>
>
> I'm not aware of peddling either here or there... what is occurring
> here is more akin to carpet-bagging than to commerce in snake-oil.
>
>>
>> That's the nature of a distribution, that somebody decides what to
>> distribute.
>> Typically by rejecting your proposals, c'est la vie. :-)
>
> If there is angst here it is not around the rejection of any
> particular proposal (certainly not my own), but rather about the
> persistent inability to engage in reasoned/meaningful/intentioned
> discussion w/re incorporating of a particular set of Lisp features by
> either ignoring and/or dismissing the utility these features do
> otherwise provide both Emacs user community and the greater community
> of Lisp dialect users despite a general acknowledgment by both of
> these communities that the particular set of features are
> wanted/needed and FTMP can be reasonably implemented.
I seem to recall there being a very significant incident of this that
lead to someone forking Emacs ... if only I could remember what the
fork was called!
> [1] The long term evidence of this inability IMO suggests that the Emacs
> project(s) are closed and proprietary project (whether their source be
> free or not). That [SX]Emacs does remain reasonably compatible with
> GNU Emacs suggest that it too abides this inability (whether tacitly
> or otherwise).
Compatibility and restriction are two different things. That [S]XEmacs
does not incorporate more of the RMS-rejected features probably says
more about the development effort available to [S]XEmacs vs. that
required to implement/port/submit the features than anything else.
Probably, in the case of add-on packages, it does not help that the
XEmacs packaging machinery is only intended for use with packages
stored in its own CVS tree...
- Keyword args (was: Return), (continued)
- Keyword args (was: Return), Helmut Eller, 2010/12/10
- Re: Keyword args, Daniel Colascione, 2010/12/12
- Re: Keyword args, Helmut Eller, 2010/12/13
- Re: Keyword args, Andy Wingo, 2010/12/13
- Re: Keyword args, Miles Bader, 2010/12/14
- Re: Keyword args, Helmut Eller, 2010/12/14
- Re: Return, MON KEY, 2010/12/07
- Re: Return, Stephen J. Turnbull, 2010/12/08
- Re: Return, MON KEY, 2010/12/08
- Re: Return, Stephen J. Turnbull, 2010/12/09
- Re: Return,
Samuel Bronson <=
- Re: Return, Stephen J. Turnbull, 2010/12/08
- Re: Return, Samuel Bronson, 2010/12/08