Re: Experimental features

[T. V. Raman]

The other advantage in doing what you suggest is that external
packages can evolve more rapidly than Emacs.

Including things with core emacs is primarily a user convenience;
but that then becomes an inconvenience if core Emacs includes an
older version of an external package, because, now the user has
to know to grab the unbundled package and install it such that it
shadows what is bundled with Emacs. Thus, I believe:

A)      Core Emacs should unbundle --- not bundle more packages
B)      Core Emacs needs a light-weight means for users to
discover and incorporate additional esxternal packages into their site.

>>>>> "Andreas" == Andreas Röhler <address@hidden> writes:
    Andreas> Am Freitag, 22. Juni 2007 23:05 schrieb Stefan
    Andreas> Monnier:
    >> Release practice during Emacs-21 at least is that new
    >> features could only appear in new major releases, except
    >> for a few small exceptions.
    >> 
    >> I'd like to change that to make released Emacsen evolve
    >> faster.  One way to do that would be to introduce the idea
    >> of "experimental" features which could be added to any
    >> minor release.
    >> 
    >> An experimental feature would be disabled by default and
    >> the code should be written in such a way that as long as
    >> the feature is enabled, it's clearly obvious that it
    >> cannot have any negative effect.
    >> 
    >> We'd then provide a way for the user to activate some of
    >> the experimental features from her .emacs file.  After
    >> some time, we would promote the new feature such that it
    >> is not experimental any more.
    >> 
    >> 
    >> Stefan
    >> 
    Andreas> 
Very good idea. But let's put the question more thoroughly: as
    Andreas> the realm of computing is vast and ever expands, you
    Andreas> have to give up the idea to incorporate any valid
    Andreas> program into core-Emacs sooner or later.
    Andreas> 
    Andreas> Emacs already is unnecessary big for most of the
    Andreas> purposes.  Thus it starts not as quick as others,
    Andreas> risks not to be first choice for calling under
    Andreas> certain circumstances. That's a pity for me, because
    Andreas> I prefer it. Don't want to write any line without
    Andreas> it, even not to my mother. :)
    Andreas> 
    Andreas> I propose a more slim core emacs coming with an
    Andreas> install-shield, which lets users click features,
    Andreas> some of them may be marked as experimental too.
    Andreas> 
    Andreas> Given this, I would be glad to see common
    Andreas> third-party features as ESS, ECB, Emacspeak
    Andreas> etc. reachable too that way.
    Andreas> 
    Andreas> I'm aware this would mean a major work. However, it
    Andreas> must not be done at once. It offers great chances,
    Andreas> because it would ease the use for many people, thus
    Andreas> expanding the number of users.
    Andreas> 
    Andreas> Andreas Roehler
    Andreas> 
    Andreas> 
    Andreas> _______________________________________________
    Andreas> Emacs-devel mailing list address@hidden
    Andreas> http://lists.gnu.org/mailman/listinfo/emacs-devel

--
Best Regards,
--raman


Email:  address@hidden
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: address@hidden
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman
IRC:    irc://irc.freenode.net/#emacs