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

[Thorsten Jolitz]

Bastien <address@hidden> writes:

Hi Bastien,

> Thorsten Jolitz <address@hidden> writes:
>
>>> I for one need to have a clearer picture of what such a minor mode
>>> would really do, without getting prematurily lost in the details of
>>> possible implementations.
>>
>> Its just a better and smarter outshine-mode (major-mode agnostic "Org
>> look&feel" for programming modes).
>
> But what would it *do*?  Can you give a simple example of a specific
> feature?  The one about editing source code in buffers other than Org
> buffers, maybe?

What outshine does already is the navigation, structure editing,
visibility cycling and fontification stuff in a major-mode agnostic
way. I would like to have the "Org action commands" too, i.e. all those
functions that make Org headers 'smart':

- todos
- priorities
- tags
- timestamps
- clocking
- properties
- ...

There is no real reason why the Org functions could not work on outside
of Org-mode since they a fundamentally based on regexp, only that those
regexps constants are hardcoded (^,$, and \\*) and the functions contain
many hardcoded regesp snippets too - thus they cannot deal with
outcommnented headers in programming buffers.

>> outshine, outorg and navi-mode are all in the mid-range of popular melpa
>> packages, so there seems to be some real demand ...
>
> No doubt!
>
>> I started with code (https://github.com/tj64/omm),
>
> (FWIW I don't think omm.el is a really good name, it's hard to guess
> what it is supposed to do.  You could use org-minor-mode.el and keep
> omm- as a prefix?)

that would be no problem

>> but faced the fundamental problem of hardcoded regexps (^, $, and
>> \\*) all over the Org sources that make Org functions fail on
>> outcommented headers and in outcommented text sections in general.
>>
>> The goals, ideas and even implementations (outshine, orgstruct) are
>> already there, a first intent to merge them into one library exists
>> (omm.el), but what to do about this core problem?
>
> Circumvent it?  Instead of try to adapt tons of Org features so that
> they run into other modes, we could try to emulate them in temporary
> buffers, where the peculiarities of the origin mode do not prevent
> Org functions from running -- see for example how `org-open-at-point'
> deals with links in comments.  This could be generalized to, e.g.,
> handle lists in Emacs lisp comments.

Thats currently possible with outorg.el, M-# M-# on a outshine subtree
or buffer is just the reverse of C-c ' on a source-block - it offers the
subtree of buffer in a temporary *outorg-edit-buffer* in full Org-mode
with the comment-section converted to text and the source-code enclosed
in source-blocks. 

So this works quite well already. But as outshine evolves, me and others
would like to have it more powerful and even more similar to
Org-mode. Then I start reimplementing features based on outline and
extensions, knowing that they are already there in Org-mode,
sophisticated and well tested. Thats a bit frustrating, especially since
it seems that its just a few chars in the regexps that inhibit using
Org-mode functions outside of org-mode. This would be easy to fix in a
small library, but since Org-mode is so big, this is really a political
thing since changing the regexps would cause more than 600 changes in
the sources and then require a (slightly) different approach to writing
regexps in the future. There is definitely a cost, but the gain would be
considerable too ...

-- 
cheers,
Thorsten