Re: [RFC] Org Minor Mode?

[Thorsten Jolitz <tjolitz@gmail.com>]

Bastien <bzg@gnu.org> writes:

Hi Bastien,

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> 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.
>
> (Did you look at `org-open-at-point' and the way it handles link in
> comments?  I don't think M-# M-# does the same.)

I looked at it, but to be honest, could not figure out what you are
referring to. Could you be more specific please (line number or so?)

>> There is definitely a cost, but the gain would be considerable too

> This is not about the number of lines to be edited or the man-hour we
> need to spend on this.  Rather about performance and maintainability.

Ok, I can see that the function call necessary to build the regexps
dynamically can be a problem here. 

Maybe instead of function calls some Backslash Constructs can be used to
derive regexp patterns that replace "^" and "$" in a way that they match
all or at least many comment-syntax (whats the plural of syntax?)?

,--------------------------------------------------------------------
| '\scode'
|     matches any character whose syntax is code. Here code is a
|     character that represents a syntax code: thus, 'w' for word
|     constituent, '-' for whitespace, '(' for open parenthesis, etc.
|     To represent whitespace syntax, use either '-' or a space
|     character. See Syntax Class Table, for a list of syntax codes
|     and the characters that stand for them.
`--------------------------------------------------------------------

e.g.

,---------------------------------------------------------------------
| Comment starters: '<'
| Comment enders: '>'
|     Characters used in various languages to delimit comments. Human
|     text has no comment characters. In Lisp, the semicolon (';')
|     starts a comment and a newline or formfeed ends one.
| [...]
| Generic comment delimiters: '!'
|     Characters that start or end a special kind of comment. Any
|     generic comment delimiter matches any generic comment delimiter,
|     but they cannot match a comment starter or comment ender;
|     generic comment delimiters can only match each other.
|    
|     This syntax class is primarily meant for use with the
|     syntax-table text property (see Syntax Properties). You can mark
|     any range of characters as forming a comment, by giving the
|     first and last characters of the range syntax-table properties
|     identifying them as generic comment delimiters.
`---------------------------------------------------------------------

For the Org star "*" maybe one could define a new category

,--------------------------------------------------------------------
| Categories provide an alternate way of classifying characters
| syntactically. You can define several categories as needed, then
| independently assign each character to one or more categories.
| Unlike syntax classes, categories are not mutually exclusive; it is
| normal for one character to belong to several categories.
`--------------------------------------------------------------------

and match them with

,---------------------------------------------------------------------
| '\cc'
|     matches any character whose category is c. Here c is a character
|     that represents a category: thus, 'c' for Chinese characters or
|     'g' for Greek characters in the standard category table. You can
|     see the list of all the currently defined categories with M-x
|     describe-categories <RET>. You can also define your own
|     categories in addition to the standard ones using the
|     define-category function (see Categories).
`---------------------------------------------------------------------

In the beginning, that category would only consist of (* ;).

This is quite low level and I haven't done anything on this level yet,
but it might be a way to stick with performant constant regexp strings,
but make them more general.

-- 
cheers,
Thorsten