Bastien <b...@gnu.org> writes: Hi Bastien,
> Thorsten Jolitz <tjol...@gmail.com> 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
