From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thorsten Jolitz Newsgroups: gmane.emacs.devel Subject: Re: Modern Conventions for Emacs Lisp files? Date: Mon, 08 Apr 2013 22:05:18 +0200 Message-ID: <87ppy4u6td.fsf@gmail.com> References: <87hajhswdh.fsf@gmail.com> <20130408093239.GA3810@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1365451536 6209 80.91.229.3 (8 Apr 2013 20:05:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Apr 2013 20:05:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 08 22:05:40 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UPIJv-0005Sl-Bj for ged-emacs-devel@m.gmane.org; Mon, 08 Apr 2013 22:05:39 +0200 Original-Received: from localhost ([::1]:57653 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPIJu-0007al-Sy for ged-emacs-devel@m.gmane.org; Mon, 08 Apr 2013 16:05:38 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPIJr-0007aQ-5U for emacs-devel@gnu.org; Mon, 08 Apr 2013 16:05:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPIJm-0006kL-EW for emacs-devel@gnu.org; Mon, 08 Apr 2013 16:05:35 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:58745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPIJm-0006kD-7D for emacs-devel@gnu.org; Mon, 08 Apr 2013 16:05:30 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UPIJj-0005F2-Iw for emacs-devel@gnu.org; Mon, 08 Apr 2013 22:05:27 +0200 Original-Received: from g231225015.adsl.alicedsl.de ([92.231.225.15]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Apr 2013 22:05:27 +0200 Original-Received: from tjolitz by g231225015.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Apr 2013 22:05:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 65 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: g231225015.adsl.alicedsl.de User-Agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:BVn/Jr/HergdlKfZ8DPTnMLF8yc= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:158779 Archived-At: Alan Mackenzie writes: > I must admit, I spent more time listening to the music than paying > attention to the screen. ;-) I was surprised too that Youtube offers me such wonderful completely unknown (Japanese!) jazz as a playback track I can add after uploading the screencast. >> Would it make sense to define 'modern conventions for Emacs Lisp files' >> based on all this new functionality and the popularity of Org-mode? > > Maybe for new elisp files, and those old ones which somebody is prepared > to convert. But not as a standard applicable to all elisp files. I guess that people who spend much time in Org-mode buffers anyway day by day (like me) might appreciate this 'Org-mode look & feel' in their Emacs lisp buffers too. >> 3. A file template somehow similar to this: > >> ,--------------------------------------------------------- >> | * navi-mode.el --- major-mode for easy buffer-navigation >> | ** Commentary >> | *** About navi-mode >> | *** Usage >> | *** Installation >> | *** Emacs Version >> | ** ChangeLog >> | * Requires >> | * Mode Definitions >> | * Variables >> | ** Consts >> | ** Vars >> | ** Hooks >> | ** Fonts >> | ** Customs >> | *** Custom Groups >> | *** Custom Vars >> | * Defuns >> | ** Functions >> | ** Commands >> | * Menus and Keys >> | ** Menus >> | ** Keys >> | * Run Hooks and Provide >> `--------------------------------------------------------- > > I would be against this bit. I think that semantically close defined > entities should be close together. For example, cc-engine.el is divided > up into pages by ^Ls, and all the def{const,var,macro,subst,fun}s to do > with "A system for finding noteworthy parens before the point" are > together in that page. It is convenient to `narrow-to-page' to enclose > all these definitions together. This facility would be lost if all > definitions in the file (over 200 of them) were ordered as suggested > above. Thats a valid argument, so consider the above template just as something that turned out to be useful for me. It avoids ever increasing chaos in a developing library, but sometimes I thought too that it would actually be nice to have all definitions that belong together in one place. -- cheers, Thorsten