Re: Modern Conventions for Emacs Lisp files?

[Thorsten Jolitz]

Stefan Monnier <address@hidden> writes:

>> I modified 'outshine.el', 'outorg.el' and 'navi-mode.el' so that they
>> now deal with the special case of "oldschool" elisp headers (";;;+").
>
> I see that the lines that match "^(" aren't treated as "deepest
> headers", as they are in outline-minor-mode.
>
> Since the format of those headers is very different, it might not be
> easy to support them, of course.

Well, the project 'Org-mode outside Org-mode' started with the very
simple yet generic idea to give source-code files the look&feel of
Org-mode files, and (in theory) it should work with all kinds of
major-modes - headlines are just outcommented Org-mode headlines with
whatever comment-syntax the major-mode at hand uses. 

Now I added two hacks - one for Org-mode itself (to enable the use of
'navi-mode' with Org-mode), the other for the oldschool lisp headers.
But its still oriented at Org-mode - only the headlines are matched, not
"^(" or so. 

But with 'navi-mode' its easy to get an overview over the all
definitions (or maybe just the function or just the variable
definitions) in a buffer. These are the keyword searches I defined for
Emacs Lisp in 'navi-mode':

,-------------------------------------------
| [KEY] : [SEARCH]
| ================
|                         a : ALL
|                         f : FUN
|                         v : VAR
|                         x : OBJ
|                         b : DB
|                         F : defun
|                         V : defvar
|                         C : defconst
|                         G : defgroup
|                         U : defcustom
|                         A : defadvice
|                         M : defmarcro
|                         D : defface
|                         S : defstruct
|                         L : defclass
|                         K : global-set-key
|                         T : add-to-list
|                         Q : setq
|                         H : add-hook
|                         O : hook
|                         X : lambda
|                         R : require
`-------------------------------------------

but this is customizable, try

,---------------------------------------------
| M-x customize-variable RET navi-key-mappings
| M-x customize-variable RET navi-keywords
`---------------------------------------------

for examples and explanations

One special thing about 'navi-mode' is that all 'free' ASCII printing
characters are by default bound to 'navi-generic-command', thus after
substracting the reserved one-key bindings from navi-mode itself, the
user still has lots of keys left to define his/her own keyword-searches,
and these key definitions are done by language. Here is e.g. what I
defined for picolisp-mode:

,------------------------------------
| [KEY] : [SEARCH]
| ================
|                         a : ALL
|                         f : FUN
|                         v : VAR
|                         x : OBJ
|                         b : DB
|                         D : de
|                         F : def
|                         C : class
|                         M : dm
|                         R : rel
|                         V : var
|                         X : extend
|                         O : obj
|                         J : object
|                         N : new
|                         S : symbols
|                         L : pool
|                         T : tree
|                         U : clause
|                         G : goal
|                         B : be
|                         P : prove
`------------------------------------
 
>> I tried this on several arbitrary .el files from Emacs itself and from
>> Org-mode, and it worked. Testing several files revealed that many Elisp
>> libraries did not make much use of outline structuring,
>
> Indeed, which is why it's not worth the trouble introducing a new convention.

I'm of course a bit biased towards the Ord-mode style headers, but with
the direct comparison to the 'oldschool headers' possible now, I still
find them much better when it comes to signaling 'this is a headline'
and 'this headline has level X'. But if one of those days one of my
libraries would make it into Emacs, it wouldn't be a problem to convert
them back to the oldschool syntax.

-- 
cheers,
Thorsten