Re: [O] [RFC] Org Minor Mode?

[Thorsten Jolitz]

Ilya Shlyakhter <address@hidden> 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