From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: [RFC] Org Minor Mode? Date: Fri, 25 Apr 2014 09:49:03 +0200 Message-ID: <87zjj9g87k.fsf@gmail.com> References: <87ha61f4rk.fsf@gmail.com> <8738hlkn64.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wdasz-0006Br-80 for emacs-orgmode@gnu.org; Fri, 25 Apr 2014 03:49:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wdasr-0006My-5R for emacs-orgmode@gnu.org; Fri, 25 Apr 2014 03:49:29 -0400 Received: from plane.gmane.org ([80.91.229.3]:48461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wdasq-0006Mn-Ur for emacs-orgmode@gnu.org; Fri, 25 Apr 2014 03:49:21 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Wdasl-00006b-V2 for emacs-orgmode@gnu.org; Fri, 25 Apr 2014 09:49:15 +0200 Received: from e178058074.adsl.alicedsl.de ([85.178.58.74]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Apr 2014 09:49:15 +0200 Received: from tjolitz by e178058074.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Apr 2014 09:49:15 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Ilya Shlyakhter writes: Hi Ilya, > On 4/10/2014 3:19 PM, Nicolas Goaziou wrote: >> I don't see why you would need the "full power of Org-mode" (whatever >> that means) in mere comments. > > There are actually many uses, especially if it becomes possible to > treat language elements (functions, classes etc) as outline elements > (cf. https://github.com/notestaff/outshine/blob/outshine-lang/outshine-lang.el > ). Sparse trees and agenda views could be used to find all code > elements related to a particular aspect of functionality, if items > related to that aspect are tagged with a tag. Sparse trees could show > just the public (interface) elements. Basically, outshine with the > full power of Org and the ability to treat language elements as > outline headings would add up to the first literate programming system > I'd call usable. I think outshine (or a true org-minor-mode) definitely has its merits when its more about "literate PROGRAMMING" rather than "LITERATE programming". I definitely liked your idea to use navi-mode regexps as additional outline elements - they can easily be defined by the users via customizable vars `navi-key-mappings' and `navi-keywords', cover a wide range of syntax elements, and would be defined once but used twice then. The most obvious choice for outlining would be the regexp stored in :FUN and called with 'f' in navi-mode, e.g. in elisp: #+begin_src emacs-lisp (defcustom navi-key-mappings '(("emacs-lisp" . ((:FUN . "f") ...))) #+end_src #+begin_src emacs-lisp (defcustom navi-keywords '(("emacs-lisp" . ((:FUN . "^[[:space:]]*(def[maus][^elt][a-z]*\\*? ") ...))) #+end_src That way somebody could define a set of predefined keyword searches for a programming language that is included in navi-mode.el (like I did for Emacs Lisp, PicoLisp, Org-mode and ESS/R) and users could modify it or add their own regexps and keybindings. Some of these regexps could then be reused in outshine for visiility cycling and other stuff. There are many Org features I would really like to have in outshine too, but I realized that reimplementing Org stuff in outshine would be kind of an uphill battle in the long run, so I would rather take what is there (orgstruct, outshine, outorg/poporg, navi) and merge it into a true org-minor-mode reusing existing Org-mode functionality. I have a pretty clear picture what is needed for an org-minor-mode, and started implementation in ,---------------------------- | https://github.com/tj64/omm `---------------------------- already. But I feel that this should be done together with the Org maintainers and the Org community, otherwise bad things could happen: - I write the whole thing (changing Org sources) and the maintainers say NO to it. - I write the whole thing (changing Org sources), the maintainers say NO to it, but I want it anyway and become the unvoluntary maintainer of an unmaintainable Org fork (nightmare). - I write the whole thing w/o changing Org sources (if that is possible), e.g. using advices, the Org people like it and reimplement it w/o advices, and my effort is wasted. So I would rather have a clear picture of the 'political situation' wrt to org-minor-mode and some technical discussion first. But anyway, I will not have time to work on this again before June. -- cheers, Thorsten