[O] [PATCH] Make the point visible when jumping to the mark
An example of the problem: * headline-1 ** one of many headlines I want to remain folded... ** headline *** headline The point starts here. I set a mark on this line. Then I fold headline-1. This becomes invisible. * headline-2 I move the point here. After I'm done here, I want to go back to my mark. I do C-u C-space (pop-to-mark-command), but it doesn't go to the mark. Instead, it takes me to the end of the still folded headline-1. To get back to my mark without globally unfolding everything requires tediously unfolding each headline and sub-headline until the marked location is exposed. There are some other non-org commands that would have this same problem (isearch, bookmark-jump, save-place), but org-mode has code to fix them. org-mark-ring-goto also handles this. I followed those examples and wrote a patch. It is attached. - Ian Kelling From 066595dd9350f06a1df2e99a341f96782ac8dfed Mon Sep 17 00:00:00 2001 From: Ian Kelling ian...@gmail.com Date: Sun, 15 Sep 2013 00:32:08 -0700 Subject: [PATCH] Make the point visible when jumping to the mark * lisp/org.el advise `pop-global-mark', `exchange-point-and-mark', and `pop-global-mark' with `org-show-context', as appropriate. TINYCHANGE --- lisp/org.el | 21 + 1 file changed, 21 insertions(+) diff --git a/lisp/org.el b/lisp/org.el index 8e970a1..30b87d9 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -23903,6 +23903,27 @@ To get rid of the restriction, use \\[org-agenda-remove-restriction-lock]. (outline-invisible-p))) (org-show-context 'bookmark-jump))) +(eval-after-load simple + '(defadvice set-mark-command (after org-make-visible activate) + Make the point visible with `org-show-context'. + (org-mark-jump-unhide))) + +(eval-after-load simple + '(defadvice exchange-point-and-mark (after org-make-visible activate) + Make the point visible with `org-show-context'. + (org-mark-jump-unhide))) + +(eval-after-load simple + '(defadvice pop-global-mark (after org-make-visible activate) + Make the point visible with `org-show-context'. + (org-mark-jump-unhide))) + +(defun org-mark-jump-unhide () + Make the point visible with `org-show-context' after jumping to the mark. + (and (derived-mode-p 'org-mode) + (outline-invisible-p) + (org-show-context 'mark-goto))) + ;; Make session.el ignore our circular variable (defvar session-globals-exclude) (eval-after-load session -- 1.8.3.1
Re: [O] [export] Easy way to make children of Beamer frames generate list items?
On Sat, Sep 14, 2013 at 09:49:18PM -0500, John Hendy wrote: In any case, I'm mostly in agreement that Org's changed and thus the file structure should change... but not all of us use the git and/or snapshot Org version with regular frequency and thus I expect a fair amount of trickling in of users surprised at the incompatibility. As I outlined towards the end of my earlier message, it is not possible (at least easily with some config magic) to get back the old behaviour with the new exporter. Maybe then we should have an FAQ stating so and outlining how one could make the format switch (again, a possible path provided in my previous message). Do you think that would be a good idea? If so, I'll add a short FAQ with a pointer to this thread for now. We can clean it up later. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] [export] Easy way to make children of Beamer frames generate list items?
Dear all, many thanks for your extensive feedback. You more than answered my question: I conclude for myself that it is not a good idea to use Org tree entries if one wants list items. This was accidentally supported by the old exporter, but with the new exporter it makes sense to manually (or automatically, with some scripting or macro-recording) convert tree entries to plain lists. This is what I will now do with my Beamer presentations. Cheers, Christoph -- Christoph Lange, School of Computer Science, University of Birmingham http://cs.bham.ac.uk/~langec/, Skype duke4701 → Mathematics in Computer Science Special Issue on “Enabling Domain Experts to use Formalised Reasoning”; submission until 31 October. http://cs.bham.ac.uk/research/projects/formare/pubs/mcs-doform/
Re: [O] [export] Easy way to make children of Beamer frames generate list items?
On 15.9.2013, at 13:07, Christoph LANGE math.semantic@gmail.com wrote: Dear all, many thanks for your extensive feedback. You more than answered my question: I conclude for myself that it is not a good idea to use Org tree entries if one wants list items. This was accidentally supported by the old exporter, but with the new exporter it makes sense to manually (or automatically, with some scripting or macro-recording) convert tree entries to plain lists. This is what I will now do with my Beamer presentations. Dear Christopher, thank you for this summary, which will help others to see the balance that had to be struck with the new exporter. Regards - Carsten Cheers, Christoph -- Christoph Lange, School of Computer Science, University of Birmingham http://cs.bham.ac.uk/~langec/, Skype duke4701 → Mathematics in Computer Science Special Issue on “Enabling Domain Experts to use Formalised Reasoning”; submission until 31 October. http://cs.bham.ac.uk/research/projects/formare/pubs/mcs-doform/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Jumping from source block to Org block ...
aditya siram aditya.si...@gmail.com writes: I've included new versions of both patches with most of the changes you suggested. I guess you'll apply the longer one when you've been notified by the FSF? Once you receive your confirmation from the FSF please let Bastien or Carsten know, and they'll add you to the list of contributors at [1]. Then I'll apply this patch. Is this a one-time deal that covers future patches or do I have to do this with every patch that's over 15 lines long? This is a one time deal that covers not only future patches to Org-mode, but future patches to any part of Emacs. Thanks again, Thanks! -deech On Sat, Sep 14, 2013 at 10:53 AM, aditya siram aditya.si...@gmail.comwrote: Thanks for your feedback and your work on org-babel! Oops, the maintain-point was a hold-over and isn't actually used in the code. I'll remove it. I will incorporate your suggestions. However, regarding the cascading if statements, how would I use `cond` when the predicates are `and`ed and when I need different behavior in the else cases? On Sat, Sep 14, 2013 at 10:44 AM, Eric Schulte schulte.e...@gmail.comwrote: aditya siram aditya.si...@gmail.com writes: Attached is a patch that fixes a bug with jumping from source block back to the Org file. The problem is that the current detangling behavior does not take the :padlline flag into account. This stopped. Hopefully this is helpful to others ... -deech Hi deech, Please see the Org-mode contribution instructions at [1]. A patch of this length would require that you fill out the FSF copyright assignment paperwork before the patch could be applied. As for the content of the patch, my only question is why do you add an optional maintain-point argument to `org-babel-tangle-jump-to-org'? Is there ever a case when you would not want to maintain the point? Of much less importance I have a couple of stylistic notes about the code which are largely unrelated to its functionality and are included to make future changes easier to read and because I'm a cranky old lisp programmer. - you should indent the code s.t. no lines are longer than 79 characters - comments which float after code (e.g., ;; end of first delimiter) should only use 1 ; character - the series of if statements (if should-be-padded... if possibly-padded... if actually-padded...) would be more legible if written as a single `cond' form. Thanks for this change. It appears to pass all tests, so after the above have been addressed I'd be very happy to apply it. Thanks for contributing, this is much appreciated! If you have the time and inclination to include a test which fails without this patch applied that would be icing on the cake. Best, Footnotes: [1] http://orgmode.org/worg/org-contribute.html -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D Footnotes: [1] http://orgmode.org/worg/org-contribute.html -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Jumping from source block to Org block ...
aditya siram aditya.si...@gmail.com writes: Thanks for your feedback and your work on org-babel! I'm happy you're finding it useful. Oops, the maintain-point was a hold-over and isn't actually used in the code. I'll remove it. I will incorporate your suggestions. However, regarding the cascading if statements, how would I use `cond` when the predicates are `and`ed and when I need different behavior in the else cases? Maybe cascading if statements are the best thing here. Perhaps changing the order of the then/else branches could ensure the conditionals are still visible from the branches, but this is an exceedingly minor point. I guess any use of cond could easily get overly verbose. Please disregard this suggestion. Cheers, On Sat, Sep 14, 2013 at 10:44 AM, Eric Schulte schulte.e...@gmail.comwrote: aditya siram aditya.si...@gmail.com writes: Attached is a patch that fixes a bug with jumping from source block back to the Org file. The problem is that the current detangling behavior does not take the :padlline flag into account. This stopped. Hopefully this is helpful to others ... -deech Hi deech, Please see the Org-mode contribution instructions at [1]. A patch of this length would require that you fill out the FSF copyright assignment paperwork before the patch could be applied. As for the content of the patch, my only question is why do you add an optional maintain-point argument to `org-babel-tangle-jump-to-org'? Is there ever a case when you would not want to maintain the point? Of much less importance I have a couple of stylistic notes about the code which are largely unrelated to its functionality and are included to make future changes easier to read and because I'm a cranky old lisp programmer. - you should indent the code s.t. no lines are longer than 79 characters - comments which float after code (e.g., ;; end of first delimiter) should only use 1 ; character - the series of if statements (if should-be-padded... if possibly-padded... if actually-padded...) would be more legible if written as a single `cond' form. Thanks for this change. It appears to pass all tests, so after the above have been addressed I'd be very happy to apply it. Thanks for contributing, this is much appreciated! If you have the time and inclination to include a test which fails without this patch applied that would be icing on the cake. Best, Footnotes: [1] http://orgmode.org/worg/org-contribute.html -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] [export] Easy way to make children of Beamer frames generate list items?
Hi Christoph and others, On Sun, Sep 15, 2013 at 01:41:32PM +0200, Carsten Dominik wrote: On 15.9.2013, at 13:07, Christoph LANGE math.semantic@gmail.com wrote: Dear all, many thanks for your extensive feedback. You more than answered my question: I conclude for myself that it is not a good idea to use Org tree entries if one wants list items. This was accidentally supported by the old exporter, but with the new exporter it makes sense to manually (or automatically, with some scripting or macro-recording) convert tree entries to plain lists. This is what I will now do with my Beamer presentations. Dear Christopher, thank you for this summary, which will help others to see the balance that had to be struck with the new exporter. I added these entries on Worg. Do you think this helps future users with similar questions? http://orgmode.org/worg/org-faq.html#sec-18-1 http://orgmode.org/worg/exporters/beamer/ox-beamer.html#migration Thanks, -- Suvayu Open source is the future. It sets us free.
Re: [O] removing Figure x from a caption
On Sat, Sep 14, 2013 at 10:28 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: Matt Price mopto...@gmail.com writes: Unfortunatey, I'm exporting to HTML (deck.js) not Beamer. I guess I still on't understand how to use beamer -- I tried it just now and it seemed to produce a very plain pdf, not a slideshow at all. sigh. It may or may not have worked. I cannot tell from your comment. It depends on what you mean by plain PDF and slideshow. Beamer is a document style and a collection of macros for LaTeX. The output of LaTeX will be a PDF file typically. For a beamer document, the PDF output is a set of pages where each page corresponds to a single slide. The slide show is the sequence of these PDF pages. Whether this corresponds to your meaning of a slide show, I cannot tell. I hope that makes some sort of sense... Yes, it does make sense, thank you Eric. The PDF document produced was not a one-heading-per-page slideshow, but a more ordinary PDF with continuous flow from page to page. I have no doubt there are numerous errors in my setup -- I don't use LaTex at all so I haven't realy investigated what woud be necesary to fix them. Thanks! Matt -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.1.1-17-gf76e8c
[O] customizing preamble for org-preview-latex-fragment
How can I change the default packages used in the latex file generated by org-preview-latex-fragment ? Julien.
Re: [O] [export] Should sidewaystable option automatically add rotating package?
2013/9/15 Carsten Dominik carsten.domi...@gmail.com: Does anyone know about conflicts arising from loading wrapfig and rotating? Not that I know of.
Re: [O] [export] Easy way to make children of Beamer frames generate list items?
On Sun, Sep 15, 2013 at 5:57 AM, Suvayu Ali fatkasuvayu+li...@gmail.com wrote: On Sat, Sep 14, 2013 at 09:49:18PM -0500, John Hendy wrote: In any case, I'm mostly in agreement that Org's changed and thus the file structure should change... but not all of us use the git and/or snapshot Org version with regular frequency and thus I expect a fair amount of trickling in of users surprised at the incompatibility. As I outlined towards the end of my earlier message, it is not possible (at least easily with some config magic) to get back the old behaviour with the new exporter. Maybe then we should have an FAQ stating so and outlining how one could make the format switch (again, a possible path provided in my previous message). My response was geared toward Is there a handy workaround in the mean time so that Christoph can get quicker access to his materials than Can we program Org-mode to handle all legacy forms of input to the exporter. Sorry if it seemed that I was requesting an official fix. It was more of a prompt for someone clever with LaTeX and/or the new exporter guts to possibly give him some magic to convert lower headlines to list while he changes over vs. simply saying, No. You can't do that. Now I understand it really just isn't possible at all, and that's a good answer to have as well :) Do you think that would be a good idea? If so, I'll add a short FAQ with a pointer to this thread for now. We can clean it up later. I'm not sure on this. I was thinking about your answer some more, and perhaps I'm trying to be empathetic with those who aren't subscribed to the mailing list and thus weren't submerged in constant discussions about the new exporter, opportunities to try it on an experimental branch, tons of warnings that it's coming, and so on. Then again, I countered myself with realizing that it's not like extreme computer novices are installing this on a daily basis -- each of us probably had to stumble on it when looking for outlining program alternatives, either already knew or endured Emacs to use Org (like me), and are aware of things like mailing lists and StackOverflow. So... maybe my concern is unfounded. Org users are most likely more familiar than many with reading manuals/help files, seeking help, etc. I think there's a decent amount out there about the new exporter, but it can seem a bit scattered between the manual and Worg. When I wanted to constantly refer back to the upgrade instructions page that Bastien/Nicolas created, I was constantly googling upgrade Org 8.0. At the time, I don't think it worked with just upgrade and no version. So things like that make me wonder how easy it is to find these things without sort of knowing where they are. Alright -- enough wind out of me. All that said, yes, more info and references/links can't hurt. That's probably the most helpful thing for newcomers/non-mailing-list people -- something smack-dab on the Org-mode webpage about FAQs or troubleshooting. Thanks for the explanations and dialog! John Cheers, -- Suvayu Open source is the future. It sets us free.
[O] [PATCH] Fix incorrect time calculation for org-extend-today-until
During the extra hours of org-extend-today-until, when org-clock-mode-line-total is 'today, the clocked time shown in the modeline is wrong. It ignores all previously clocked time, when it should add them starting from the past day beyond org-extend-today-until hours. This also affects clock tables. The problem can be reproduced in emacs with the following code, as long as the current time is not between 11 PM and 12 AM: (progn (require 'org-clock) (setq org-clock-mode-line-total 'today) (setq org-extend-today-until 23) (format-time-string %a %D %l:%M %p (org-clock-get-sum-start))) expected result: A date of yesterday, time of 11:00 PM Actual result: A date of today, time of 11:00 PM Note this patch only fixes a bug where org-extend-today-until is already used. - Ian Kelling From 619572e221cafc17f0a1c33654eb22d7ca5f4d89 Mon Sep 17 00:00:00 2001 From: Ian Kelling ian...@gmail.com Date: Sun, 15 Sep 2013 08:03:24 -0700 Subject: [PATCH] Fix incorrect time calculation for org-extend-today-until * lisp/org-clock.el Fix bad date math. Affects mode line and clock tables. TINYCHANGE --- lisp/org-clock.el | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 9f22562..3195dc1 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1368,10 +1368,12 @@ decides which time to use. (current-time)) ((equal cmt today) (setq msg-extra showing today's task time.) - (let* ((dt (decode-time (current-time - (setq dt (append (list 0 0 0) (nthcdr 3 dt))) - (if org-extend-today-until - (setf (nth 2 dt) org-extend-today-until)) + (let* ((dt (decode-time (current-time))) + (hour (nth 2 dt)) + (day (nth 3 dt))) + (if ( hour org-extend-today-until) (setf (nth 3 dt) (1- day))) + (setf (nth 2 dt) org-extend-today-until) + (setq dt (append (list 0 0) (nthcdr 2 dt))) (apply 'encode-time dt))) ((or (equal cmt all) (and (or (not cmt) (equal cmt auto)) -- 1.8.3.1
[O] Normalized Parse-Tree readable by other Lisps (Languages)
Hi List, I now got a first working version of code that transforms the parse-tree produced by `org-element-parse-buffer' into a normalized form - in the sense that special Emacs Lisp syntax is converted into plain standard Lisp syntax: The transformation steps can be seen in this code excerpt from the core function ,--- | (defun iorg-normalize-parse-tree | (optional data buffer-or-file rest args) ... ) `--- , | [ ... ] | ;; do the transformation | (normalized-parse-tree-as-string | (iorg--fix-read-syntax |(iorg--tag-org-data-element | (iorg--add-children-list | (iorg--unwind-circular-list | (iorg--tag-elems-with-id-attributes |(if map? |(org-element-map |dat typ fun inf 1st-match no-recur with-affil) | dat | buf | ;; upcase nil and t? | (if preserve-nil-and-t-p | normalized-parse-tree-as-string | (iorg--nil-and-t-to-uppercase normalized-parse-tree-as-string ` The parse-tree produced by `org-element-parse-buffer' is optionally mapped first, then 1. each element is tagged with a :elem-id attribute 2. circular list references are unwind, i.e. ':parent #2#' becomes ':parent 2' (with parent having :elem-id 2) 3. in addition to its :parent attribute, each headline gets a :children attribute (a list of sub-headlines) 4. the top 'org-data' element is tagged with meta-data and a unique ID, making each parse-tree unique and easy to reference. 5. finally, other object references (#1=\text\ and #1#) as well as read syntax for text with properties (#(\text\ 0 4 ...)) is fixed in the sense that the three constructs are replaced by three functions: - (hashtag '(\text\ 0 4 ...)) - (hashtag-equal '(1 \text\)) - (enclosing-hashtag 1) These should be defined as functions in the target language, e.g. PicoLisp, and should produce the original Emacs Lisp read syntax when evaluated. 6. as a last optional step, nil and t are upcased to NIL and T I can now directly import an org parse-tree into PicoLisp after this transformation, as a PicoLisp list, and start working on it. Since PicoLisp is a pure and simple List, I would guess that the transformed parse-tree can be read as-is by other Lisps too (untested), and maybe by non-lisps that can read lists. The only remaining special syntax is ':keyword'. Thereby one could avoid to write many Org-mode parsers for other Lisps (languages), but rather use org-element (the de-facto specification of Org-mode) for parsing and then import the transformed parse-tree as described. The code is here, still under development: [[https://github.com/tj64/iorg/blob/master/picoLisp/iorg/el/iorg.el][iorg.el]] PS I know I could have used ox.el for the transformation, but decided to work directly on the parse-tree - for the good or for the bad, who knows... -- cheers, Thorsten
Re: [O] [PATCH] Fix incorrect time calculation for org-extend-today-until
Updated patch, fixed commit message format. From 0c23ccb9b00fd42f830f5a7472e2980b93c6040f Mon Sep 17 00:00:00 2001 From: Ian Kelling ian...@gmail.com Date: Sun, 15 Sep 2013 08:03:24 -0700 Subject: [PATCH] Fix incorrect time calculation for `org-extend-today-until' * lisp/org-clock.el (org-clock-get-sum-start): Fix bad date math, affecting mode line and clock tables. TINYCHANGE --- lisp/org-clock.el | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 9f22562..3195dc1 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1368,10 +1368,12 @@ decides which time to use. (current-time)) ((equal cmt today) (setq msg-extra showing today's task time.) - (let* ((dt (decode-time (current-time - (setq dt (append (list 0 0 0) (nthcdr 3 dt))) - (if org-extend-today-until - (setf (nth 2 dt) org-extend-today-until)) + (let* ((dt (decode-time (current-time))) + (hour (nth 2 dt)) + (day (nth 3 dt))) + (if ( hour org-extend-today-until) (setf (nth 3 dt) (1- day))) + (setf (nth 2 dt) org-extend-today-until) + (setq dt (append (list 0 0) (nthcdr 2 dt))) (apply 'encode-time dt))) ((or (equal cmt all) (and (or (not cmt) (equal cmt auto)) -- 1.8.3.1
[O] org-schedule vs org-time-stamp
I'm not clear on how these two are intended to be used. The former prefixes the timestamp with SCHEDULED: but I'm not sure what practical consequences this has. Items appear in the agenda either way.
Re: [O] [PATCH] Recenter around #+begin_src when moving to previous/next code block
Hi Carsten, Carsten Dominik wrote: When moving with C-c C-v C-n (or p) from one code block to the next (or previous), it's much better if the code block gets centered (vs hidden, forcing the user to scroll down, as it currently is). This is the purpose of this easy patch. I don't think this patch is the right thing - is feels different from standard Emacs behavior. I'm not sure to understand which Emacs behavior we would deviate from? This is a jump, and it'd be better located at a readable place. Without it, you're forced to follow 90% of your jumps by a `C-l'... And isn't it very similar to the patch I sent earlier this week regarding the recenter after the jump with `C-c C-x C-j'? I'd more easily understand that both are either accepted or rejected, but not a mixed case. Anyway, I'm not bothered if it's not in Org, I can simply defadvice the functions (the `after' case). So I respect your decision, even if it puzzles me: it's just that having to manually recenter after almost all jumps do not feel like a right behavior of Org to me, for the beginners who can't make such defadvice on their own. Best regards, Seb -- Sebastien Vauban
Re: [O] no fontification of #+BEGIN_LaTeX blocks
Julien Cubizolles wrote: org-src-fontify-natively doesn't fontify quoted LaTeX code like #+BEGIN_LaTeX #+END_LaTeX the same as it does for LaTeX src blocks like #+BEGIN_SRC latex #+END_SRC Why is that, and is there a way to get fontification for both ? Yes, you have different faces: `org-block-background' and face `org-block'. It's always better to have more than not enough. Up to you to customize them so that they look the same, if that's what you want. PS- Use `C-u C-x =' with point where you want to know which are the faces in question. Then, M-x customize-face... Best regards, Seb -- Sebastien Vauban
Re: [O] org-schedule vs org-time-stamp
Paul Rudin, Paul Rudin wrote: I'm not clear on how these two are intended to be used. The former prefixes the timestamp with SCHEDULED: but I'm not sure what practical consequences this has. Items appear in the agenda either way. You should absolutely read the chapter 8 (Dates and Times) of the Org manual. In summary, active timestamps only will appear on the day of the timestamp. It's good for meetings or birthdays or events that naturally only occur at a certain day. SCHEDULED timestamps indicate when you want to start working on a task. Such items will appear every day, on and on, in your agenda until you mark them done. Best regards, Seb -- Sebastien Vauban
Re: [O] org-schedule vs org-time-stamp
Sebastien Vauban sva-n...@mygooglest.com writes: Paul Rudin, Paul Rudin wrote: I'm not clear on how these two are intended to be used. The former prefixes the timestamp with SCHEDULED: but I'm not sure what practical consequences this has. Items appear in the agenda either way. You should absolutely read the chapter 8 (Dates and Times) of the Org manual. In summary, active timestamps only will appear on the day of the timestamp. It's good for meetings or birthdays or events that naturally only occur at a certain day. SCHEDULED timestamps indicate when you want to start working on a task. Such items will appear every day, on and on, in your agenda until you mark them done. Ah yes, I see. Thanks.
Re: [O] customizing preamble for org-preview-latex-fragment
Julien Cubizolles j.cubizol...@free.fr writes: How can I change the default packages used in the latex file generated by org-preview-latex-fragment ? They are produced by the function org-create-formula--latex-header, which uses the variables org-latex-default-packages-alist org-latex-packages-alist to construct the header of the latex file. These two have the same format: they are both lists of three-element sublists, where each sublist is of the form: (options package snippet-flag) Note the snippet-flag. See the docstrings of the variables for more details. If the package you want to include is missing completely from these two lists, then add it to the second variable above with a snippet-flag setting of ``t'': --8---cut here---start-8--- (add-to-list 'org-latex-packages-alist '(options package t)) --8---cut here---end---8--- If the package is included in one of them (probably the default list) but has been banned from being included in a snippet (by setting its snippet-flag to nil), then unban it by setting the flag to ``t''. It's probably best to do that through the customize interface. Untested, but I can't imagine anything going wrong - famous last words :-) ... -- Nick
[O] Bug: org-set-property does not leave the point still [8.1.1 (release_8.1.1-29-gc5f2ae @ /home/mboes/.emacs.d/lisp/org/lisp/)]
Hi, consider the following very simple org file: * TODO Thing1[] where [] marks where the point is. Now if I C-S-RET to insert a new TODO heading, I get * TODO Thing1 * TODO [] Note that there is a trailing space at the end of the last line, as expected. The problem is that if I now press C-c C-x p to set a property (any property), then I end up with the following situation: * TODO Thing1 * TODO :PROPERTIES: :PROP: val :END: [] The point is now at the end of the property drawer, rather than where it was before. Notice how the trailing whitespace in the heading has moreover been moved to after the property drawer. Expected behaviour: After C-c C-x p, I expect to get: * TODO Thing1 * TODO [] :PROPERTIES: :PROP: val :END: This is exactly what I get if there is *no trailing whitespace* in the TODO heading before hitting C-c C-x p. So it seems that the bug is that org-set-property does not deal well with trailing whitespace. This is a problem because it messes up setting properties by advising org-insert-todo-heading, say to set a CREATED property automatically for new TODO items. Emacs : GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.2) of 2013-08-07 on -mnt-storage-buildroots-staging-x86_64-eric Package: Org-mode version 8.1.1 (release_8.1.1-29-gc5f2ae @ /home/mboes/.emacs.d/lisp/org/lisp/)
Re: [O] Remove Org and Tbl from menubar for derived mode
On 2013-09-14 13:42 , Jambunathan K wrote: (add-hook 'org-mode-hook (lambda nil (local-unset-key [menu-bar Org]))) Thanks, if I do this for my derived mode, it does exactly what I need! Christian -- Christian Wittern, Kyoto
Re: [O] [PATCH] Recenter around #+begin_src when moving to previous/next code block
On 15.9.2013, at 21:06, Sebastien Vauban sva-n...@mygooglest.com wrote: Hi Carsten, Carsten Dominik wrote: When moving with C-c C-v C-n (or p) from one code block to the next (or previous), it's much better if the code block gets centered (vs hidden, forcing the user to scroll down, as it currently is). This is the purpose of this easy patch. I don't think this patch is the right thing - is feels different from standard Emacs behavior. I'm not sure to understand which Emacs behavior we would deviate from? This is a jump, and it'd be better located at a readable place. Without it, you're forced to follow 90% of your jumps by a `C-l'... And isn't it very similar to the patch I sent earlier this week regarding the recenter after the jump with `C-c C-x C-j'? I'd more easily understand that both are either accepted or rejected, but not a mixed case. I think the difference is the following: org-clock-goto is a jump to a specific location and can be expected to be far away, so it is OK to recenter the screen. org-babel-next-src-block is more like forward paragraph, or like a forward search. It is possible that there are several src blocks on a page. Only moving the window content when necessary gives a better sense of space and location. This is why such commands in Emacs only scroll when the target position is off screen. Regards - Carsten Anyway, I'm not bothered if it's not in Org, I can simply defadvice the functions (the `after' case). So I respect your decision, even if it puzzles me: it's just that having to manually recenter after almost all jumps do not feel like a right behavior of Org to me, for the beginners who can't make such defadvice on their own. Best regards, Seb -- Sebastien Vauban signature.asc Description: Message signed with OpenPGP using GPGMail
[O] Repeaters in plain timestamps
Hi, Org people. The manual, section 8.3.2 Repeated tasks, says: Some tasks need to be repeated again and again. Org mode helps to organize such tasks using a so-called repeater in a DEADLINE, SCHEDULED, or plain timestamp. Examples and directions given in the page are related to DEADLINE, and a few words suggest that SCHEDULED works the same. But the page does not say how one may handle repeaters with plain timestamps. I merely would like to update them so they show the date for the next iteration, a bit like command t d already does on a DEADLINE repeater. François P.S. Someone on the list strongly advise me to avoid DEADLINE and SCHEDULED unless they are really meaningful for me, and so did I. But for many cases of events which are not heavy (birthdays are a good example), repeaters are still meaningful.
