emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modern Conventions for Emacs Lisp files?


From: Thorsten Jolitz
Subject: Re: Modern Conventions for Emacs Lisp files?
Date: Mon, 08 Apr 2013 22:05:18 +0200
User-agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.3 (gnu/linux)

Alan Mackenzie <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]