Re: Return

[Samuel Bronson <naesten@gmail.com>]

On Mon, Dec 6, 2010 at 9:42 PM, MON KEY <monkey@sandpframing.com> wrote:
> On Mon, Dec 6, 2010 at 2:20 AM, Stephen J. Turnbull <stephen@xemacs.org> 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...