Re: [O] Wrong Type Error When Publishing Project
Nick Dokos ndo...@gmail.com writes: Brian Callies br...@gibbous.org writes: I'm sure I must be doing something obviously wrong, but I've had no success at publishing a project I've just created. I've been working on this error for some time, incidentally fixing other mistakes, but I'm unable to get it working. I get the same error on Arch Linux, as I do on Win8. I'm using Org-mode 8.0.5. I get the following error: Wrong type argument: stringp My project config is below. Images-w and css-w export fine on their own, but alpharednotes-w and AlphaRedWin both fail with the error above. (setq org-publish-project-alist '( (alpharednotes-w :base-directory C:/Users/bcallies/Dropbox/RPG/Alpha Red/org :base-extension org :publishing-directory C:/Users/bcallies/Dropbox/RPG/Alpha Red/org/html/ ; :recursive t :publishing-function org-publish-org-to-html This was valid for org 7.x, but for org 8.x you have to say :publishing-function org-html-publish-to-html BTW, you should check your installation: presumably you are not getting on error when calling org-publish-org-to-html, which means that it is somehow defined - but it should not be if you are running 8.x. You might be getting the orgmode bundled with emacs: if that's true, that's a state of affairs that is bound to be confusing. -- Nick
Re: [O] how to handle svg files when exporting orgmode to html and pdf?
Hi Malcom, 2013ko uztailak 17an, malcolm cook-ek idatzi zuen: Hi, I am creating .svg files with R source blocks and ESS in org. I am happily viewing them in-line in my emacs buffer. I am happily exporting as html and viewing them in-line in the resulting web page, including a table of images. I do not have an approach for including them into PDF when I export-tex-pdf. I'm thinking there might be an approach to converting them on-the-fly to png (or something) during the export-tex-pdf. A similar problem was addressed with custom macros here: http://thread.gmane.org/gmane.emacs.orgmode/56532/focus=58322 But it does not work with R source blocks that produce .svg files. Any suggestions for me? Is this a lost cause? Am I asking for too many assumptions to be made by such an auto-conversion process that it is doomed to fail anyway? I have been using a variant of this workflow with some success. Using a patch I just pushed to the master branch, you should be able to successfully export SVG image files to LaTeX documents, using the “svg” LaTeX package: http://www.ctan.org/pkg/svg No configuration should be needed on the org side. The svg LaTeX package is a bit fussy. It only works under pdfTeX (it can be patched to work with LuaTeX, but cannot work with XeTeX at all). It also requires you to have the inkscape command line program installed. But within those constraints it works very nicely. You may need to arrange for whatever compilation process you use for LaTeX files to pass the “-shell-escape” command line option to pdftex. This allows TeX code to execute command line programs, which is needed to communicate with inkscape and convert the SVG into something LaTeX can use. I think in the long run it would be nice if Org could help you translate the image types in your document into image types an exporter understands (basically an expanded and generalized version of what is already done with LaTeX snippets for non-LaTeX export). But that is a bigger project, I think. -- Aaron Ecay
Re: [O] Encoding Problem in export?
At Fri, 26 Jul 2013 12:20:37 +0200, Nicolas Goaziou wrote: David Maus dm...@ictsoc.de writes: Thanks for your answer. It seems I got confused with the current state of URI-encoding. Please scratch my previous suggestion and let's start over. The more I think about it the more I grow certain that it is NOT about URI encoding but protecting a string. Unless we parse the URI and know the protocol we cannot tell if square brackets are allowed or not. Alas, there is a serious flaw in the current implementation. As you said: There is, of course, the nasty thing that we don't know if the link in a buffer went through org-link-escape or not. E.g. if you paste , | [[http://redirect.example.org?url=http%3A%2F%2Ftarget.example.org%3Fid%3D33%26format%3Dhtml]] ` into the buffer you'll get a broken link because org-link-open assumes the link to be escaped by org. There is, indeed, no easy way to know if a link went through `org-link-escape', so we cannot unescape it properly in every situation. We could use text properties on escaped links, but that seems awkward. I think there is a simpler solution: we never unescape links, which means that escaping must be at its minimum. For example, we could only replace [ and ] with, respectively, %5B and %5D and newlines with spaces. It doesn't cripple link's readability very mucĥ, and is safe as [, ] and \n are always forbidden in URI anyway. `[' and `]' are not forbidden per se, they belong to the set of reserved characters (see RFC 3986, 2.2.). characters in the reserved set are protected from normalization and are therefore safe to be used by scheme-specific and producer-specific algorithms for delimiting data subcomponents within a URI. (RFC 3986, p. 12) Moreover they are explicitly required in the host part to denote a IPv6 address literal (RFC 3986, 3.2.2). If I am not mistaken then this is a valid http-URI with a XPointer fragment pointing to the third `p' element in a locally hosted file: http://[::1]/foo.xml#xpointer(//p[3]) ,[ http://www.w3.org/TR/xptr-framework/#escaping | IRI references can be converted to URI references for consumption by | URI resolvers. The disallowed characters in URI references include all | non-ASCII characters, plus the excluded characters listed in Section | 2.4 of [RFC 2396], except for the number sign (#) and percent sign (%) | and the square bracket characters re-allowed in [RFC 2732]. ` When sending the URL to the consuming, there will be problems, according to the assumption at the beginning of this message. But that is to be expected. If we escape but don't unescape there are *other* problems: Depending on the protocol an escaped square bracket and a unescaped square bracket can have different meaning. The assumption I mentioned referes to unescaped characters. A consuming application knows the protocol and can infer the characters that need to be escaped. Replacing non-ascii characters would make the link unreadable to a human. Also, we don't prevent encoding mismatch (e.g., from UTF-8 to ISO-8859-1) when yanking regular text in an Org buffer, so there's no particular reason to do it for links. ACK. It's not about creating URIs but protecting strings, thus the rules for percent escaping don't have to be applied. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de
Re: [O] Encoding Problem in export?
David Maus dm...@ictsoc.de writes: The more I think about it the more I grow certain that it is NOT about URI encoding but protecting a string. This is what I mean. `[' and `]' are not forbidden per se, they belong to the set of reserved characters (see RFC 3986, 2.2.). characters in the reserved set are protected from normalization and are therefore safe to be used by scheme-specific and producer-specific algorithms for delimiting data subcomponents within a URI. (RFC 3986, p. 12) Moreover they are explicitly required in the host part to denote a IPv6 address literal (RFC 3986, 3.2.2). If I am not mistaken then this is a valid http-URI with a XPointer fragment pointing to the third `p' element in a locally hosted file: http://[::1]/foo.xml#xpointer(//p[3]) Thanks for the info. I didn't read RFC 3986 thoroughly. If we escape but don't unescape there are *other* problems: Depending on the protocol an escaped square bracket and a unescaped square bracket can have different meaning. The assumption I mentioned referes to unescaped characters. A consuming application knows the protocol and can infer the characters that need to be escaped. We cannot unescape if we use %-encoding, as stated before. ACK. It's not about creating URIs but protecting strings, thus the rules for percent escaping don't have to be applied. Indeed. Ideally, we need to encode [ and ] with strings that cannot ever be found in a URI. Then, it will be possible to decode them safely. Regards, -- Nicolas Goaziou
[O] LaTeX export: {} on separate lines are escaped, why?
Just wondering if there's a better way to handle LaTeX commands written inline,
when the command arguments span a line break. Currently, LaTeX export preserves
curly braces as is if a pair of them is on a single line, but it escapes them
if there's a line break in between:
~~ org
Sections may be created as subpatches, using \inpcode{[route go
stop]} to start or stop the section, as in the very simple example in
Figure \ref{pd_comp}a.
~~
~~ Exported LaTeX:
Sections may be created as subpatches, using \codeident\{[route go
stop]\} to start or stop the section, as in the very simple example in
Figure \ref{pd_comp}a.
~~
(\codeident is a custom command I defined in the preamble, as semantic markup
for \texttt.)
In the PDF, \ref{pd_comp} turns into a figure number, as I would expect, but
\codeident\{...\} sets the enclosed string in the normal font rather than
fixed-width (with visible {}, which shouldn't be in the printed output).
I do have a workaround:
~~ org
Sections may be created as subpatches, using
#+LaTeX: \inpcode{[route go stop]}
to start or stop the section, as in the very simple example in
Figure \ref{pd_comp}a.
~~
... where #+LaTeX: prevents M-q from breaking the braces onto separate lines,
but -- this has tripped me up a few dozen times working on this article, so I
thought it would be worth asking if this is really the ideal behavior.
hjh
Re: [O] Wrong Type Error When Publishing Project
On 07/27/2013 01:21 AM, Nick Dokos wrote: Nick Dokos ndo...@gmail.com writes: This was valid for org 7.x, but for org 8.x you have to say :publishing-function org-html-publish-to-html BTW, you should check your installation: presumably you are not getting on error when calling org-publish-org-to-html, which means that it is somehow defined - but it should not be if you are running 8.x. You might be getting the orgmode bundled with emacs: if that's true, that's a state of affairs that is bound to be confusing. I was concerned about his too. But, when I do M-x org-version, it does say 8.0.5 which is the version I downloaded manually and installed. For some reason I could never get the ELPA version to load.
Re: [O] using a simple numerical variable in an org text ocument
Sebastien Vauban sva-n...@mygooglest.com writes:
Matt Price wrote:
I'm making a very simple org-document -- a packing list for a trip.
It has entries like
- 4 mugs
- for sleeping bags
- 4 thermarest pads
I'd like to replace the numbers there by a variable -- so if I make a
list for 4 people, the number displayed will be '4'; but if the list
is for 2 people, the number displayed will be 2. Better would be if I
could also do simple arithmetic manipulations (x * 6 dinners for a
week...). I there a really simple way to do this? if it's not really
easy, it won't really seem worth it, but if it is really easy, I will
use it a lot...
As macros are expanded before Babel code is evaluated, I would
try #+scr_calc{...} with MACRO constants in the formula (untested).
Hi Seb(astien),
it seems that you're working with calc source blocks! :-) I'd like to
leverage calc in org-mode (I'm thinking of unit conversions, etc.:
Mathematica for free men) but I'm not getting it. I assume that in an
#+src_calc block the mode of operation of calc is algebraic, isn't it?
#+BEGIN_SRC calc
2 + 2
sqrt(8)
# above is working, by the way, does a calc block have a comment sign?
2 cm
calc-convert-units(mm)
#+END_SRC
#+RESULTS:
: calc - convert - units(mm)
Above attempt is not working. Is it also possible to use the RPN? Like
in this fictive block:
#+BEGIN_SRC calc :mode rpn
2 2 +
2 'mm 8 'cm + 'in u c
#+END_SRC
And the *Calc Trail* buffer seems not to reflect any operations, despite
Calc showing the block results in its calculator buffer!
Thanks
Dieter
Best regards,
Seb
--
Best wishes
H. Dieter Wilhelm
Darmstadt
Germany
[O] [proposal] org-test: Embedded self-tests in orgmode files
After finding that =fill-paragraph= has regressed again, I threw together a quick hack to allow for creating unit tests in orgmode. The result is at [1]. This simply lets you create an org file like so: #+BEGIN_SRC org ,* Test heading ,#+BEGIN_SRC emacs-lisp (org-test-def org-test-fill-paragraph Test filling paragraphs (fill-paragraph)) ,#+END_SRC ,** Before :before: ⁁Lorem Ipsum ,** Expected :expected: ⁁Lorem Ipsum #+END_SRC put the point in the source block, hit =C-c C-c= and have it return #+BEGIN_SRC org ,#+RESULTS: : t #+END_SRC The =⁁= character is =u+2041=, aka =CARET INSERTION POINT=, and notes where point should be before and after running the code. My idea is that this code could be refined to generate ERT tests allowing orgmode to have a unit test suite. What does everyone think? P.S. I'm not on the list, so please include me in replies. [1] https://github.com/haxney/org-test -- Daniel Hackney
Re: [O] LaTeX export: {} on separate lines are escaped, why?
Hello,
James Harkins jamshar...@gmail.com writes:
Just wondering if there's a better way to handle LaTeX commands
written inline, when the command arguments span a line break.
Currently, LaTeX export preserves curly braces as is if a pair of them
is on a single line, but it escapes them if there's a line break in
between:
~~ org
Sections may be created as subpatches, using \inpcode{[route go
stop]} to start or stop the section, as in the very simple example in
Figure \ref{pd_comp}a.
~~
~~ Exported LaTeX:
Sections may be created as subpatches, using \codeident\{[route go
stop]\} to start or stop the section, as in the very simple example in
Figure \ref{pd_comp}a.
~~
Org syntax has a very limited support for LaTeX commands. Usual regexp
used is:
[a-zA-Z]+\\*?\\(\\(\\[[^][\n{}]*\\]\\)\\|\\({[^{}\n]*}\\)\\)*
As you can see, newline characters are explicitly forbidden.
We could extend quite easily this support to more complex commands, but
I'm not sure we should encourage this. By essence, LaTeX macros are not
very portable. Luckily, there's a syntax for non-portable code: export
snippets. Thus, you can write:
Sections may be created as subpatches, using @@latex:\inpcode{[route go
stop]}@@ to start or stop the section, as in the very simple example in
Figure \ref{pd_comp}a.
I think it is better than improving LaTeX commands support.
As a side note, I suggest to use Org cross reference syntax instead of
writing \ref{...} explicitly.
Regards,
--
Nicolas Goaziou
[O] [BUG] `org-fill-paragraph' doesn't use `fill-prefix'
I proposed a fix [1] for this back in 2010, but it seems to have regressed again. `org-fill-paragraph' no longer makes use of a `fill-prefix', so filling things like email comments no longer works. To test, launch =emacs -Q= and create a buffer with #+BEGIN_EXAMPLE The cat in the hat #+END_EXAMPLE And press =M-q=. In `fundamental-mode', this results in #+BEGIN_EXAMPLE The cat in the hat #+END_EXAMPLE In recent versions of org-mode, this results in #+BEGIN_EXAMPLE The cat in the hat #+END_EXAMPLE I have tested the following versions of org-mode: | Mode | Working | |--+-| | fundamental-mode | Yes | | org 7.9.3f (Emacs 24.3.1)| No | | org 8.0 (20130727.224 from MELPA | No | | 7.8.11 (Emacs 24.2.1)| Yes | |--+-| P.S. I'm not subscribed to the list, so please CC me in replies. [1] http://permalink.gmane.org/gmane.emacs.orgmode/22705 -- Daniel Hackney
Re: [O] [proposal] org-test: Embedded self-tests in orgmode files
Nicolas Goaziou n.goaz...@gmail.com wrote: Daniel Hackney d...@haxney.org writes: After finding that =fill-paragraph= has regressed again, Would you mind elaborating on that? I could have overlooked the problem. I just started a separate thread about it. -- Daniel Hackney
Re: [O] Wrong Type Error When Publishing Project
Thank you. I thought it was probably something like this. Is there updated documentation yet for 8.x? The Worg link below is one site I based my attempt on: http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html -Brian On 07/26/2013 08:33 PM, Nick Dokos wrote: Brian Callies br...@gibbous.org writes: I'm sure I must be doing something obviously wrong, but I've had no success at publishing a project I've just created. I've been working on this error for some time, incidentally fixing other mistakes, but I'm unable to get it working. I get the same error on Arch Linux, as I do on Win8. I'm using Org-mode 8.0.5. I get the following error: Wrong type argument: stringp My project config is below. Images-w and css-w export fine on their own, but alpharednotes-w and AlphaRedWin both fail with the error above. (setq org-publish-project-alist '( (alpharednotes-w :base-directory C:/Users/bcallies/Dropbox/RPG/Alpha Red/org :base-extension org :publishing-directory C:/Users/bcallies/Dropbox/RPG/Alpha Red/org/html/ ; :recursive t :publishing-function org-publish-org-to-html This was valid for org 7.x, but for org 8.x you have to say :publishing-function org-html-publish-to-html -- Nick
Re: [O] [proposal] org-test: Embedded self-tests in orgmode files
Hello, Daniel Hackney d...@haxney.org writes: After finding that =fill-paragraph= has regressed again, Would you mind elaborating on that? I could have overlooked the problem. Regards, -- Nicolas Goaziou
Re: [O] [BUG] `org-fill-paragraph' doesn't use `fill-prefix'
Daniel Hackney d...@haxney.org writes: I proposed a fix [1] for this back in 2010, but it seems to have regressed again. `org-fill-paragraph' no longer makes use of a `fill-prefix', so filling things like email comments no longer works. It has been discussed on this ML already. Org mode is not Message mode and prefix means nothing to it. Also, it has its own set of special prefixes, which are not found in Fundamental mode. For example, you can never have : as a fill prefix since it creates a fixed-width area. Therefore, I don't consider it to be a regression since it's not an expected feature in the first place. But I admit it is still convenient. Maybe we can introduce some support for `adaptive-fill-regexp' in paragraphs and comments filling. Would you mind testing the following patch? Regards, -- Nicolas Goaziou From d460b8048d7b3b308cd93794b1de46837438a8e6 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou n.goaz...@gmail.com Date: Sat, 27 Jul 2013 22:02:45 +0200 Subject: [PATCH] Add support for `adaptive-fill-regexp' in paragraphs and comments * lisp/org.el (org-adaptive-fill-function, org-fill-paragraph): Add support for `adaptive-fill-regexp' in paragraphs and comments. * testing/lisp/test-org.el: Add test. --- lisp/org.el | 43 ++- testing/lisp/test-org.el | 34 ++ 2 files changed, 64 insertions(+), 13 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 2f619cc..c852550 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -22179,7 +22179,15 @@ meant to be filled. (post-affiliated (org-element-property :post-affiliated element))) (unless (and post-affiliated ( p post-affiliated)) (case type - (comment (looking-at [ \t]*# ?) (match-string 0)) + (comment + (save-excursion + (beginning-of-line) + (looking-at [ \t]*# ?) + (goto-char (match-end 0)) + (let ((comment-prefix (match-string 0))) + (if (looking-at adaptive-fill-regexp) + (concat comment-prefix (match-string 0)) + comment-prefix (footnote-definition ) ((item plain-list) (make-string (org-list-item-body-column @@ -22188,15 +22196,19 @@ meant to be filled. ? )) (paragraph ;; Fill prefix is usually the same as the current line, - ;; except if the paragraph is at the beginning of an item. + ;; except if the paragraph is at the beginning of an + ;; item. For convenience, if `adaptive-fill-regexp' + ;; matches, use it. (let ((parent (org-element-property :parent element))) - (cond ((eq (org-element-type parent) 'item) - (make-string (org-list-item-body-column - (org-element-property :begin parent)) -? )) - ((save-excursion (beginning-of-line) (looking-at [ \t]+)) - (match-string 0)) - (t + (save-excursion + (beginning-of-line) + (cond ((eq (org-element-type parent) 'item) + (make-string (org-list-item-body-column + (org-element-property :begin parent)) + ? )) + ((looking-at adaptive-fill-regexp) (match-string 0)) + ((looking-at [ \t]+) (match-string 0)) + (t ) (comment-block ;; Only fill contents if P is within block boundaries. (let* ((cbeg (save-excursion (goto-char post-affiliated) @@ -22341,10 +22353,15 @@ a footnote definition, try to fill the first paragraph within. (line-end-position) ;; Do not fill comments when at a blank line or at ;; affiliated keywords. - (let ((fill-prefix (save-excursion - (beginning-of-line) - (looking-at [ \t]*#) - (concat (match-string 0) + (let ((fill-prefix + (save-excursion + (beginning-of-line) + (looking-at [ \t]*#) + (let ((comment-prefix (match-string 0))) + (goto-char (match-end 0)) + (if (looking-at adaptive-fill-regexp) +(concat comment-prefix (match-string 0)) + (concat comment-prefix )) (when ( end begin) (save-excursion (fill-region-as-paragraph begin end justify)) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 504defa..517d0d1 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -176,6 +176,14 @@ (narrow-to-region 1 8) (org-fill-paragraph) (buffer-string) + ;; Handle `adaptive-fill-regexp' in paragraphs. + (should + (equal a b + (org-test-with-temp-text a\n b + (let ((fill-column 5) + (adaptive-fill-regexp [ \t]*+[ \t]*)) + (org-fill-paragraph) + (buffer-string) ;; Special case: Fill first paragraph when point is at an item or ;; a plain-list or a footnote reference. (should @@ -225,6 +233,14 @@ (let ((fill-column 20)) (org-fill-paragraph) (buffer-string) + ;; Handle `adaptive-fill-regexp' in comments. + (should + (equal # a b + (org-test-with-temp-text # a\n# b + (let ((fill-column
Re: [O] Adding support for limits and exclusions to iCal recurring events
Toke Høiland-Jørgensen t...@toke.dk writes: Michael Brand michael.ch.br...@gmail.com writes: When implementing this, consider also whether the END_DATE should be an agenda entry on its own and of which kind, warning period etc. I tried to make an example that shows this issue. Adding to this, as mentioned previously, I interpret the iCal standard to really permit and end *time* rather than an end *date*. Which would make more sense in an org context? Going for an END_TIME parameter, and then comparing exactly to the scheduled time (i.e. if current iteration of the recurring entry END_TIME, then filter it), or doing an END_DATE and then interpreting the actual cut-off to be at 00:00:00 on that date? I think it would be less ambiguous to use ICALENDAR_UNTIL (or UNTIL), and apply RFC 5545: The value of the UNTIL rule part MUST have the same value type as the DTSTART property. Furthermore, if the DTSTART property is specified as a date with local time, then the UNTIL rule part MUST also be specified as a date with local time. If the DTSTART property is specified as a date with UTC time or a date with local time and time zone reference, then the UNTIL rule part MUST be specified as a date with UTC time. Regards, -- Nicolas Goaziou
Re: [O] [BUG] `org-fill-paragraph' doesn't use `fill-prefix'
Nicolas Goaziou n.goaz...@gmail.com wrote: Daniel Hackney d...@haxney.org writes: I proposed a fix [1] for this back in 2010, but it seems to have regressed again. `org-fill-paragraph' no longer makes use of a `fill-prefix', so filling things like email comments no longer works. It has been discussed on this ML already. Org mode is not Message mode and prefix means nothing to it. It isn't just that behaves this way in `fundamental-mode' and older versions of org-mode; there are a number of such characters. From a quick test, in Emacs 24.2, #+BEGIN_EXAMPLE -- foo -- bar #+END_EXAMPLE becomes #+BEGIN_EXAMPLE -- foo bar #+END_EXAMPLE whereas in the current org-mode, it is #+BEGIN_EXAMPLE -- foo -- bar #+END_EXAMPLE Same with #+BEGIN_EXAMPLE ! foo ! bar #+END_EXAMPLE and #+BEGIN_EXAMPLE % foo % bar #+END_EXAMPLE The following also fill to a single line: #+BEGIN_EXAMPLE % % foo % % bar ! ! foo ! ! bar #+END_EXAMPLE From a brief look at `fill-paragraph', the relevant code is in `fill-comment-paragraph'. I might take a closer look at it to see if I can come up with my own fix. Also, it has its own set of special prefixes, which are not found in Fundamental mode. For example, you can never have : as a fill prefix since it creates a fixed-width area. Of course. Fundamental mode will fill #+BEGIN_EXAMPLE - foo - bar #+END_EXAMPLE into a single line, but org-mode never did. I'm not asking for new behavior, simply the `fill-paragraph' style of org 7.8.11 back. Therefore, I don't consider it to be a regression since it's not an expected feature in the first place. But I admit it is still convenient. Well, my patch from 2010 /was/ applied [1], so I would consider it an expected feature :) Maybe we can introduce some support for `adaptive-fill-regexp' in paragraphs and comments filling. Would you mind testing the following patch? I'll test it later today. [1] http://article.gmane.org/gmane.emacs.orgmode/22954 -- Daniel Hackney
Re: [O] Clocktable time Information without days (8.0) [7.9.2 (7.9.2-dist @ /usr/share/emacs/site-lisp/org/)]
Hi Arne, I also don't use the output format that includes days. Try setting the following variable: (setq org-time-clocksum-format '(:hours %d :require-hours t :minutes :%02d :require-minutes t)) Regards, Bernt Arne Babenhauserheide arne_...@web.de writes: Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. Dear Org-Hackers, Since the update to org-mode 8.0¹ my timestamps show a day column, when the time is longer than 24 hours. Since I use them to check a 40h workweek, that gets in my way quite a bit. I think that I can get used to it, but I would prefer to set it back to showing hours as highest unit. Is there a way to tell org-mode to avoid showing days? This also interferes with plotting via gnuplot (which does not know the day format). Best wishes, Arne PS: Sorry for abusing the report-bug function for this. It was the fastest way to create this mail… ¹: I write this from another computer which still has org 7. Emacs : GNU Emacs 24.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.12) of 2013-03-20 on kaverne Package: Org-mode version 7.9.2 (7.9.2-dist @ /usr/share/emacs/site-lisp/org/)
Re: [O] [BUG] `org-fill-paragraph' doesn't use `fill-prefix'
Nicolas Goaziou n.goaz...@gmail.com wrote: Daniel Hackney d...@haxney.org writes: I proposed a fix [1] for this back in 2010, but it seems to have regressed again. `org-fill-paragraph' no longer makes use of a `fill-prefix', so filling things like email comments no longer works. Maybe we can introduce some support for `adaptive-fill-regexp' in paragraphs and comments filling. Would you mind testing the following patch? The patch works great for me. I'd love to see it in a released-to-ELPA version of org... ;) -- Daniel Hackney
Re: [O] Export of property key:value
Thanks for the info. I took it up as a challenge to finally learn a little elisp. This is what I have so far, which appears to work as long as I expand the entire subtree to be exported. I'd appreciate any criticism since I really don't know if I'm handling things the best possible way. (defun ewd/export-properties (backend) Export all property names listed in EXPORT_PROPERTIES in the format: - name: value after each heading of specified level NOTE: 1st value in EXPORT_PROPERTIES is heading level (if (org-entry-get (point) EXPORT_PROPERTIES) (let* ( (export_properties (split-string (org-entry-get (point) EXPORT_PROPERTIES) )) (export-level (string-to-number (car export_properties))) (export-list (cdr export_properties)) ) (org-map-entries (lambda () (next-line) (open-line 1) (dolist (prop export-list) (if (= export-level (car (org-heading-components))) (progn (insert - prop : (if (org-entry-get (point) prop) (org-entry-get (point) prop) N/A)) (newline) (add-hook 'org-export-before-processing-hook 'ewd/export-properties)
[O] Export subtree options not working
It appears that I'm using the properties syntax correctly, however I cannot seem to get export to use the options I set in the properties drawer. If I move the LaTeX_CLASS and OPTIONS over to their #+ equivalents at the top of the file they work just fine. Is there something (hopefully not *too* obvious) that I'm doing wrong? :PROPERTIES: :EXPORT_LaTeX_CLASS: report :EXPORT_OPTIONS: toc:nil num:nil H:4 :COLUMNS: %25ITEM %TODO %15Business %16Start-Date %16Last-Update :EXPORT_PROPERTIES: 2 Business Start-Date Last-Update :END:
