Re: [O] How to escape an asterisk on org-mode
Hi James, James Ryland Miller james.ryland.mil...@gmail.com writes: I'm trying to escape an asterisk character, i.e. * to use in regular text. I.e., The person wanted to say *BSD. And I don't want to use a verbatim or code block because monospace is not what I need. I've tried \* to escape the character and it doesn't work. I'm on Org 8.2.5h. There is currently no way to escape characters in this way. Using an asterisk like in your example should work fine -- except if the text after it makes it seem like the asterisk is actually markup. (e.g. The person wanted to say *BSD. Now this is bold* Whether an asterisk is treated as a symbol or as markup follows some rather complicated rules, but there are two simple rules that make the behavior predictable: 1. Asterisks intended for markup must occur right before and after the words that are to be printed in bold, i.e. *this is bold*, but * neither this* is, *nor this *. 2. Markup cannot span more than two lines: *this is not bold* HTH Albert -- Albert Krewinkel GPG: 8eed e3e2 e8c5 6f18 81fe e836 388d c0b2 1f63 1124
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Daimrod daim...@gmail.com writes: PS: The change about throwing an error when recentering a window that does not display the current buffer breaks ~37 tests in Org master branch, even with this fix. I need to digg this further. Err, what's the rational behind this change? It is meant to catch cases where recenter acts on the wrong window. Think of the cases where (recenter) is called from within a timer or a process filter function. See the discussion entitled comint-preoutput-filter-functions and flickering redisplay in TTY on emacs devel. -- Nico.
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Nicolas Richard theonewiththeevill...@yahoo.fr writes: Daimrod daim...@gmail.com writes: PS: The change about throwing an error when recentering a window that does not display the current buffer breaks ~37 tests in Org master branch, even with this fix. I need to digg this further. Err, what's the rational behind this change? It is meant to catch cases where recenter acts on the wrong window. Think of the cases where (recenter) is called from within a timer or a process filter function. See the discussion entitled comint-preoutput-filter-functions and flickering redisplay in TTY on emacs devel. Thanks! -- Daimrod/Greg
Re: [O] How to escape an asterisk on org-mode
Thank you very much. That was most informative. Sent from James Miller's iPhone. On Jun 12, 2014, at 3:01 AM, Albert Krewinkel tar...@moltkeplatz.de wrote: Hi James, James Ryland Miller james.ryland.mil...@gmail.com writes: I'm trying to escape an asterisk character, i.e. * to use in regular text. I.e., The person wanted to say *BSD. And I don't want to use a verbatim or code block because monospace is not what I need. I've tried \* to escape the character and it doesn't work. I'm on Org 8.2.5h. There is currently no way to escape characters in this way. Using an asterisk like in your example should work fine -- except if the text after it makes it seem like the asterisk is actually markup. (e.g. The person wanted to say *BSD. Now this is bold* Whether an asterisk is treated as a symbol or as markup follows some rather complicated rules, but there are two simple rules that make the behavior predictable: 1. Asterisks intended for markup must occur right before and after the words that are to be printed in bold, i.e. *this is bold*, but * neither this* is, *nor this *. 2. Markup cannot span more than two lines: *this is not bold* HTH Albert -- Albert Krewinkel GPG: 8eed e3e2 e8c5 6f18 81fe e836 388d c0b2 1f63 1124
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Daimrod daim...@gmail.com writes: Nicolas Richard theonewiththeevill...@yahoo.fr writes: Daimrod daim...@gmail.com writes: PS: The change about throwing an error when recentering a window that does not display the current buffer breaks ~37 tests in Org master branch, even with this fix. I need to digg this further. Err, what's the rational behind this change? It is meant to catch cases where recenter acts on the wrong window. Think of the cases where (recenter) is called from within a timer or a process filter function. See the discussion entitled comint-preoutput-filter-functions and flickering redisplay in TTY on emacs devel. Thanks! Okay, so is there another fix than `(when (eq (current-buffer) (window-buffer)))' or removing the call? If not, why does it raise an error instead of doing nothing silently? Best, -- Daimrod/Greg
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
I've now fixed this in the maint and master branch of Org's repository. Firmly waiting for warnings from the CAR and CDR random checks! -- Bastien
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Daimrod daim...@gmail.com writes: Daimrod daim...@gmail.com writes: Nicolas Richard theonewiththeevill...@yahoo.fr writes: Daimrod daim...@gmail.com writes: PS: The change about throwing an error when recentering a window that does not display the current buffer breaks ~37 tests in Org master branch, even with this fix. I need to digg this further. Err, what's the rational behind this change? It is meant to catch cases where recenter acts on the wrong window. Think of the cases where (recenter) is called from within a timer or a process filter function. See the discussion entitled comint-preoutput-filter-functions and flickering redisplay in TTY on emacs devel. Thanks! Okay, so is there another fix than `(when (eq (current-buffer) (window-buffer)))' or removing the call? If not, why does it raise an error instead of doing nothing silently? I've read the fix in org-mode and I understand that it was a silly question. Please ignore it. Best, -- Daimrod/Greg
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Daimrod daim...@gmail.com writes: I've read the fix in org-mode and I understand that it was a silly question. Please ignore it. Well, the whole thread gave me the guts to dive in and to find, as often, how tiny the challenge was -- so thanks for soft-prodding! -- Bastien
[O] Alternative to arrow keys (more ergonomic)?
Im using Shift+RightArrow and Shift+LeftArrow quite often to change the scheduled or deadline dates of a task in my agenda view. As I have a normal large keyboard (where the arrow keys are between the alphanumeric block and the numeric keypad like here: http://www.microsoft.com/hardware/_base_v1//products/wireless-desktop-3000/mk_wd3000_otherviews01.jpg ). So the arrow key is difficult to reach and forces me to leave the QUERTZ keys with the right hand. Can I define an additional key or key combination which does the same thing like RightArrow and is easier to reach? Which one would be available in the agenda view? Kind regards Martin
Re: [O] Alternative to arrow keys (more ergonomic)?
Hi Martin, Martin Beck elwood...@web.de writes: I'm using Shift+RightArrow and Shift+LeftArrow quite often to change the scheduled or deadline dates of a task in my agenda view. As I have a normal large keyboard (where the arrow keys are between the alphanumeric block and the numeric keypad like here: http://www.microsoft.com/hardware/_base_v1//products/wireless-desktop-3000/mk_ wd3000_otherviews01.jpg ). So the arrow key is difficult to reach and forces me to leave the QUERTZ keys with the right hand. Can I define an additional key or key combination which does the same thing like RightArrow and is easier to reach? Which one would be available in the agenda view? I have the (totally useless) CapsLock key of my keyboard remapped to Hyper, which allows me to use an extra modifier for emacs commands. For your case after you have a Hyper key you could make your own arrow keys without your right fingers moving away from J K L ; where they belong: #+BEGIN_SRC emacs-lisp (global-set-key (kbd H-i) 'previous-line) (global-set-key (kbd H-k) 'next-line) (global-set-key (kbd H-j) 'left-char) (global-set-key (kbd H-l) 'right-char) #+END_SRC and for org: #+BEGIN_SRC emacs-lisp (define-key org-mode-map (kbd H-S-i) 'org-shiftup) (define-key org-mode-map (kbd H-S-k) 'org-shiftdown) (define-key org-mode-map (kbd H-S-j) 'org-shiftleft) (define-key org-mode-map (kbd H-S-l) 'org-shiftright) #+END_SRC In Linux I use xmodmap for the remapping of the CapsLock key. While you are at it you can also remap the Alt key to Cntrl and the Super to Meta, to that you press C- commands with your left thumb and not with your left pinky, avoiding the common emacs pinky problem. Best, Jorge. PS: http://i.stack.imgur.com/2kbJv.jpg http://www.splitreason.com/Product_Images/4e3477bef139.jpg PPS: to be fair some very fast typists use CapsLock (http://seanwrona.com/typing.php)
Re: [O] Alternative to arrow keys (more ergonomic)?
jorge.a.alf...@gmail.com (Jorge A. Alfaro-Murillo) writes: Hi, I have the (totally useless) CapsLock key of my keyboard remapped to Hyper, which allows me to use an extra modifier for emacs commands. For your case after you have a Hyper key you could make your own arrow keys without your right fingers moving away from J K L ; where they belong: #+BEGIN_SRC emacs-lisp (global-set-key (kbd H-i) 'previous-line) (global-set-key (kbd H-k) 'next-line) (global-set-key (kbd H-j) 'left-char) (global-set-key (kbd H-l) 'right-char) #+END_SRC and for org: #+BEGIN_SRC emacs-lisp (define-key org-mode-map (kbd H-S-i) 'org-shiftup) (define-key org-mode-map (kbd H-S-k) 'org-shiftdown) (define-key org-mode-map (kbd H-S-j) 'org-shiftleft) (define-key org-mode-map (kbd H-S-l) 'org-shiftright) #+END_SRC In Linux I use xmodmap for the remapping of the CapsLock key. While you are at it you can also remap the Alt key to Cntrl and the Super to Meta, to that you press C- commands with your left thumb and not with your left pinky, avoiding the common emacs pinky problem. Just out of curiosity - did you try this on the console (without X) too? -- cheers, Thorsten
Re: [O] Alternative to arrow keys (more ergonomic)?
Thorsten Jolitz tjol...@gmail.com writes: Just out of curiosity - did you try this on the console (without X) too? Xmodmap does not work without X, at least I suppose that is what the X stands for =) If someone knows how to remap outside of X please let me know. Since I use emacs not in X in my phone, my workaround is to create a hyper key in another place (F6 is a good place for the keyboard of JuiceSSH in Android). It is not really a modifier, so to press 'H-j', you actually do 'F6 j', that is 'F6' followed by 'j', but I guess that is as good as you can get with a keyboard onscreen without installing a super tiny keyboard (e.g. Hacker's Keyboard). #+BEGIN_SRC emacs-lisp (defun hyperify (prompt) (let ((e (read-event))) (vector (if (numberp e) (logior (lsh 1 24) e) (if (memq 'hyper (event-modifiers e)) e (add-event-modifier H- e)) (defun add-event-modifier (string e) (let ((symbol (if (symbolp e) e (car e (setq symbol (intern (concat string (symbol-name symbol (if (symbolp e) symbol (cons symbol (cdr e) (define-key key-translation-map (kbd f6) 'hyperify) #+END_SRC Best, Jorge.
[O] proposal to have ignoreheading tags/properties
In using org-mode, there is one problem that has always irked me (and is apparently also closely related to the FAQ How do I ignore a headline?). When I am writing something, I sometimes want to group things by concept or by work to be done, or any other number of groupings. BUT I do not want these groupings to be part of the exported document itself. In fact, I would like it to be as if the grouping did not exist at all (i.e. a headline that is ignored). The problem with using an ignored headline for grouping things is that it still does have an effect on exported document structure, in that all of the elements contained inside / in the scope of the ignored headline still keep their depth (one level deeper than the level of the ignored headline). What I want is for the nested items to have their levels all promoted by one, so that it's truly as if the ignored headline wasn't there at all, and that it invisibly wrapped around a group of items without requiring them to have a deeper level. Perhaps this could be done by use of an ignoreheading and an ignoreheadingpromote tag (one promotes the level of contained items, another doesn't), or some equivalent set of properties that could be set on a headline. Would there be any chance that something like this could be built in to org-mode? I think it would make it far more flexible in terms of organizing things, making this organization process orthogonal to the selection of sections/subsections of a document.
Re: [O] How to escape an asterisk on org-mode
Hello,
James Miller james.ryland.mil...@gmail.com writes:
Thank you very much. That was most informative.
For completeness, you can escape an asterisk in Org using entities, in
this case \ast{}, or \star{}:
The person wanted to say \ast{}BSD. Now this is bold*
Unfortunately, for obvious reasons, this will not work in verbatim
snippets, i.e, ~...~ and =...=, which is why at some point, Org will
need to allow escaping ~ and = there.
Regards,
--
Nicolas Goaziou
Re: [O] Alternative to arrow keys (more ergonomic)?
jorge.a.alf...@gmail.com (Jorge A. Alfaro-Murillo) writes: Thorsten Jolitz tjol...@gmail.com writes: Just out of curiosity - did you try this on the console (without X) too? Xmodmap does not work without X, at least I suppose that is what the X stands for =) I know, thats why I asked. If someone knows how to remap outside of X please let me know. In Archlinux, I copied console keymap ,- | de-latin1-nodeadkeys `- adapted it to my emacs needs, saved it and put ,-- | KEYMAP=de-latin1-nodeadkeys-emacs `-- in my /etc/vconsole.conf. It looks somehow like this: ,-- | # de-latin1-nodeadkeys-emacs.map: German keymap with special keybindings for Emacs | | include de-latin1.map | | # control keycode 7 = Control_asciicircum | keycode 13 = apostrophe grave | keycode 27 = plus asterisk asciitilde | # keycode 41 = asciicircum degree | | # corresponding keys in de-latin1.map: | # keycode 13 = dead_acute dead_grave | # keycode 27 = plus asterisk dead_tilde | # keycode 41 = dead_circumflex degree | | # unterste Zeile: | keycode 29 = AltGr AltGr AltGr AltGr | [...] | etc etc `-- Would be interesting if (and how) it works to actually define and use a hyper-key on the console, because even the standard modifiers like C-, M- and don't always work, especially when combined (see 'org on a tty' in the manual) or in combination with S-. Since I use emacs not in X in my phone, my workaround is to create a hyper key in another place (F6 is a good place for the keyboard of JuiceSSH in Android). It is not really a modifier, so to press 'H-j', you actually do 'F6 j', that is 'F6' followed by 'j', but I guess that is as good as you can get with a keyboard onscreen without installing a super tiny keyboard (e.g. Hacker's Keyboard). #+BEGIN_SRC emacs-lisp (defun hyperify (prompt) (let ((e (read-event))) (vector (if (numberp e) (logior (lsh 1 24) e) (if (memq 'hyper (event-modifiers e)) e (add-event-modifier H- e)) (defun add-event-modifier (string e) (let ((symbol (if (symbolp e) e (car e (setq symbol (intern (concat string (symbol-name symbol (if (symbolp e) symbol (cons symbol (cdr e) (define-key key-translation-map (kbd f6) 'hyperify) #+END_SRC sounds interesting ... -- cheers, Thorsten
Re: [O] proposal to have ignoreheading tags/properties
Mark Edgington edgi...@gmail.com writes: In using org-mode, there is one problem that has always irked me (and is apparently also closely related to the FAQ How do I ignore a headline?). When I am writing something, I sometimes want to group things by concept or by work to be done, or any other number of groupings. BUT I do not want these groupings to be part of the exported document itself. In fact, I would like it to be as if the grouping did not exist at all (i.e. a headline that is ignored). The problem with using an ignored headline for grouping things is that it still does have an effect on exported document structure, in that all of the elements contained inside / in the scope of the ignored headline still keep their depth (one level deeper than the level of the ignored headline). What I want is for the nested items to have their levels all promoted by one, so that it's truly as if the ignored headline wasn't there at all, and that it invisibly wrapped around a group of items without requiring them to have a deeper level. Perhaps this could be done by use of an ignoreheading and an ignoreheadingpromote tag (one promotes the level of contained items, another doesn't), or some equivalent set of properties that could be set on a headline. Would there be any chance that something like this could be built in to org-mode? I think it would make it far more flexible in terms of organizing things, making this organization process orthogonal to the selection of sections/subsections of a document. In a tree structure, when ignoring the parent node, it seems only logical that the siblings are ignored too. You seem to use the wrong tool for the task (headlines), this looks like a perfect use case for TAGS, i.e. define your (concept) groups as tags. If these tags are not part of `org-export-exclude-tags' they won't affect exporting, but you can still use them to build your agenda or a sparse tree or so. -- cheers, Thorsten
Re: [O] proposal to have ignoreheading tags/properties
Thorsten Jolitz tjolitz at gmail.com writes: In a tree structure, when ignoring the parent node, it seems only logical that the siblings are ignored too. You seem to use the wrong tool for the task (headlines), this looks like a perfect use case for TAGS, i.e. define your (concept) groups as tags. If these tags are not part of `org-export-exclude-tags' they won't affect exporting, but you can still use them to build your agenda or a sparse tree or so. Why do you suppose this is the wrong tool? It is a quite natural and sensible tool, because it allows grouping, folding, and nesting collections of items together. I cannot do that with tags. If you don't like the idea of having a headline serve this purpose, then perhaps we can invent a new kind of pseudo-headline which behaves in this way. How would you propose to use tags alone to do something like the following which allows folding and unfolding the contents, without a lot of extra work? -- for example: * Chapters about Topic A :pseudo: ** Chapter 1 Title ** Chapter 2 Title * Chapters about Topic B :pseudo: ** Chapter 3 Title List of interesting things: *** items relevant to X :pseudo: - item 1 - item 2 - item 3 *** items relevant to Y :pseudo: - item 4 - item 5 Another example would be, say, if you wanted to divide up some kind of text-file (e.g. source code, or prose), dividing it into groupings that make sense to you, but not wanting to actually bring these changes into the document's exported structure. Here's an example of a letter: * Addresses / date :pseudo: 123 Cherry Lane City, ST 12345 October 5, 2014 Ms. Jane Doe Accounts Payable * Greeting :pseudo: Dear Ms. Johnson: * Body :pseudo: It has come to my attention that .. * Closing:pseudo: Sincerely, John Doe * Postscript :pseudo: P.S. . Perhaps one could make it so that when a headline bullet (sequence) has a '#' character tacked on after the sequence, it is no longer a headline, but a summary node having the property that it promotes the levels of all its children. It doesn't much matter to me *how* one makes such a node, but I think the availability of nodes/headlines like this is important. In any case, it's not clear that this is the wrong tool. I would use it, and for me (and presumably others) it would be the right (kind of) tool. Furthermore tags are limited by their brevity -- with a pseudo headline I can describe a concept or category with much more detail / clarity.
Re: [O] proposal to have ignoreheading tags/properties
Ken Mankoff mank...@gmail.com writes: Another common (for me) example is to have a heading called * Appendix in a paper, and then the LaTeX \appendix command. The Org heading is just for me. It should not be exported. All headings below the \appendix command are Org sub-sections but should be promoted to \section in the final document. then IMO it should be , | * Appendix | ** Latex Command :noexport: | \appendix | ** Subsec1 | ** Subsec2 ... ` This is very common ,--- | * Level 1 | text | ** Level 2 | text | ** Level 2 `--- but often not very good. The text under Level 1 might deserve its own subsection, and then things become easier and more consistent. -- cheers, Thorsten
Re: [O] proposal to have ignoreheading tags/properties
Mark Edgington edgi...@gmail.com writes: In using org-mode, there is one problem that has always irked me (and is apparently also closely related to the FAQ How do I ignore a headline?). When I am writing something, I sometimes want to group things by concept or by work to be done, or any other number of groupings. BUT I do not want these groupings to be part of the exported document itself. In fact, I would like it to be as if the grouping did not exist at all (i.e. a headline that is ignored). The problem with using an ignored headline for grouping things is that it still does have an effect on exported document structure, in that all of the elements contained inside / in the scope of the ignored headline still keep their depth (one level deeper than the level of the ignored headline). What I want is for the nested items to have their levels all promoted by one, so that it's truly as if the ignored headline wasn't there at all, and that it invisibly wrapped around a group of items without requiring them to have a deeper level. Perhaps this could be done by use of an ignoreheading and an ignoreheadingpromote tag (one promotes the level of contained items, another doesn't), or some equivalent set of properties that could be set on a headline. Would there be any chance that something like this could be built in to org-mode? I think it would make it far more flexible in terms of organizing things, making this organization process orthogonal to the selection of sections/subsections of a document. I just ran across this need myself, and updated an old solution to work with the new exporter. See the thread and my solution at the following. http://lists.gnu.org/archive/html/emacs-orgmode/2014-06/msg00238.html -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] proposal to have ignoreheading tags/properties
+1 to the OP. On 2014-06-12 at 13:32, Thorsten Jolitz wrote: In a tree structure, when ignoring the parent node, it seems only logical that the siblings are ignored too. I'm found myself in all of the following situations: 1. I want the heading and everything below not-exported 2. I want the heading not-exported, but the content exported. 1. I don't care if the sub-headings are kept or moved up a level 2. I do care - I want the sub-headings to remain as-is. 3. I do care - I want the sub-headings to be promoted. 3. I want the heading and the heading-level content not-exported, but sub-heading and their content exported You seem to use the wrong tool for the task (headlines), this looks like a perfect use case for TAGS, i.e. define your (concept) groups as tags. If these tags are not part of `org-export-exclude-tags' they won't affect exporting, but you can still use them to build your agenda or a sparse tree or so. A simple example where tags don't work, nothing to do with agenda. Some paper formats (Nature, for example) do not allow headings or sub-headings. It is just 2 pages of text. But it is certainly nice to write the paper and organize thoughts in sections and sub-sections. This is case 2.0 above. Each heading is tagged :noexport and it is not exported, but the content (text, figures, lists) below the heading is exported. I'm not sure how tags would help here, other than the tag of :noexport. Another common (for me) example is to have a heading called * Appendix in a paper, and then the LaTeX \appendix command. The Org heading is just for me. It should not be exported. All headings below the \appendix command are Org sub-sections but should be promoted to \section in the final document. -k.
Re: [O] proposal to have ignoreheading tags/properties
On 2014-06-12 at 14:11, Thorsten Jolitz wrote: Ken Mankoff mank...@gmail.com writes: Another common (for me) example is to have a heading called * Appendix in a paper, and then the LaTeX \appendix command. The Org heading is just for me. It should not be exported. All headings below the \appendix command are Org sub-sections but should be promoted to \section in the final document. then IMO it should be , | * Appendix | ** Latex Command :noexport: | \appendix | ** Subsec1 | ** Subsec2 ... ` I'm confused how this creates a correct LaTeX document. The \appendix command is not exported, since that section was tagged :noexport:, in which case, what is the point of having \appendix? I *need* the LaTeX command exported. It changes things in the remainder of the LaTeX document. A section titled Appendix, which is what your text above creates, does not create a correct LaTeX document. Furthermore, Subsec1 and Subsec2 need to be promoted, either in Org or in the export. , | * Appendix :noexportheading:promotesubheading: | \appendix | ** Subsec1 | ** Subsec2 ` The above works, assuming that noexportheading doesn't export the heading, but does export the content (\appendix), and the promotesubheading does what you would expect. -k.
[O] can show inline images anymore in orgmode
Hi all i have a weird problem. in the last few weeks i cant get orgmode to show inline images anymore. when i use org-toggle-inline-images i get the following error: progn: Wrong type argument: stringp, nil [2 times] can anyone help me to debug this? best Z.
Re: [O] proposal to have ignoreheading tags/properties
Hi Eric, hi all, 2014ko ekainak 12an, Eric Schulte-ek idatzi zuen: I just ran across this need myself, and updated an old solution to work with the new exporter. See the thread and my solution at the following. http://lists.gnu.org/archive/html/emacs-orgmode/2014-06/msg00238.html It’s really wonderful that you and the other members of the org community have devoted lots of careful effort to this problem. See also: - http://orgmode.org/worg/org-hacks.html#ignoreheadline - http://mid.gmane.org/87lhvvjoo0@gmx.us - http://mid.gmane.org/87zjii42k9@ucl.ac.uk Many of the solutions work approximately, but not in all circumstances – see the discussion on worg. Searching my email archives for the string “ignoreheading” in 2014, I see threads from May 14, May 9, May 6, March 27, March 17, and Jan 7 on this topic. It seems reasonable to ask whether this constitutes enough user interest to make this a core feature. The benefits would include: - the code can be made robust by the combined effort of those interested - the feature can be incorporated into the test suite, so it won’t accidentally break in the future - it will be more “discoverable” in the org info manual (which almost certainly gets a larger audience than worg) What do you think? -- Aaron Ecay
Re: [O] proposal to have ignoreheading tags/properties
2014-06-12 20:54 GMT+02:00 Aaron Ecay aarone...@gmail.com: Hi Eric, hi all, 2014ko ekainak 12an, Eric Schulte-ek idatzi zuen: I just ran across this need myself, and updated an old solution to work with the new exporter. See the thread and my solution at the following. http://lists.gnu.org/archive/html/emacs-orgmode/2014-06/msg00238.html It’s really wonderful that you and the other members of the org community have devoted lots of careful effort to this problem. See also: - http://orgmode.org/worg/org-hacks.html#ignoreheadline - http://mid.gmane.org/87lhvvjoo0@gmx.us - http://mid.gmane.org/87zjii42k9@ucl.ac.uk Many of the solutions work approximately, but not in all circumstances – see the discussion on worg. Searching my email archives for the string “ignoreheading” in 2014, I see threads from May 14, May 9, May 6, March 27, March 17, and Jan 7 on this topic. It seems reasonable to ask whether this constitutes enough user interest to make this a core feature. The benefits would include: - the code can be made robust by the combined effort of those interested - the feature can be incorporated into the test suite, so it won’t accidentally break in the future - it will be more “discoverable” in the org info manual (which almost certainly gets a larger audience than worg) I also ran across this need. What I had in mind was that certain todo types would be treated as inline. For instance, if P was a member of this hypothetical org-inline-todo-keywords, then * P a paragraph some contents would be rendered as some contents by the exporter, no matter the backend. Such a feature is more generic and would be useful in other contexts ; and the LaTeX-related issues discussed in this thread would be solved using something like * INLINE appendix \appendix * Appendix 1 Cheers, Nicolas
Re: [O] proposal to have ignoreheading tags/properties
2014-06-12 21:21 GMT+02:00 Nicolas Girard girard.nico...@gmail.com: 2014-06-12 20:54 GMT+02:00 Aaron Ecay aarone...@gmail.com: Hi Eric, hi all, I also ran across this need. What I had in mind was that certain todo types would be treated as inline. For instance, if P was a member of this hypothetical org-inline-todo-keywords, then * P a paragraph some contents would be rendered as some contents by the exporter, no matter the backend. Such a feature is more generic and would be useful in other contexts ; and the LaTeX-related issues discussed in this thread would be solved using something like * INLINE appendix \appendix * Appendix 1 Or, even better: rendering *both* the headline *and* the body of lnline nodes as inline contents too: * INLINE My inline contents -- My inline contents * INLINE \appendix -- \appendix
Re: [O] proposal to have ignoreheading tags/properties
On 2014-06-12 at 15:21, Nicolas Girard wrote: I also ran across this need. What I had in mind was that certain todo types would be treated as inline. ... Such a feature is more generic and would be useful in other contexts ; and the LaTeX-related issues discussed in this thread would be solved using something like * INLINE appendix \appendix * Appendix 1 In your example, I cannot collapse * Appendix 1 under INLINE appendix. I need to add a * to it, and it is now at the incorrect level when exporting. There is no point in having the INLINE appendix here. I'm not sure how this feature using TODO keywords is more generic (also, more generic than what?). TODO types have a very specific functionality, and I think one can only have 1 TODO type. So if you wanted to have * INLINE TODO foo or * WAITING INLINE bar It would not work. Implementing this feature as tags allows one to use existing TODO items. Tags are already a more generic item so adding a new behavior isn't that dramatic (and is it new? :noexport: already exists), and multiple tags are supported. It seems a better place for the implementation. I vote for the following tags: + :noexport: Does not export item, content, and children. + :ignoreheading: Does not export heading. Exports content and children. + :ignorecontent: Does not export heading or content. Does export children. + :ignorebranch: Does not export heading, content, or children. + :promotesubheadings: Promotes children headings, regardless of exporting this heading or not Note that :ignorebranch: is the same as :noexport but is a more consistent naming scheme. Ignoring and promotion are two separate items and can be used together or exclusively for maximum number of export behaviors. In this case, a modified version of your example might look like this: * Appendix :ignoreheading:promotesubheadings: \appendix ** Appendix 1 ** Appendix 2 -k.
Re: [O] proposal to have ignoreheading tags/properties
2014-06-12 21:26 GMT+02:00 Ken Mankoff mank...@gmail.com: On 2014-06-12 at 15:21, Nicolas Girard wrote: I vote for the following tags: + :noexport: Does not export item, content, and children. + :ignoreheading: Does not export heading. Exports content and children. + :ignorecontent: Does not export heading or content. Does export children. + :ignorebranch: Does not export heading, content, or children. + :promotesubheadings: Promotes children headings, regardless of exporting this heading or not Agreed. That would rock !
Re: [O] org-mime spurious alternative
Sébastien Delafond sdelaf...@gmail.com writes:
Hello,
from Debian bug #751014 (http://bugs.debian.org/751014):
When org-mime-library is set to semi, org-mime generates a spurious
alternative section around the HTML part. This is due to two bugs in
the function org-mime-multipart:
1. it attempts to put a multipart/alternative section around the HTML,
where it should be putting a multipart/related part;
2. it tests for the presence of images by doing (when images ...),
which triggers when images is the empty string (somebody has been
programming in Python or Javascript?).
To repeat:
M-x load-library org-mime RET
M-: (setq org-mime-library 'semi) RET
M-x wl RET
w
Then insert some text below the separator line, and do
M-x org-mime-htmlize
and see the breakage.
Cheers,
--Seb
Does the attached patch fix these problems?
Thanks,
Eric
From 9af18107bd82fb9778b87b5891b1772fb847cc74 Mon Sep 17 00:00:00 2001
From: Eric Schulte schulte.e...@gmail.com
Date: Thu, 12 Jun 2014 14:40:32 -0400
Subject: [PATCH] fix semi-backend bug in org-mime
* contrib/lisp/org-mime.el (org-mime-multipart): Fix bug in use of the
semi org-mime-library when converting emails to HTML.
---
contrib/lisp/org-mime.el | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/contrib/lisp/org-mime.el b/contrib/lisp/org-mime.el
index 5f874d9..44bf91b 100644
--- a/contrib/lisp/org-mime.el
+++ b/contrib/lisp/org-mime.el
@@ -163,10 +163,13 @@ and images in a multipart/related part.
('semi (concat
-- alternative-{\n
-- [[text/plain]]\n plain
- (when images (concat -- alternative-{\n))
--- [[text/html]]\n html
- images
- (when images (concat -- }-alternative\n))
+ (if (and images ( (length images) 0))
+ (concat -- related-{\n
+ -- [[text/html]]\n html
+ images
+ -- }-related\n)
+ (concat -- [[text/html]]\n html
+ images))
-- }-alternative\n))
('vm ?)))
--
2.0.0
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] How to specify the tangled comment to be the location of the noweb ref definition instead of where it was tangled?
How do I make the code comment specify the actual location of the source block ref, not just where it was expanded and tangled? Currently inserting comments around snippets of code expanded with noweb is not supported. You may be able to fake this through the clever use of variables along the lines of the following, #+begin_src sh :var start=(line-number-at-pos (point)) :results scalar cat EOF # started at $start foo bar baz EOF #+end_src or an implementation of optional wrappers for noweb-expanded snippets would probably start with the `org-babel-expand-noweb-references' function. Best, Eric -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] [bug][babel] noweb gotcha
Charles Berry ccbe...@ucsd.edu writes: The following , | #+PROPERTY: tangle yes | | #+NAME: print-abc | #+BEGIN_SRC emacs-lisp | (format | %s abc) | #+END_SRC | | #+NAME: print-def | #+BEGIN_SRC emacs-lisp | (concat | def ) | #+END_SRC | | #+BEGIN_SRC emacs-lisp :noweb yes | print-abc | print-def | #+END_SRC ` tangles as , | (format | %s abc) | | (concat | def ) | | (format | %s abc) | (concat | ) ` Note that def disappeared from (concat ...). FWIW, adding quotes inside the constant string in org-babel-noweb-wrap: \\([^ \\t\n][^\]+?[^ \\t]\\|[^ \\t\n]\\) fixes this instance. Does this raise any error, or fail silently? Thanks, Eric HTH, Chuck -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] A simple org tangle and weave makefile
Grant Rettke g...@wisdomandwonder.com writes: Hi, My goals was to have a simple makefile to tangle and weave a document; so org-mk was out of scope. Just wondering; how could I have done it better? ## INIT=.emacs.el $(INIT): TC3F.org time emacs --batch --no-init-file --load .org-mode.emacs.el --find-file TC3F.org --funcall org-babel-tangle --kill TC3F.html: $(INIT) time emacs --batch --no-init-file --load .org-mode.emacs.el --find-file TC3F.org --funcall org-html-export-to-html --kill clean: rm $(INIT) rm TC3F.html ## Kind regards, I don't know if this is better, but its closer to what I use locally. EMACS=emacs BATCH_EMACS=$(EMACS) --batch -Q -l init.el %.html: %.org $(BATCH_EMACS) $*.org -f org-html-export-to-html %.tex: %.org init.el $(BATCH_EMACS) $*.org -f org-latex-export-to-latex %.el: %.org init.el $(BATCH_EMACS) $*.org -f org-babel-tangle # two fancier alternatives to the above which provide a default file # name and encode language information %.el: %.org init.el $(BATCH_EMACS) $*.org \ --eval '(org-babel-tangle nil $@ (quote emacs-lisp))' %.sh: %.org init.el $(BATCH_EMACS) $*.org \ --eval '(org-babel-tangle nil $@ (quote bash))' Grant Rettke | AAAS, ACM, ASA, FSF, IEEE, SIAM, Sigma Xi g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --ThompsonH -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] proposal to have ignoreheading tags/properties
I also ran across this need. What I had in mind was that certain todo types would be treated as inline. For instance, if P was a member of this hypothetical org-inline-todo-keywords, then * P a paragraph some contents would be rendered as some contents by the exporter, no matter the backend. Such a feature is more generic and would be useful in other contexts ; and the LaTeX-related issues discussed in this thread would be solved using something like * INLINE appendix \appendix * Appendix 1 Why TODO types rather than a tag? IMO using a TODO type would conflate task management and document structuring. What do you think about the attached patch which should add this functionality to the core. From 5a41eae2af24097ec9c1507926af6f6fab8f2628 Mon Sep 17 00:00:00 2001 From: Eric Schulte schulte.e...@gmail.com Date: Thu, 12 Jun 2014 16:11:04 -0400 Subject: [PATCH] export removes INLINE heading and promotes subtree * lisp/ox.el (org-export-remove-and-promote-children-of-inline-headlines): A new function. (org-export-as): Include `org-export-remove-and-promote-children-of-inline-headlines' in the export process. --- lisp/ox.el | 26 ++ 1 file changed, 26 insertions(+) diff --git a/lisp/ox.el b/lisp/ox.el index 4bfef52..961d795 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -2320,6 +2320,29 @@ tree is modified by side effect and returned by the function. (plist-get info prop) info +(defun org-export-remove-and-promote-children-of-inline-headlines (data info) + Remove inline headlines and promote their children. +DATA is the parse tree. INFO is a plist containing export +options. Each headline tagged as INLINE will be removed +retaining its contents, and promoting any children headlines by a +single level. + (org-element-map data org-element-all-elements +(lambda (object) + (when (and (equal 'headline (org-element-type object)) + (or (member inline (org-element-property :tags object)) + (member INLINE (org-element-property :tags object +(mapc (lambda (el) +;; recursively promote all nested headlines +(org-element-map el 'headline + (lambda (el) +(when (equal 'headline (org-element-type el)) + (org-element-put-property el +:level (1- (org-element-property :level el)) +(org-element-insert-before el object)) + (cddr object)) +(org-element-extract-element object))) +info nil org-element-all-elements)) + (defun org-export--remove-uninterpreted-data-1 (data info) Change uninterpreted elements back into Org syntax. DATA is a parse tree or a secondary string. INFO is a plist @@ -3124,6 +3147,9 @@ Return code as a string. ;; Handle left-over uninterpreted elements or objects in ;; parse tree and communication channel. (org-export-remove-uninterpreted-data tree info) + ;; Remove headlines tagged as inline and promote their + ;; children. + (org-export-remove-and-promote-children-of-inline-headlines tree info) ;; Call options filters and update export options. We do not ;; use `org-export-filter-apply-functions' here since the ;; arity of such filters is different. -- 2.0.0 Cheers, Nicolas -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] patch: Oracle engine for SQL blocks
Hi John,
This patch looks great. Given it's length FSF copyright assignment will
be required so please begin that process and when it is complete I'll be
very happy to apply this patch.
Thanks,
Eric
John Dell'Aquila del...@ml1.net writes:
Hi,
This patch makes Oracle a supported database for SQL source code
blocks:
- separate or unified logins, take your pick of:
:dbuser user :dbpassword password :dbhost connect_id
:dbuser user/password@connect_id
:cmdline user/password@connect_id
- support for :colnames on/off
- helpful error messages in minibuffer if execution fails
- good looking result block (most of the time)
I've tested this extensively on Windows 7. It only needs the sqlplus
executable and file redirection, so it should work everywhere.
I am willing to execute an FSF copyright assignment.
Regards,
John
From 08e01124a7f65fbdeec8d14f0e7b555bb1565ad9 Mon Sep 17 00:00:00 2001
From: John Dell'Aquila del...@ml1.net
Date: Tue, 10 Jun 2014 20:33:31 -0500
Subject: [PATCH] ob-sql.el: Implement Oracle engine
* lisp/ob-sql.el (org-babel-execute:sql): Add Oracle support with
proper error handling.
---
lisp/ob-sql.el | 41 +
1 file changed, 41 insertions(+)
diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index 7b85df8..42a03a1 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -128,11 +128,31 @@ This function is called by
`org-babel-execute-src-block'.
(org-babel-process-file-name in-file)
(org-babel-process-file-name out-file)
(or cmdline )))
+ ('oracle (format
+ sqlplus -S -L %s %s %s %s
+ (if (and dbuser dbpassword dbhost) ; build login
+ (format %s/%s@%s dbuser dbpassword dbhost)
+ (or dbuser )) ; or just pass dbuser
+ (or cmdline )
+ (org-babel-process-file-name in-file)
+ (org-babel-process-file-name out-file)))
(t (error No support for the %s SQL engine engine)
(with-temp-file in-file
(insert
(case (intern engine)
('dbi /format partbox\n)
+ ('oracle
+ ;; Inject suitable SQL*Plus settings
+ (concat
+(if colnames-p
+set heading on underline '-'\n ; column headings
+ set heading off\n) ; no headings
+set colsep '|' tab off\n ; | between columns, no tabs
+set linesize 150\n; Oracle default width
+set newpage none\n; no page breaks
+set feedback off\n; no informational messages
+prompt ~_SentineL~!\n ; marker for post-processing
+))
(t ))
(org-babel-expand-body:sql body params)))
(message command)
@@ -155,6 +175,27 @@ This function is called by
`org-babel-execute-src-block'.
(insert -\n)
(setq header-delim -)
(write-file out-file)
+ ((eq (intern engine) 'oracle)
+(with-temp-buffer
+ (insert-file-contents out-file)
+ ;; Delete up to and including sentinel (anything before
+ ;; sentinel is garbage from user's login.sql script)
+ (goto-char (point-min))
+ (if (re-search-forward ~_SentineL~!\n nil t)
+ (delete-region (point-min) (point)))
+ ;; Anything left?
+ (if (eq (buffer-size) 0)
+ (if (string-match ; body)
+ (error No rows selected)
+(error No rows selected (need final ; perhaps?
+ ;; Scan for *last* Oracle or SQL*Plus error, include up
+ ;; to 5 preceding lines in error message
+ (goto-char (point-max))
+ (if (re-search-backward ^\\(ORA\\|SP2\\)-[0-9]+: nil t)
+ (let ((p (line-end-position)))
+(forward-line -5)
+(error (buffer-substring-no-properties (point) p
+ (write-file out-file)))
(t
;; Need to figure out the delimiter for the header row
(with-temp-buffer
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] [bug][babel] noweb gotcha
On Thu, 12 Jun 2014, Eric Schulte wrote: Charles Berry ccbe...@ucsd.edu writes: The following , | #+PROPERTY: tangle yes | | #+NAME: print-abc | #+BEGIN_SRC emacs-lisp | (format | %s abc) | #+END_SRC | | #+NAME: print-def | #+BEGIN_SRC emacs-lisp | (concat | def ) | #+END_SRC | | #+BEGIN_SRC emacs-lisp :noweb yes | print-abc | print-def | #+END_SRC ` tangles as , | (format | %s abc) | | (concat | def ) | | (format | %s abc) | (concat | ) ` Note that def disappeared from (concat ...). FWIW, adding quotes inside the constant string in org-babel-noweb-wrap: \\([^ \\t\n][^\]+?[^ \\t]\\|[^ \\t\n]\\) fixes this instance. Does this raise any error, or fail silently? Thanks, Eric Alas, it fails silently -- producing the erroneous output. I guess the issue is that `(re-search-forward (org-babel-noweb-wrap) nil t)' finds quoted expressions like 1. abc 2. (concat abc ) FWIW, (re-search-forward (org-babel-noweb-wrap \\([^ \\t\n][^\]+?[^ \\t]\\|[^ \\t\n]\\) ) nil t) (adding quotes to the [^...] bits) takes care of example 2. Not sure if example 1 is a feature or a bug - I sometimes use things like text-I-want so maybe modifying the regex is good enough? OTOH, no-such-chunk has no effect. Maybe checking that the reference actually resolves is better than tweaking the regexes. HTH, Chuck
Re: [O] can show inline images anymore in orgmode
Xebar Saram zelt...@gmail.com writes: Hi all Hi, i have a weird problem. in the last few weeks i cant get orgmode to show inline images anymore. when i use org-toggle-inline-images i get the following error: progn: Wrong type argument: stringp, nil [2 times] can anyone help me to debug this? 1. M-x toggle-debug-on-error RET 2. report the backtrace FWIW, I don't have this error using the latest version (HEAD) of org-mode. Regards, -- Daimrod/Greg
Re: [O] controling width of graphviz source block result
Hi Nicolas, Thank you for your earlier comments. In order to adjust the scaling of a graphic generated by a R source block I am doing this ... ** adjusting scaling of a figure generated from source #+begin_src R :results graphics silent :file foo2.pdf :exports results plot(c(1:10), c(10:1)) #+end_src #+attr_latex: :width .35\textwidth file:foo2.pdf While this does work, it is a wee bit unsatisfying to type foo2.pdf twice. Is there a better way to apply the latex keyword to the results? Many thanks, regcl Nicolas Goaziou n.goaz...@gmail.com writes: Hello, regcl re...@channing.harvard.edu writes: So I am understanding from your answer that attribues only modify the next immediate thing in the .org document, and do not persist, so to speak. things are called elements in Org lingo and attributes are called affiliated keywords. So, yes, affiliated keywords apply to the element right after them. But I have discovered that it works to stack them up like this ... #+ATTR_HTML: :width 1000 #+ATTR_ODT: :width 15 :height 15 [[file:gnus.png]] ... so I am a little confused. Could you please clarify? Both keywords are affiliated keywords. There is only one element in this example (a paragraph containing a single link). Affiliated keywords apply to the next element, not the next affiliated keyword. For more information, see: http://orgmode.org/worg/dev/org-syntax.html or the comments at the beginning of org-element.el. Regards,
Re: [O] proposal to have ignoreheading tags/properties
2014-06-12 22:13 GMT+02:00 Eric Schulte schulte.e...@gmail.com: Why TODO types rather than a tag? IMO using a TODO type would conflate task management and document structuring. Agreed. What do you think about the attached patch which should add this functionality to the core. Seems fine to me ! I created a public repository containing a Makefile and a bunch of unit tests here: https://github.com/ngirard/org-inline-headings-tests. Cheers, Nicolas
Re: [O] [bug][babel] noweb gotcha
Charles C. Berry ccbe...@ucsd.edu writes: On Thu, 12 Jun 2014, Eric Schulte wrote: Charles Berry ccbe...@ucsd.edu writes: The following , | #+PROPERTY: tangle yes | | #+NAME: print-abc | #+BEGIN_SRC emacs-lisp | (format | %s abc) | #+END_SRC | | #+NAME: print-def | #+BEGIN_SRC emacs-lisp | (concat | def ) | #+END_SRC | | #+BEGIN_SRC emacs-lisp :noweb yes | print-abc | print-def | #+END_SRC ` tangles as , | (format | %s abc) | | (concat | def ) | | (format | %s abc) | (concat | ) ` Note that def disappeared from (concat ...). FWIW, adding quotes inside the constant string in org-babel-noweb-wrap: \\([^ \\t\n][^\]+?[^ \\t]\\|[^ \\t\n]\\) fixes this instance. Does this raise any error, or fail silently? Thanks, Eric Alas, it fails silently -- producing the erroneous output. I guess the issue is that `(re-search-forward (org-babel-noweb-wrap) nil t)' finds quoted expressions like 1. abc 2. (concat abc ) FWIW, (re-search-forward (org-babel-noweb-wrap \\([^ \\t\n][^\]+?[^ \\t]\\|[^ \\t\n]\\) ) nil t) (adding quotes to the [^...] bits) takes care of example 2. Not sure if example 1 is a feature or a bug - I sometimes use things like text-I-want so maybe modifying the regex is good enough? OTOH, no-such-chunk has no effect. Maybe checking that the reference actually resolves is better than tweaking the regexes. So it is currently possible to raise errors when noweb references don't resolve through the use of the `org-babel-noweb-error-all-langs' variable. I just added `org-babel-noweb-error-all-langs' which may be set to raise such errors regardless of the language of the code block. Best, Eric HTH, Chuck -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] proposal to have ignoreheading tags/properties
Nicolas Girard girard.nico...@gmail.com writes: 2014-06-12 22:13 GMT+02:00 Eric Schulte schulte.e...@gmail.com: Why TODO types rather than a tag? IMO using a TODO type would conflate task management and document structuring. Agreed. What do you think about the attached patch which should add this functionality to the core. Seems fine to me ! Great, I'll leave actual application and possible adjustment to Nicolas Goaziou as he knows best how the exporter should grow. I created a public repository containing a Makefile and a bunch of unit tests here: https://github.com/ngirard/org-inline-headings-tests. This looks great, perhaps you could fold the unit tests into the testing directory Org-mode repository and then share them as a patch? Best, Eric Cheers, Nicolas -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] proposal to have ignoreheading tags/properties
On 2014-06-12 at 16:13, Eric Schulte wrote: What do you think about the attached patch which should add this functionality to the core. Why inline? Org already has inline TODO items which is a different thing. I don't think the word inline signifies that a heading will or won't be exported and/or its children promoted. -k.
Re: [O] proposal to have ignoreheading tags/properties
Ken Mankoff mank...@gmail.com writes: On 2014-06-12 at 16:13, Eric Schulte wrote: What do you think about the attached patch which should add this functionality to the core. Why inline? Org already has inline TODO items which is a different thing. I don't think the word inline signifies that a heading will or won't be exported and/or its children promoted. Can you suggest a more intuitive/appropriate tag name? I'm not personally partial to inline, it was just the first thing that occurred to me. Previous implementations of similar behavior used the tag prelim. Thanks, Eric -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] proposal to have ignoreheading tags/properties
if i were a newcomer i'd wonder how these affected babel, agenda, etc. maybe noexport, noexportheading, noexportcontent, exportpromotechildren? On 6/12/14, Ken Mankoff mank...@gmail.com wrote: + :noexport: Does not export item, content, and children. + :ignoreheading: Does not export heading. Exports content and children. + :ignorecontent: Does not export heading or content. Does export children. + :ignorebranch: Does not export heading, content, or children. + :promotesubheadings: Promotes children headings, regardless of exporting this heading or not
Re: [O] proposal to have ignoreheading tags/properties
Mark Edgington edgi...@gmail.com writes: In using org-mode, there is one problem that has always irked me (and is apparently also closely related to the FAQ How do I ignore a headline?). When I am writing something, I sometimes want to group things by concept or by work to be done, or any other number of groupings. BUT I do not want these groupings to be part of the exported document itself. In fact, I would like it to be as if the grouping did not exist at all (i.e. a headline that is ignored). The problem with using an ignored headline for grouping things is that it still does have an effect on exported document structure, in that all of the elements contained inside / in the scope of the ignored headline still keep their depth (one level deeper than the level of the ignored headline). What I want is for the nested items to have their levels all promoted by one, so that it's truly as if the ignored headline wasn't there at all, and that it invisibly wrapped around a group of items without requiring them to have a deeper level. Perhaps this could be done by use of an ignoreheading and an ignoreheadingpromote tag (one promotes the level of contained items, another doesn't), or some equivalent set of properties that could be set on a headline. Would there be any chance that something like this could be built in to org-mode? I think it would make it far more flexible in terms of organizing things, making this organization process orthogonal to the selection of sections/subsections of a document. It looks like a groundswell for remove-andor-promote tags for headlines, but for the sake of argument let me propose the use of blocks. It seems to me that something like a generic block (a block that does nothing but delete its begin/end delimiters on export) fits the use-case better: #+BEGIN_BLOCK Here's a list of reasons why blocks make sense 1. They group together content that should go together, but don't constitute a part of document structure. They're a little like notecards in Scrivener 2. You can fold them like headlines, and re-order them with org-meta(up|down) 3. You could put arbitrary text after the begin block declaration, as if it were ignored headline text. 4. I can't think of any more reasons, except that this seems like the right weight for this kind of feature. #+END_BLOCK Anyway, just being argumentative... E
Re: [O] proposal to have ignoreheading tags/properties
Hi Eric, On 2014-06-12 at 20:46, Eric Schulte wrote: Can you suggest a more intuitive/appropriate tag name? I'm not personally partial to inline, it was just the first thing that occurred to me. Previous implementations of similar behavior used the tag prelim. I posted the following before. I think you might not be getting all the emails I post to the list. For example, I commented that INLINE as a TODO keyword didn't make sense to me using a similar explanation to your reply to that same email. I have used your implementation from last week using prelim but changed the word, because as with inline, I don't associate the word prelim with the behavior being implemented. -k. I vote for the following tags: + :noexport: Does not export item, content, and children. + :ignoreheading: Does not export heading. Exports content and children. + :ignorecontent: Does not export heading or content. Does export children. + :ignorebranch: Does not export heading, content, or children. + :promotesubheadings: Promotes children headings, regardless of exporting this heading or not Note that :ignorebranch: is the same as :noexport but is a more consistent naming scheme. Ignoring and promotion are two separate items and can be used together or exclusively for maximum number of export behaviors.
Re: [O] proposal to have ignoreheading tags/properties
Eric Schulte schulte.eric at gmail.com writes: Ken Mankoff mankoff at gmail.com writes: I don't think the word inline signifies that a heading will or won't be exported and/or its children promoted. Can you suggest a more intuitive/appropriate tag name? Would it be possible / sensible to allow user-specified aliases for the different canonical tags (whatever they turn out to be), just like it's possible to specify tags other than noexport which will not be exported?
Re: [O] proposal to have ignoreheading tags/properties
Eric Abrahamsen eric at ericabrahamsen.net writes: It looks like a groundswell for remove-andor-promote tags for headlines, but for the sake of argument let me propose the use of blocks. It seems to me that something like a generic block (a block that does nothing but delete its begin/end delimiters on export) fits the use-case better: Consider the following: * Test #+begin_block abc * test2 #+begin_block def * test3 ** test4 #+end_block ** test5 #+end_block Some remarks on this, and on blocks vs. headlines: - For me, the above example ends up being indented very poorly with org-indent-mode active. Also folding the nested headlines swallows up the end-block lines. - I find that it's difficult to identify what belongs to what block, and the need to have both start and end lines to delineate the blocks is a bit more noisy and can be a pain to work with (what if I want to remove the abc frame -- I will need not only to delete the begin line, but also to locate where the corresponding end line is, and delete it as well). - creating a block (manually, at least) requires more effort than creating a headline (= more RSI). - It also may be convenient at times to be able to remove the :promote:, etc. tags in order to have the exporter include the grouping as part of the exported document's structure. - Likewise, what if I want to add a :noexport: tag so that all of the content is ignored -- easy with headlines, more work to do the same thing with a block.
Re: [O] proposal to have ignoreheading tags/properties
Mark Edgington edgi...@gmail.com writes: Eric Abrahamsen eric at ericabrahamsen.net writes: It looks like a groundswell for remove-andor-promote tags for headlines, but for the sake of argument let me propose the use of blocks. It seems to me that something like a generic block (a block that does nothing but delete its begin/end delimiters on export) fits the use-case better: Consider the following: * Test #+begin_block abc * test2 #+begin_block def * test3 ** test4 #+end_block ** test5 #+end_block FWIW, I think the above example is actually illegal Org syntax -- it's going to result in breakage in many ways, not just this case. Some remarks on this, and on blocks vs. headlines: - For me, the above example ends up being indented very poorly with org-indent-mode active. Also folding the nested headlines swallows up the end-block lines. - I find that it's difficult to identify what belongs to what block, and the need to have both start and end lines to delineate the blocks is a bit more noisy and can be a pain to work with (what if I want to remove the abc frame -- I will need not only to delete the begin line, but also to locate where the corresponding end line is, and delete it as well). - creating a block (manually, at least) requires more effort than creating a headline (= more RSI). - It also may be convenient at times to be able to remove the :promote:, etc. tags in order to have the exporter include the grouping as part of the exported document's structure. - Likewise, what if I want to add a :noexport: tag so that all of the content is ignored -- easy with headlines, more work to do the same thing with a block. Yup, I don't really have any argument against these above points -- I think it's mostly a matter of use-case. The inconvenience of the block approach could easily be remedied with a few extra functions: something like org-wrap-region-in-block and org-delete-enclosing-block would probably do it. But your second two objections are just a matter of a difference in use-case: you want something more flexible and powerful. My suggestion is just a lighter-weight alternate if (it's a possibility) the tag-based approach gets nixed... E
