Re: [O] [PATCH] Making org-agenda filters orthogonal and refreshed
Hi Bastien, Org-mode version 8.2.5h (release_8.2.5h-883-g45e881 @ /Users/gtk/.emacs.d/org/lisp/) Sure, I'm happy to go with the FSF copyright agreement. I'll send the request today. Greg On Sat, Apr 19, 2014 at 2:02 PM, Bastien b...@gnu.org wrote: Hi Greg, Greg Tucker-Kellogg gtuckerkell...@gmail.com writes: This is org-mode version 8.2.5h, directly off the git. When mentioning the Org version for a patch you submit, please include the whole version with C-u M-x org-version RET -- this tells more than C-h v org-version. emacs version 24.4.50.1 I have noticed that combining top headline filters and category filters didn't always work as documented. Thanks for looking into this. Before we go further enhancing the patch, are you willing to go with the FSF copyright assignment? I see you already have tiny changes and we cannot accept more. If you're not willing to sign, you'll drive the debugging and I'll write the code. Let me know. Other than that, the diagnosis is good and the patch looks okay, except for the use of defadvice. Thanks, -- Bastien
[O] [PATCH] Making org-agenda filters orthogonal and refreshed
This is org-mode version 8.2.5h, directly off the git. emacs version 24.4.50.1 I have noticed that combining top headline filters and category filters didn't always work as documented. In particular, the combination of filters displayed depends on the order of application and removal, and is not always refreshed properly. To test it, I created a new org file with a couple of simple entries. Note: the behaviour is most obvious if you have some other tasks with the same categories or tags in your global todo agenda. * A team member ** TODO Task 1 :COMPUTER: :PROPERTIES: :CATEGORY: Work :END: ** TODO Task 2 :PROPERTIES: :CATEGORY: Team :END: * Someone else ** TODO Someone else's Task 1 :COMPUTER: :PROPERTIES: :CATEGORY: Work :END: If I apply two filters in succession: ^ to filter to the top headline and to filter to the Work category, it appears to work. But then if I toggle the top headline filter with ^ again, all the filters are removed, because the function is using the category filter type to apply and remove the top headline overlay. (Separately, the | shortcut to remove all filters does not currently recognise a top headline filter). I created a patch to fix the issues, but I think it's a bit of a hack, and I'd welcome input or a better patch by a more skilled coder. Even after separating the filter removal, I ended up advising two filter functions to reload the agenda so that it refreshed properly. All of this reflects my poor elisp skills. Nonetheless, I wonder if org-agenda doesn't need some refactoring to remove the explicit repetition of cases for different filter types. Greg diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 184209b..d686bd7 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -2097,6 +2097,7 @@ When nil, `q' will kill the single agenda buffer. org-agenda-tag-filter org-agenda-cat-filter-overlays org-agenda-category-filter +org-agenda-top-headline-filter org-agenda-re-filter-overlays org-agenda-regexp-filter org-agenda-markers @@ -3412,6 +3413,7 @@ If AGENDA-BUFFER-NAME, use this as the buffer name for the agenda to write. (defvar org-agenda-tag-filter-overlays nil) (defvar org-agenda-cat-filter-overlays nil) +(defvar org-agenda-top-headline-filter-overlays nil) (defvar org-agenda-re-filter-overlays nil) (defun org-agenda-mark-filtered-text () @@ -3425,6 +3427,7 @@ If AGENDA-BUFFER-NAME, use this as the buffer name for the agenda to write. 'org-filtered t))) (append org-agenda-tag-filter-overlays org-agenda-cat-filter-overlays +org-agenda-top-headline-filter-overlays org-agenda-re-filter-overlays (defun org-agenda-unmark-filtered-text () @@ -7352,6 +7355,11 @@ The category is that of the current line. (list (concat + cat))) 'category)) ((error No category at point)) + +(defadvice org-agenda-filter-by-category (after org-agenda-redo-after-cat-filter activate) + sometimes the filter needs to be redone + (org-agenda-redo)) + (defun org-find-top-headline (optional pos) Find the topmost parent headline and return it. (save-excursion @@ -7371,10 +7379,14 @@ The top headline is that of the current line. (progn (setq org-agenda-filtered-by-top-headline nil org-agenda-top-headline-filter nil) -(org-agenda-filter-show-all-cat)) -(let ((cat (org-find-top-headline (org-get-at-bol 'org-hd-marker - (if cat (org-agenda-filter-top-headline-apply cat strip) -(error No top-level category at point) +(org-agenda-filter-show-all-top-headlines)) +(let ((tophl (org-find-top-headline (org-get-at-bol 'org-hd-marker + (if tophl (org-agenda-filter-top-headline-apply tophl strip) +(error No top-level headline at point) + +(defadvice org-agenda-filter-by-top-headline (after org-agenda-redo-after-tophl-filter activate) + sometimes the filter needs to be redone + (org-agenda-redo)) (defvar org-agenda-regexp-filter nil) (defun org-agenda-filter-by-regexp (strip) @@ -7403,7 +7415,9 @@ With two prefix arguments, remove the regexp filters. (when org-agenda-category-filter (org-agenda-filter-show-all-cat)) (when org-agenda-regexp-filter -(org-agenda-filter-show-all-re))) +(org-agenda-filter-show-all-re)) + (when org-agenda-top-headline-filter) + (org-agenda-filter-show-all-top-headlines)) (defun org-agenda-filter-by-tag (strip optional char narrow) Keep only those lines in the agenda buffer that have a specific tag. @@ -7665,7 +7679,7 @@ When NO-OPERATOR is non-nil, do not add the + operator to returned tags. (tophl (and pos (org-find-top-headline pos (if (and tophl (funcall (if negative 'identity 'not) (string= hl tophl))) -(org-agenda-filter-hide-line
Re: [O] PATCH -- ox-latex.el . sideways figure in latex export
Thanks for the guidance. I think this is it.
Cheers,
Greg
On Sun, Apr 6, 2014 at 4:46 PM, Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Greg Tucker-Kellogg gtuckerkell...@gmail.com writes:
I think this covers it. :float sideways now works for both tables and
figures, but :float sidewaystable is kept for backwards compatibility.
I
updated org.texi, and mentioned that the use of :float sideways will
make
the :placement option irrelevant.
Attached are the two patches; the one from yesterday and the one that
updates as described above.
Thank you. Here are a few comments.
+The @code{:float} specifies the float environment for the table.
Possible values are @code{sideways},
+(or equivalently @code{sidewaystable}), @code{multicolumn}, @code{t}
and @code{nil}. When unspecified, a table with
+a caption will have a @code{table} environment. Moreover, the
@code{:placement}
+attribute can specify the positioning of the float. Note:
@code{:placement} is
+ignored for sidewaystable.
In Texinfo, you need to add two spaces after a period.
Also, providing backwards compatibility for sidewaystable in code is
fine, but I don't think we need to talk about it anymore as an
alternative option in the documentation. If you feel uncomfortable about
it, I think it's better to add a footnote:
Possible values are @code{sideways}@footnote{Formerly, the value was
@code{sidewaystable}. This is deprecated since Org 8.3.},
@code{multicolumn}...
Also, could you provide a proper commit message, with TINYCHANGE at
its end. For more information, see
http://orgmode.org/worg/org-contribute.html
I think you can also merge both patches. But that's your call.
Regards,
--
Nicolas Goaziou
0001-ox-latex.el-support-sideways-float-options-for-table.patch
Description: Binary data
[O] PATCH -- ox-latex.el . sideways figure in latex export
This is a tiny patch to support a “:float sidewaysfigure” option in LaTeX
backend export
---
lisp/ox-latex.el | 5 +
1 file changed, 5 insertions(+)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index d65c975..c05ffb6 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1801,6 +1801,7 @@ used as a communication channel.
(float (let ((float (plist-get attr :float)))
(cond ((and (not float) (plist-member attr :float)) nil)
((string= float wrap) 'wrap)
+ ((string= float sidewaysfigure) 'sidewaysfigure)
((string= float multicolumn) 'multicolumn)
((or float
(org-element-property :caption parent)
@@ -1876,6 +1877,10 @@ used as a communication channel.
\\centering
%s%s
%s\\end{wrapfigure} placement comment-include image-code caption))
+ (sidewaysfigure (format \\begin{sidewaysfigure}%s
+\\centering
+%s%s
+%s\\end{sidewaysfigure} placement comment-include image-code caption))
(multicolumn (format \\begin{figure*}%s
\\centering
%s%s
--
1.8.4.3
Re: [O] PATCH -- ox-latex.el . sideways figure in latex export
I think this covers it. :float sideways now works for both tables and figures, but :float sidewaystable is kept for backwards compatibility. I updated org.texi, and mentioned that the use of :float sideways will make the :placement option irrelevant. Attached are the two patches; the one from yesterday and the one that updates as described above. Cheers, Greg On Sun, Apr 6, 2014 at 3:03 AM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Greg Tucker-Kellogg gtuckerkell...@gmail.com writes: This is a tiny patch to support a :float sidewaysfigure option in LaTeX backend export Thank you for the patch. It makes sense since tables provide sidewaystable. By the way, wouldn't it make sense to use sideways for both, instead of sidewaystable and sidewaysfigure? Also, it needs to be documented in org.texi. Do you want to take care of that part? Regards, -- Nicolas Goaziou 0001-ox-latex-sidewaysfigure-export-for-LaTeX-backend.patch Description: Binary data 0002-Documented-and-standardised-sideways-options-for-tab.patch Description: Binary data
[O] Bug: R source block list export not working properly [7.8.11]
I reported this on the mailing list as a question, but it appears to be an actual bug, so I thought I should file it formally. The following MWE shows the problem when trying to export an R character vector: #+begin_src R :exports results :results value list c(x,y,z) #+end_src #+RESULTS: - (x) - (y) - (z) This is clearly not what is wanted, more or less ever. What works, instead, requires R manipulation of the results, of the form: #+BEGIN_SRC R :exports results :results output raw a - c(x,y,z) cat(paste(-, a), sep=\n) #+END_SRC #+RESULTS: - x - y - z Emacs : GNU Emacs 24.2.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2012-08-27 on bob.porkrind.org Package: Org-mode version 7.8.11
Re: [O] Bug: R source block list export not working properly [7.8.11]
Hi Tom, I didn't realize. Thanks for the info; I'll look into it. Greg On Sep 25, 2012, at 11:28 PM, Thomas S. Dye wrote: Hi Greg, The problem is that no one is maintaining ob-r.el. The author, Dan Davison, has moved on to other things. Eric Schulte will apply patches to ob-r.el. Perhaps you could suggest a patch that would fix this behavior? All the best, Tom -- Thomas S. Dye http://www.tsdye.com
[O] creating a list from an R source block
Creating a list in Org from a Ruby Array is trivial #+BEGIN_SRC ruby :exports results :results value list [x , y, z ] #+END_SRC #+RESULTS: - x - y - z But trying the same thing from R gives a surprising (to me) result #+BEGIN_SRC R :exports results :results value list c(x,y,z) #+END_SRC #+RESULTS: - (x) - (y) - (z) removing the list header creates a table, but there seems to be no straightforward way in R to create a list of elements that is treated by Org as a list. Am I missing something? Greg
Re: [O] creating a list from an R source block
Thanks, that works. But does this count as a bug in ob-R? Greg On Sep 5, 2012, at 12:55 AM, John Hendy wrote: On Tue, Sep 4, 2012 at 11:42 AM, Greg Tucker-Kellogg gtuckerkell...@gmail.com wrote: Creating a list in Org from a Ruby Array is trivial #+BEGIN_SRC ruby :exports results :results value list [x , y, z ] #+END_SRC #+RESULTS: - x - y - z But trying the same thing from R gives a surprising (to me) result #+BEGIN_SRC R :exports results :results value list c(x,y,z) #+END_SRC #+RESULTS: - (x) - (y) - (z) Clunky, perhaps, but this works: #+BEGIN_SRC R :exports results :results output org a - c(x,y,z) cat(paste(-, a), sep=\n) #+END_SRC #+RESULTS: #+BEGIN_ORG - x - y - z #+END_ORG Best regards, John removing the list header creates a table, but there seems to be no straightforward way in R to create a list of elements that is treated by Org as a list. Am I missing something? Greg
[O] specifying the coding language resulting from a a :results code source block
I have a Ruby block that creates some dot code. I'd like to be able to have the #+RESULTS block enclosed in a src block that starts #+BEGIN_SRC dot. Using :results value code generates the enclosing SRC block, but using the same language (Ruby) used to generate the code. Is there a way to specify the coding language of a generated #+RESULTS src block? Thanks, Greg signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] specifying the coding language resulting from a a :results code source block
Mahalo Tom, It looks like that's what I'll be doing for the ruby block. That said, it would be great if the :results code argument would allow a language specification. Greg On Jun 27, 2012, at 10:22 AM, Thomas S. Dye wrote: Greg Tucker-Kellogg gtuckerkell...@gmail.com writes: I have a Ruby block that creates some dot code. I'd like to be able to have the #+RESULTS block enclosed in a src block that starts #+BEGIN_SRC dot. Using :results value code generates the enclosing SRC block, but using the same language (Ruby) used to generate the code. Is there a way to specify the coding language of a generated #+RESULTS src block? Thanks, Greg Aloha Greg, This works for me with an emacs-lisp code block named harris-matrix that generates dot code. #+header: :var input=harris-matrix #+header: :file temp.pdf #+header: :cmdline -Tpdf #+header: :results output #+BEGIN_SRC dot $input #+END_SRC It's not quite what you were after, but it might help? All the best, Tom -- Thomas S. Dye http://www.tsdye.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] [dev] About a beamer back-end
I also quite like using headlines for blocks, for many of the same reasons Eric mentioned. In addition, I regularly use column view to set BEAMER_env, BEAMER_envargs, BEAMER_extra, etc., and column view operates on headlines. Greg On Jun 20, 2012, at 5:04 AM, Eric S Fraga wrote: Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Eric S Fraga e.fr...@ucl.ac.uk writes: Well, I will have to chime in with a contrary view. I like using headlines to define blocks, and I use blocks on almost every frame. I have the following reasons for preferring a headline approach: - the proposed approach does not easily (at all?) cater for blocks within blocks I may be missing your point, but you can have nested blocks. What would be more difficult to achieve with blocks? Sorry! I missed the begin...end structure for the blocks you were proposing. Indeed, I see no reason that your proposal does not support a recursive nesting of blocks. - ease of hiding of content: org for me is still primarily an outliner! You can hide blocks too. but the difference is that the hidden block doesn't tell you anything about the block itself? that is, there is no equivalent to the text content of a headline that is visible when the contents below the headline are hidden. This is possibly (?) a minor point, mind you. - being able to re-arrange content in a frame quickly (M-up, etc.) See `org-element-drag-backward' and `org-element-drag-forward'. Okay. Will it be easy to bind these to M-up etc. to achieve consistent behaviour? I.e. does org-metaup know what to do with blocks? - within frames, there is no other use for lower level headlines. Using these for blocks seems appropriate. What else could they be used for? Good question. One idea would be to use them as outline tools that would have no impact on export (they would help hiding frame contents in the buffer but would be ignored in produced LaTeX code). Obviously, both approaches (blocks or headlines) have drawbacks. I'm still unsure about which one would be the quickest/cleanest/most useful. Understood! And I don't want to stand in the way of an implementation of beamer support in the new exporter. As a point for discussion and evaluation, attached is an example slide (both org and pdf) demonstrating the type of thing I tend to do for some of my beamer documents. Also, please don't forget about columns! beamerblocks.orgbeamerblocks.pdf -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.1.50.1 and Org release_7.8.11-69-ga2fd96 signature.asc Description: Message signed with OpenPGP using GPGMail
[O] org-babel R :results output changes with block level :session setting
I'm trying to use org-mode to reproduce the HTML slide show made with knitr demonstrated at http://goo.gl/bOJJo . The following single code block works #+BEGIN_SRC R :results output html library(googleVis) G - gvisGeoChart(Exports, Country, Profit, options = list(width = 250, height = 120)) print(G) #+END_SRC and wraps it in the needed HTML block, but if I set :session on the block the R prompt is included in the output. If i set a file level session property it works fine, but if on a single block inserts the prompt. I was expecting these would behave identically. Is this the expected behavior? Greg signature.asc Description: Message signed with OpenPGP using GPGMail
[O] Removing TODO overviews (e.g., [3/5]) on export?
I am preparing a presentation using Org and Beamer. This time -- for the first time -- I am marking the slides as TODO items. I have the org export options set so the TODO keywords don't wind up in the LaTeX export, (todo:nil) and d:nil to make sure my status logging drawer is not included. This all works fine. My slides are level 2 headings, and I use top level headings to mark sections. But if I capture an overview of the work on slides in a section, e.g., * TODO [3/5] Section 1 ** DONE A slide ** TODO Another slide ** TODO another slide ** DONE A slide ** DONE A slide the LaTeX export exports the [5/7] into the section headings, where it then appears in transition slides to mark new sections. I don't see any export option in the manual or the mailing list archives for turning this off. Have I missed such an option? Greg smime.p7s Description: S/MIME cryptographic signature
