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