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: Sun, 14 Apr 2013 10:16:20 +0200 Message-ID: <87fvytil2j.fsf@gmail.com> References: <87hajhswdh.fsf@gmail.com> <87y5csu7ml.fsf@gmail.com> <87hajgu5bp.fsf@gmail.com> <87li8m3sny.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1365927398 4423 80.91.229.3 (14 Apr 2013 08:16:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Apr 2013 08:16:38 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 14 10:16:43 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 1URI77-0000fL-6I for ged-emacs-devel@m.gmane.org; Sun, 14 Apr 2013 10:16:41 +0200 Original-Received: from localhost ([::1]:56452 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URI76-00073b-Np for ged-emacs-devel@m.gmane.org; Sun, 14 Apr 2013 04:16:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URI71-00073J-68 for emacs-devel@gnu.org; Sun, 14 Apr 2013 04:16:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URI6z-0007Pt-KQ for emacs-devel@gnu.org; Sun, 14 Apr 2013 04:16:35 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:52533) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URI6z-0007Pn-AA for emacs-devel@gnu.org; Sun, 14 Apr 2013 04:16:33 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1URI6t-0000Qr-9G for emacs-devel@gnu.org; Sun, 14 Apr 2013 10:16:27 +0200 Original-Received: from g231235158.adsl.alicedsl.de ([92.231.235.158]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Apr 2013 10:16:27 +0200 Original-Received: from tjolitz by g231235158.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Apr 2013 10:16:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 113 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: g231235158.adsl.alicedsl.de User-Agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:bednuftejTc/jLHDDuS154Fglsw= 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:158898 Archived-At: Stefan Monnier 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