From mboxrd@z Thu Jan 1 00:00:00 1970
Path: main.gmane.org!not-for-mail
From: Phillip Lord
Newsgroups: gmane.emacs.help
Subject: Re: Software/HD ecology
Date: 12 Dec 2002 14:50:19 +0000
Organization: BIOSCI/MRC Human Genome Mapping Project Resource Centre
Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org
Message-ID:
References: <041220020952400758%ajanta@no.spam>
<56cfb0e3.0212041458.5eab182a@posting.google.com>
<061220020416350201%ajanta@no.spam>
<071220021155280606%ajanta@no.spam>
<5ld6obj8il.fsf@rum.cs.yale.edu> <091220021652087216%ajanta@no.spam>
<111220021101520860%ajanta@no.spam>
<111220021253524057%ajanta@no.spam>
<84of7s703d.fsf@lucy.cs.uni-dortmund.de>
<111220022147059290%anil@null.invalid>
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: main.gmane.org 1039704959 28190 80.91.224.249 (12 Dec 2002 14:55:59 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Thu, 12 Dec 2002 14:55:59 +0000 (UTC)
Return-path:
Original-Received: from monty-python.gnu.org ([199.232.76.173])
by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
id 18MUko-0007KW-00
for ; Thu, 12 Dec 2002 15:55:58 +0100
Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org)
by monty-python.gnu.org with esmtp (Exim 4.10.13)
id 18MUkN-0006bl-02
for gnu-help-gnu-emacs@m.gmane.org; Thu, 12 Dec 2002 09:55:31 -0500
Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!logbridge.uoregon.edu!newsfeed.icl.net!newsfeed.fjserv.net!lnewspeer00.lnd.ops.eu.uu.net!emea.uu.net!server1.netnews.ja.net!hgmp.mrc.ac.uk!not-for-mail
Original-Newsgroups: comp.sys.mac.apps,comp.sys.mac.advocacy,comp.text.tex,gnu.emacs.help
Original-Lines: 49
Original-NNTP-Posting-Host: bromine.hgmp.mrc.ac.uk
Original-X-Trace: niobium.hgmp.mrc.ac.uk 1039704620 339 193.62.192.35 (12 Dec 2002
14:50:20 GMT)
Original-X-Complaints-To: news@net.bio.net
Original-NNTP-Posting-Date: Thu, 12 Dec 2002 14:50:20 +0000 (UTC)
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.93
Original-Xref: shelby.stanford.edu comp.sys.mac.apps:348709
gnu.emacs.help:108033
Original-To: help-gnu-emacs@gnu.org
X-BeenThere: help-gnu-emacs@gnu.org
X-Mailman-Version: 2.1b5
Precedence: list
List-Id: Users list for the GNU Emacs text editor
List-Help:
List-Post:
List-Subscribe: ,
List-Archive:
List-Unsubscribe: ,
Errors-To: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org
Xref: main.gmane.org gmane.emacs.help:4564
X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:4564
>>>>> "Anil" == Anil Trivedi writes:
Anil> Stefan Monnier wrote:
>> As maintainers, it's in our own interest to keep things
>> uncluttered, so we strive to find some logic to things such that
>> we can organize our files and keep files in their logical
>> place...I don't claim that the current arrangement is perfect,
>> but it takes time and energy to think about how to make it better
>> and to fix the various places where things aren't consistent and
>> logical, so help is most welcome.
Anil> Kai Gro_johann wrote:
>> Writing these few extra lines is a LOT of work. Most important of
>> all, it's not clear what to delete. There would be *endless*
>> arguments about which files to remove and which files to keep.
>> Emacs consists of 2297 files (on my system), it's very difficult
>> to untangle dependencies on them.
Anil> 2. Once the program compiles, and works fine, the user should
Anil> be able
Anil> to delete all files that were needed in compiling but will not
Anil> be needed in running it, or in uninstalling it.
I think Kai's example showed the problem with this.
Personally I find an emacs without the .el files half baked. The
reason for this is that I read the .el source as a form of
documentation. Clearly this makes me a specialist user, but none the
less a user. Similarly the hyper links in command documentation will
not work with source, as there is no source to jump to.
The M-x finder-commentary example shows that even non programming
users may need the source to get all the functionality that they
require. Of course it would be possible to ensure that the commentary
was copied into the .elc file, or alternatively, it could be cut out,
and kept, so that you could still view it even when the .el files were
gone.
The core problem is that the Emacs is a lisp interpreter. The
distinction between "files required for compiling" and "files required
for running" is not clear with lisp as it is with C, for instance. My
own feeling is that binary distributions of emacs should always
include .el files, but not the C source for the lisp
interpreter. Which is what Emacs's own makefile installs.
Phil