Re: Modern Conventions for Emacs Lisp files?

[Alan Mackenzie <acm@muc.de>]

Morning, Thorsten!

On Mon, Apr 08, 2013 at 02:23:54AM +0200, Thorsten Jolitz wrote:

> Hi List, 

> there are new ways (libraries) to make Emacs Lisp buffers similar to
> Org-mode buffers in looks and (outline) functionality. 

> I made a screencast showing these new libraries for 'Org-mode outside
> Org-mode' (outshine, outorg, poporg, navi-mode) in action:

> ,----------------------------
> | http://youtu.be/nqE6YxlY0rw
> `----------------------------

I must admit, I spent more time listening to the music than paying
attention to the screen.  ;-)

> (Watch in HD)

> 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.

> Something like this:

> 1. File structuring with outcommented Org-mode headlines (;; * Headline)
> 2. Meta information not as free text anymore but as Org-mode properties,
> maybe like this:

> ,---------------------------------------------------------
> | * navi-mode.el --- major-mode for easy buffer-navigation
> |   :PROPERTIES:
> |   :copyright: Thorsten Jolitz
> |   :copyright-years: 2013
> |   :version:  0.9
> |   :licence:  GPL 2 or later (free software)
> |   :licence-url: http://www.gnu.org/licenses/
> |   :part-of-emacs: no
> |   :author: Thorsten Jolitz
> |   :author_email: tjolitz AT gmail DOT com
> |   :inspiration:  occur-mode org-mode
> |   :keywords: emacs outline lisp
> |   :END:
> `---------------------------------------------------------

> 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.

> -- 
> cheers,
> Thorsten

-- 
Alan Mackenzie (Nuremberg, Germany).