From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: [RFC] Org Minor Mode? Date: Thu, 29 May 2014 19:47:04 +0200 Message-ID: <87zji0xysn.fsf@gmail.com> References: <87ha61f4rk.fsf@gmail.com> <8738hlkn64.fsf@gmail.com> <87zjj9g87k.fsf@gmail.com> <877g5znrgl.fsf@bzg.ath.cx> <87y4xnzif9.fsf@gmail.com> <8738ft379k.fsf@bzg.ath.cx> <878uplim22.fsf@gmail.com> <87y4xl1mh5.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wq4QG-000862-HQ for emacs-orgmode@gnu.org; Thu, 29 May 2014 13:47:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wq4QA-0003NB-J2 for emacs-orgmode@gnu.org; Thu, 29 May 2014 13:47:24 -0400 Received: from plane.gmane.org ([80.91.229.3]:58723) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wq4QA-0003N1-Bk for emacs-orgmode@gnu.org; Thu, 29 May 2014 13:47:18 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Wq4Q8-00087G-Il for emacs-orgmode@gnu.org; Thu, 29 May 2014 19:47:16 +0200 Received: from g231233153.adsl.alicedsl.de ([92.231.233.153]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 May 2014 19:47:16 +0200 Received: from tjolitz by g231233153.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 May 2014 19:47:16 +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 Bastien writes: Hi Bastien, > Thorsten Jolitz 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 . 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