[O] problem with auto-fill-mode in gnus with org

[Eric S Fraga]

Hello all,

I have recently started using pabbrev again.  However, I found that
using orgstruct mode within Message buffers (in gnus) caused pabbrev to
not work properly.  Not sure why (something to pursue later).

So I decided to not enable orgstruct mode.  However, by doing so, I get
the following error whenever I try to type in a line longer than my
auto-fill-column:

,
| Debugger entered--Lisp error: (void-variable orgtbl-line-start-regexp)
|   org-adaptive-fill-function()
|   org-auto-fill-function()
|   self-insert-command(1)
|   funcall-interactively(self-insert-command 1)
|   call-interactively(self-insert-command nil nil)
|   command-execute(self-insert-command)
`

I have

  (setq auto-fill-function 'org-auto-fill-function)

in my message-mode-hook so I do expect org to be involved in my message
composition.  Am I responsible for initialisation of org in this
context?  What am I missing?

Thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-558-g83d8a2

Re: [O] What happened to ODT export?

[Brady Trainor]

Hello, 

Christopher Culver  writes:

> I am running org-mode 8.2.10 from elpa on Emacs 24.4. When I try to
> export to ODT format with the keystrokes described here:
>
> http://orgmode.org/manual/ODT-export-commands.html
>
> I get an error. Indeed, when I press C-c C-e, ODT is not even mentioned
> among the formats that I can export to, I am offered only iCalender,
> HTML, plaintext and LaTeX. I remember being able to easily export to ODT
> in the past. Has this functionality been removed or moved to a separate
> package?

I find the following: 

, [ C-h v org-export-backends RET ]
| org-export-backends is a variable defined in `org.el'.
| Its value is (ascii html icalendar latex md odt)
| Original value was 
| (ascii html icalendar latex)
`

In my init file, I have

--8<---cut here---start->8---
(setq org-export-backends 
  '(ascii
html
icalendar
latex
md
odt
))
--8<---cut here---end--->8---

Also, at top of buffer, I see

,
| Use SPC, DEL, C-n, or C-p to navigate.
`

Helpful if additional options are not visible. 

HTH

--
Brady

Re: [O] What happened to ODT export?

[Eric Abrahamsen]

Christopher Culver  writes:

> I am running org-mode 8.2.10 from elpa on Emacs 24.4. When I try to
> export to ODT format with the keystrokes described here:
>
> http://orgmode.org/manual/ODT-export-commands.html
>
> I get an error. Indeed, when I press C-c C-e, ODT is not even mentioned
> among the formats that I can export to, I am offered only iCalender,
> HTML, plaintext and LaTeX. I remember being able to easily export to ODT
> in the past. Has this functionality been removed or moved to a separate
> package?

You have to explicitly require many of the export backends: (require
'ox-odt). That should do it.

Re: [O] Inline code :results replace not working

[Ista Zahn]

On Mon, Nov 10, 2014 at 3:04 PM, Grant Rettke  wrote:
> On Mon, Nov 10, 2014 at 11:03 AM, Ista Zahn  wrote:
>> On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry  wrote:
>>> On Mon, 10 Nov 2014, Andreas Leha wrote:
>>
>> [snip]
>>
>>>
>>
>> Nonetheless, from a literate programming perspective, I think that
>> replaceable (and raw) inline results are definitely desirable.
>> Regardless of the state of their implementation in orgmode right now.
>>>
>>>
>>> +1.
>>
>> +1 from me as well. For exactly the reason Andreas illustrated I've
>> given up on using inline results for the past year or so. Would be
>> great to see this feature become usable by implementing a system for
>> replacing them.
>
> My approach here has been to use "hidden" source blocks that aren't
> exported but make it
> really easy to see the result during development. These settings
> should work on any configuration,
> so I didn't include mine here.
>
> ✂✂
> #+BEGIN_SRC R
> a = 10
> b = 23
> c = a + b
> #+END_SRC
>
> #+BEGIN_SRC R :results output silent :exports none
> c
> #+END_SRC
>
> The user calculated src_R{c}.
> ✂✂
>
> When you use these functions
> http://orgmode.org/manual/Key-bindings-and-useful-functions.html#Key-bindings-and-useful-functions
> the addition of these "hidden" blocks hav almost zero cost and give me
> what I want.

The problem I have is not that I miss being able to see results of the
inline block in the org-mode buffer. The problem is that I don't want
blocks to be evaluated on export (too time consuming in many cases).
So I turn that off, and either evaluate the blocks one at a time (I'm
aware of the dangers of this, not my point here) or call
org-babel-execute-buffer. Everytime I do that I get duplicate output
from inline code. As far as I can see inline code +
org-babel-execute-buffer is incompatible, which is why I gave up on
the former.

Best,
Ista

[O] What happened to ODT export?

[Christopher Culver]

I am running org-mode 8.2.10 from elpa on Emacs 24.4. When I try to
export to ODT format with the keystrokes described here:

http://orgmode.org/manual/ODT-export-commands.html

I get an error. Indeed, when I press C-c C-e, ODT is not even mentioned
among the formats that I can export to, I am offered only iCalender,
HTML, plaintext and LaTeX. I remember being able to easily export to ODT
in the past. Has this functionality been removed or moved to a separate
package?

Re: [O] Inline code :results replace not working

[Grant Rettke]

On Mon, Nov 10, 2014 at 2:45 PM, Thomas S. Dye  wrote:
> Grant Rettke  writes:
>
>>
>> My approach here has been to use "hidden" source blocks that aren't
>> exported but make it
>> really easy to see the result during development. These settings
>> should work on any configuration,
>> so I didn't include mine here.
>
> I think you've set the :session header argument somewhere.

I did. I use:

#+begin_src emacs-lisp
(print emacs-version)
#+end_src

#+NAME:
#+begin_example

"24.3.1"
#+end_example

#+begin_src emacs-lisp
(print org-version)
#+end_src

#+NAME:
#+begin_example

"8.2.10"
#+end_example

#+begin_src emacs-lisp
(print (pp-to-string org-babel-default-header-args))
#+end_src

#+NAME:
#+begin_example

"((:eval . \"always\")
 (:padline . \"yes\")
 (:noweb . \"no-export\")
 (:exports . \"both\")
 (:results . \"output replace\")
 (:comments . \"noweb\")
 (:session . \"none\")
 (:cache . \"no\")
 (:hlines . \"no\")
 (:tangle . \"no\"))
"
#+end_example

#+begin_src emacs-lisp
(print (pp-to-string org-babel-default-header-args:R))
#+end_src

#+NAME:
#+begin_example

"((:session . \"*R*\"))
"
#+end_example

Re: [O] Inline code :results replace not working

[Thomas S. Dye]

Grant Rettke  writes:

>
> My approach here has been to use "hidden" source blocks that aren't
> exported but make it
> really easy to see the result during development. These settings
> should work on any configuration,
> so I didn't include mine here.

I think you've set the :session header argument somewhere.

>
> ✂✂
> #+BEGIN_SRC R
> a = 10
> b = 23
> c = a + b
> #+END_SRC
> #+BEGIN_SRC R :results output silent :exports none
> c
> #+END_SRC
>
> The user calculated src_R{c}.
> ✂✂
>
> When you use these functions
> http://orgmode.org/manual/Key-bindings-and-useful-functions.html#Key-bindings-and-useful-functions
> the addition of these "hidden" blocks hav almost zero cost and give me
> what I want.
>
>

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] Inline code :results replace not working

[Grant Rettke]

On Mon, Nov 10, 2014 at 11:03 AM, Ista Zahn  wrote:
> On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry  wrote:
>> On Mon, 10 Nov 2014, Andreas Leha wrote:
>
> [snip]
>
>>
>
> Nonetheless, from a literate programming perspective, I think that
> replaceable (and raw) inline results are definitely desirable.
> Regardless of the state of their implementation in orgmode right now.
>>
>>
>> +1.
>
> +1 from me as well. For exactly the reason Andreas illustrated I've
> given up on using inline results for the past year or so. Would be
> great to see this feature become usable by implementing a system for
> replacing them.

My approach here has been to use "hidden" source blocks that aren't
exported but make it
really easy to see the result during development. These settings
should work on any configuration,
so I didn't include mine here.

✂✂
#+BEGIN_SRC R
a = 10
b = 23
c = a + b
#+END_SRC

#+BEGIN_SRC R :results output silent :exports none
c
#+END_SRC

The user calculated src_R{c}.
✂✂

When you use these functions
http://orgmode.org/manual/Key-bindings-and-useful-functions.html#Key-bindings-and-useful-functions
the addition of these "hidden" blocks hav almost zero cost and give me
what I want.

Re: [O] What is the Preferred Method for Logging Creation Date?

[Karl Voit]

* Dominic Surano  wrote:
>
> be able to quickly pull up an agenda view that shows each entry on the day / 
> time it was created.

I am using (org-expiry-insinuate) from the org-expiry.el and have
those CREATED properties within my capture templates.[1]

HTH

[1] https://github.com/novoid/dot-emacs/blob/master/main.el

Re: [O] Repeated teaching classes and stopping date

[Rasmus]

Hi Xavier,

Xavier Garrido  writes:

> I'm trying to move to =org-agenda= and I'm converting some of my
> Google Calendar entries into Org agenda entries. I'm facing an issue
> with repeated tasks and how to properly stop the event. Consider the
> following entry :
>
> * [Master 1] Nuclear & particle class
> <2015-01-21 mer. 14:00-16:00 +1w>--<2015-03-22 dim.>
>
> For me it means, I will teach every week @ 14:00 to 16:00 until the
> 22th of March. I am surely doing something bad since the events
> actually appear every day until the 22th of March. It basically works
> when I remove the --<2015-03-22 dim.> but then how to stop the
> repeated tasks.
>
> Sorry if the answer is obvious but I have read org-mode manual
> (http://orgmode.org/manual/Repeated-tasks.html) and other "timestamp"
> related pages and I didn't find a way to do that.

Did you check `org-class'?  Also check
`org-clone-subtree-with-time-shift'.  If you search for the latter you
will find a recent discussion on what I think is the topic you are
interested in.

Hope it helps,
Rasmus

-- 
Evidence suggests Snowden used a powerful tool called monospaced fonts

[O] Repeated teaching classes and stopping date

[Xavier Garrido]

Dear Orgers,

I'm trying to move to =org-agenda= and I'm converting some of my Google 
Calendar entries into Org agenda entries. I'm facing an issue with 
repeated tasks and how to properly stop the event. Consider the 
following entry :


* [Master 1] Nuclear & particle class
<2015-01-21 mer. 14:00-16:00 +1w>--<2015-03-22 dim.>

For me it means, I will teach every week @ 14:00 to 16:00 until the 22th 
of March. I am surely doing something bad since the events actually 
appear every day until the 22th of March. It basically works when I 
remove the --<2015-03-22 dim.> but then how to stop the repeated tasks.


Sorry if the answer is obvious but I have read org-mode manual 
(http://orgmode.org/manual/Repeated-tasks.html) and other "timestamp" 
related pages and I didn't find a way to do that.


Thanks for your help,
Xavier

Re: [O] Inline code :results replace not working

[Ista Zahn]

On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry  wrote:
> On Mon, 10 Nov 2014, Andreas Leha wrote:

[snip]

>

 Nonetheless, from a literate programming perspective, I think that
 replaceable (and raw) inline results are definitely desirable.
 Regardless of the state of their implementation in orgmode right now.
>
>
> +1.

+1 from me as well. For exactly the reason Andreas illustrated I've
given up on using inline results for the past year or so. Would be
great to see this feature become usable by implementing a system for
replacing them.

-Ista

>
> I find myself writing an inline src block, then typing `C-c C-c C-x u' to
> view and then remove the result, then revise, and repeat. I'd be happy to
> just leave it in the document.
>
>>>
>>> FWIW, I'm not -- yet? -- convinced we should see the results of inline
>>> code blocks inlined in the paragraph (and I'm not sure either it does
>>> not cause interpretation problems); but, for sure, I'd love to be able
>>> to preview the value interactively, at least.
>>>
 So, I do not doubt, that you and Nicolas are right with that
 replaceable inline results are not implemented and are -- from
 orgmodes perspective -- expected to be evaluated only during export.

 My message was meant more as a feature request saying that I consider
 replaceable inline results useful and would like to see them supported
 by org.
>>>
>>>
>>> Could you better explain your statement: "Limiting the use of inline
>>> code to eval-on-export-only renders all the org-babel-execute-subtree
>>> and related functionality useless"?
>>>
>>> I'm not sure to fully understand your use-case.  That'd certainly be
>>> worth explaining why you think it must be changed in the first instance
>>> if you'd like Eric or Nicolas (or someone else) to change that.
>>>
>>
>> Consider this simple toy example.  If you press 'C-c C-v s' in the
>> subtree, the document is 'broken' for export.  If you press 'C-c C-v s'
>> twice or more the document is 'broken' even for display.
>>
>
> [deleted ECM]
>
> It seems like implementing removable inline results cleanly is a nettlesome
> issue.
>
> But with the recent implementation of `org-babel-inline-result-wrap' it
> would be trivial to wrap results with something like "@@babel:%s@@",
> which can be found and removed more reliably than "=%s=".
>
> On export, either the :back-end property of such export-snippets could be
> revised to the backend in use by a parse-tree filter or the code in each
> org--export-snippet could be revised to accept such snippets.
>
> There is still the matter of adding code to find and remove those snippets
> where Nicolas pointed in ob-core.al.
>
> But it seems do-able.
>
> HTH,
>
> Chuck
>

Re: [O] Problem with latest org-mode plus latest emacs 25

[Justin Gordon]

With the error, I had installed emacs like this:
brew reinstall emacs --HEAD --cocoa --srgb

That built Emacs on my yosemite mac.

Just verified that this build corrects the issue. So the issue could be
with core emacs.

http://emacsformacosx.com/builds
FileVersionDateArchitectureBuilt OnSizeEmacs-pretest-24.4-rc1-universal.dmg


On Mon, Nov 10, 2014 at 6:55 AM, Justin Gordon 
wrote:

> Org-mode version 8.2.3c (release_8.2.3c-249-g85d28b.dirty @
> /Users/justin/forks/org-mode/lisp/)
> GNU Emacs 25.0.50.1 (x86_64-apple-darwin14.0.0, NS appkit-1343.14 Version
> 10.10 (Build 14A389)) of 2014-11-10 on JustinMbp-2.local
>
> To reproduce:
> 1. Open up org file
> 2. export to markdown, buffer
>
> Debugger entered--Lisp error: (error "`recenter'ing a window that does not
> display current-buffer.")
>   recenter((4))
>   (let ((pos (point)) (level (save-excursion (goto-char (point-min)) (if
> (re-search-forward (concat "^" outline-regexp) nil t) (progn (goto-char
> (match-beginning 0)) (funcall outline-level)) (and level
> (hide-sublevels level)) (recenter (quote (4))) (goto-char pos))
>   org-overview()
>   (cond ((eq org-startup-folded t) (org-overview)) ((eq org-startup-folded
> (quote content)) (org-content)) ((or (eq org-startup-folded (quote
> showeverything)) (eq org-startup-folded nil)) (show-all)))
>
>
> Any work around?
>
>
> --
> Justin Gordon | 808-877-6461 | m: 808-281-7272 | talksurf.com
> 
> www.railsonmaui.com  | twitter: @railsonmaui
>  | sugarranchmaui.com
>  | Sugar Ranch Blog
> 
>



-- 
Justin Gordon | 808-877-6461 | m: 808-281-7272 | talksurf.com

www.railsonmaui.com  | twitter: @railsonmaui
 | sugarranchmaui.com
 | Sugar Ranch Blog

[O] Problem with latest org-mode plus latest emacs 25

[Justin Gordon]

Org-mode version 8.2.3c (release_8.2.3c-249-g85d28b.dirty @
/Users/justin/forks/org-mode/lisp/)
GNU Emacs 25.0.50.1 (x86_64-apple-darwin14.0.0, NS appkit-1343.14 Version
10.10 (Build 14A389)) of 2014-11-10 on JustinMbp-2.local

To reproduce:
1. Open up org file
2. export to markdown, buffer

Debugger entered--Lisp error: (error "`recenter'ing a window that does not
display current-buffer.")
  recenter((4))
  (let ((pos (point)) (level (save-excursion (goto-char (point-min)) (if
(re-search-forward (concat "^" outline-regexp) nil t) (progn (goto-char
(match-beginning 0)) (funcall outline-level)) (and level
(hide-sublevels level)) (recenter (quote (4))) (goto-char pos))
  org-overview()
  (cond ((eq org-startup-folded t) (org-overview)) ((eq org-startup-folded
(quote content)) (org-content)) ((or (eq org-startup-folded (quote
showeverything)) (eq org-startup-folded nil)) (show-all)))


Any work around?


-- 
Justin Gordon | 808-877-6461 | m: 808-281-7272 | talksurf.com

www.railsonmaui.com  | twitter: @railsonmaui
 | sugarranchmaui.com
 | Sugar Ranch Blog

Re: [O] Inline code :results replace not working

[Charles C. Berry]

On Mon, 10 Nov 2014, Andreas Leha wrote:


Hi Sebastien,

Sebastien Vauban  writes:

Andreas Leha wrote:

Sebastien Vauban  writes:

Andreas Leha wrote:

For me, that's the correct behavior, as inline code blocks are
*only expected to be evaluated during export*.


I disagree here.




[snip]



Nonetheless, from a literate programming perspective, I think that
replaceable (and raw) inline results are definitely desirable.
Regardless of the state of their implementation in orgmode right now.


+1.

I find myself writing an inline src block, then typing `C-c C-c C-x u' to 
view and then remove the result, then revise, and repeat. I'd be happy to 
just leave it in the document.




FWIW, I'm not -- yet? -- convinced we should see the results of inline
code blocks inlined in the paragraph (and I'm not sure either it does
not cause interpretation problems); but, for sure, I'd love to be able
to preview the value interactively, at least.


So, I do not doubt, that you and Nicolas are right with that
replaceable inline results are not implemented and are -- from
orgmodes perspective -- expected to be evaluated only during export.

My message was meant more as a feature request saying that I consider
replaceable inline results useful and would like to see them supported
by org.


Could you better explain your statement: "Limiting the use of inline
code to eval-on-export-only renders all the org-babel-execute-subtree
and related functionality useless"?

I'm not sure to fully understand your use-case.  That'd certainly be
worth explaining why you think it must be changed in the first instance
if you'd like Eric or Nicolas (or someone else) to change that.



Consider this simple toy example.  If you press 'C-c C-v s' in the
subtree, the document is 'broken' for export.  If you press 'C-c C-v s'
twice or more the document is 'broken' even for display.



[deleted ECM]

It seems like implementing removable inline results cleanly is a 
nettlesome issue.


But with the recent implementation of `org-babel-inline-result-wrap' it 
would be trivial to wrap results with something like "@@babel:%s@@",

which can be found and removed more reliably than "=%s=".

On export, either the :back-end property of such export-snippets could be 
revised to the backend in use by a parse-tree filter or the code in each 
org--export-snippet could be revised to accept such snippets.


There is still the matter of adding code to find and remove those snippets 
where Nicolas pointed in ob-core.al.


But it seems do-able.

HTH,

Chuck

Re: [O] [Feature Request] HEADLINE special property

[Nicolas Goaziou]

Brett Witty  writes:

> Seems like a good solution. Although how about HEADLINE_LEVEL,
> OUTLINE_LEVEL or some abbreviation to make it more unlikely to clash with
> user defined properties?

I stripped all meta-data from "ITEM" special property in master.
However, I kept the stars as they inform about relationship between
headlines in a columnview table.

Please report if you encounter any bug.


Regards,

Re: [O] 'remembering' not quite working right.

[Sharon Kimble]

Nick Dokos  writes:

> Sharon Kimble  writes:
>
>> I am able to 'remember' text with highlighting the text required, and
>> copying it to the clipboard, and then "C-c r" remembers it, and shows in
>> its popup buffer that I need to "C-c C-c" to copy/move it to my remember
>> storage file. Except, the last bit doesn't work for me, instead it
>> calls the "Tag" command which opens "Tag: " in the mini-buffer which
>> just sits and waits for some response.
>>
>> When I 'remember' something, this shows in its buffer -
>>
>> # C-c C-c  "~/.emacs.d/org/remember.org" -> "* Interesting"
>> # C-u C-c C-c  like C-c C-c, and immediately visit note at target location
>> # C-0 C-c C-c  "???" -> "* ???"
>> # C-1 C-c C-c  to select file and header location interactively.
>> # C-2 C-c C-c  as child (C-3: as sibling) of the currently clocked item
>> # To switch templates, use `M-x org-remember'.  To abort use `C-c C-k'.
>>
>> How then can I get it working right please?
>>
>
> Remember (ha!) that org-remember is obsolete, replaced by org-capture.

I'm covering all bases with -

--8<---cut here---start->8---
(require 'remember)
(require 'org-capture)
(require 'org-remember)
--8<---cut here---end--->8---

Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
my git repo = https://bitbucket.org/boudiccas/dots
TGmeds = http://www.tgmeds.org.uk
Debian testing, fluxbox 1.3.5, emacs 24.4.1.0


signature.asc
Description: PGP signature

Re: [O] What is the Preferred Method for Logging Creation Date?

[Ian Barton]

On 10/11/14 14:18, Ian Barton wrote:

On 06/11/14 20:20, Dominic Surano wrote:

I'm a huge fan of Org-mode and have been using it daily for a little
over a
year. I've been following this list for about 8 months and really benefit
from
the level of technical discussion. I've finally encountered a methodology
problem that I haven't quite been able to wrap my head around and I'm
curious
how other people implement this functionality.

I'm a heavy user of capture templates. One thing I've been struggling
with
for a while now is how to appropriately log the creation time of such
templates
in a way that can be useful for agenda views. Knowing WHEN I created a
heading is often just as useful as the content in the heading. The end
goal
is to
be able to quickly pull up an agenda view that shows each entry on the
day /
time it was created.

For all the examples below, I've just included the FINAL output from org-
capture rather than the templates themselves. I feel I have a pretty good
understanding of capture templates, but can provide them if you think
they'll help in formulating a solution.

Org-mode currently has built in support for DEADLINE, SCHEDULED, and
CLOSED
times. Ideally, for my use cases, CREATED would also be built in such
that
headings would look like:

* DONE Task
   CLOSED: [2014-11-06 Thu 10:59] DEADLINE: <2014-11-06 Thu> CREATED:
[2014-
11-06 Thu 10:50]
   :LOGBOOK:
   - State "DONE"   from "TODO"   [2014-11-06 Thu 10:59]
   :END:
   :PROPERTIES:
   :Via:  Origin of this task
   :Note: Note describing task
   :ID:   64f7fa18-0936-46cb-a2c8-21a0fbc9bae3
   :END:

And I would be able to pull up an agenda view using a similarly named
special property
(http://orgmode.org/manual/Special-properties.html#Special-
properties). Unfortunately, since CREATED is not a special property, I
end
up with:

* DONE Task
   CLOSED: [2014-11-06 Thu 10:59] DEADLINE: <2014-11-06 Thu>
   :LOGBOOK:
   - State "DONE"   from "TODO"   [2014-11-06 Thu 10:59]
   :END:
   CREATED: [2014-11-06 Thu 10:50]
   :PROPERTIES:
   :Via:  Origin of this task
   :Note: Note describing task
   :ID:   64f7fa18-0936-46cb-a2c8-21a0fbc9bae3
   :END:

I consider this similar to Bernt Hansen's approach
(http://doc.norang.ca/org-mode.html#InsertInactiveTimestamps). Turning on
inactive timestamps, using v
[ in the agenda view, doesn't just pull up the CREATED time, but also the
state change time in LOGBOOK in addition to any other inactive timestamps
(either in the entry, notes in LOGBOOK, etc.). I've considered using the
special property TIMESTAMP_IA, but unfortunately, as shown above
"CREATED:
..."
always ends up getting bumped down when a state change is made or note is
taken, and the :LOGBOOK: drawer is created.

I have no doubt that implementing CREATED as a special time would be non-
trivial.

Here are some solutions I've contemplated implementing:

1) Including the creation date in the logbook using a format
consistent with
org-todo state changes:

* DONE Task
   CLOSED: [2014-11-06 Thu 10:59] DEADLINE: <2014-11-06 Thu>
   :LOGBOOK:
   - State "DONE"   from "TODO"   [2014-11-06 Thu 10:59]
   - State "TODO"   from ""   [2014-11-06 Thu 10:50]
   :END:
   :PROPERTIES:
   :Via:  Origin of this task
   :Note: Note describing task
   :ID:   64f7fa18-0936-46cb-a2c8-21a0fbc9bae3
   :END:

This seems to make a lot of sense (although I'm still unclear about
how to
generate the aforementioned agenda view), but it breaks down for capture
templates that don't use org-todo-keywords (i.e. are ALWAYS stateless).

2) Including the creation date in the logbook using something similar to
note (C-c z):

* DONE Task
   CLOSED: [2014-11-06 Thu 10:59] DEADLINE: <2014-11-06 Thu>
   :LOGBOOK:
   - State "DONE"   from "TODO"   [2014-11-06 Thu 10:59]
   - Created from capture template on [2014-11-06 Thu 10:50]
   :END:
   :PROPERTIES:
   :Via:  Origin of this task
   :Note: Note describing task
   :ID:   64f7fa18-0936-46cb-a2c8-21a0fbc9bae3
   :END:

This makes sense, but breaks consistency with org-todo state changes
and has
the same agenda problem described in (1).

3) Including the creation date in a the property drawer:

* DONE Task
   CLOSED: [2014-11-06 Thu 10:59] DEADLINE: <2014-11-06 Thu>
   :LOGBOOK:
   - State "DONE"   from "TODO"   [2014-11-06 Thu 10:59]
   - State "TODO"   from ""   [2014-11-06 Thu 10:50]
   :END:
   :PROPERTIES:
   :Via:  Origin of this task
   :Note: Note describing task
   :Created:  [2014-11-06 Thu 10:50]
   :ID:   64f7fa18-0936-46cb-a2c8-21a0fbc9bae3
   :END:

This would maintain consistency with org-todo, but I'm not sure how I
would
generate the agenda view. It seems to be the preferred method for
users of
org-expiry.el.



Not quite what you wanted, but I use CREATED in the PROPERTY draw:

("t" "Todo" entry (file+headline
"~/Documents/emacs/org/org_files/tasks/todo.org" "Tasks") "* TODO
%?\nSCHEDULED: %^t\n

Re: [O] What is the Preferred Method for Logging Creation Date?

[Ian Barton]

On 06/11/14 20:20, Dominic Surano wrote:

I'm a huge fan of Org-mode and have been using it daily for a little over a
year. I've been following this list for about 8 months and really benefit
from
the level of technical discussion. I've finally encountered a methodology
problem that I haven't quite been able to wrap my head around and I'm
curious
how other people implement this functionality.

I'm a heavy user of capture templates. One thing I've been struggling with
for a while now is how to appropriately log the creation time of such
templates
in a way that can be useful for agenda views. Knowing WHEN I created a
heading is often just as useful as the content in the heading. The end goal
is to
be able to quickly pull up an agenda view that shows each entry on the day /
time it was created.

For all the examples below, I've just included the FINAL output from org-
capture rather than the templates themselves. I feel I have a pretty good
understanding of capture templates, but can provide them if you think
they'll help in formulating a solution.

Org-mode currently has built in support for DEADLINE, SCHEDULED, and CLOSED
times. Ideally, for my use cases, CREATED would also be built in such that
headings would look like:

* DONE Task
   CLOSED: [2014-11-06 Thu 10:59] DEADLINE: <2014-11-06 Thu> CREATED: [2014-
11-06 Thu 10:50]
   :LOGBOOK:
   - State "DONE"   from "TODO"   [2014-11-06 Thu 10:59]
   :END:
   :PROPERTIES:
   :Via:  Origin of this task
   :Note: Note describing task
   :ID:   64f7fa18-0936-46cb-a2c8-21a0fbc9bae3
   :END:

And I would be able to pull up an agenda view using a similarly named
special property (http://orgmode.org/manual/Special-properties.html#Special-
properties). Unfortunately, since CREATED is not a special property, I end
up with:

* DONE Task
   CLOSED: [2014-11-06 Thu 10:59] DEADLINE: <2014-11-06 Thu>
   :LOGBOOK:
   - State "DONE"   from "TODO"   [2014-11-06 Thu 10:59]
   :END:
   CREATED: [2014-11-06 Thu 10:50]
   :PROPERTIES:
   :Via:  Origin of this task
   :Note: Note describing task
   :ID:   64f7fa18-0936-46cb-a2c8-21a0fbc9bae3
   :END:

I consider this similar to Bernt Hansen's approach
(http://doc.norang.ca/org-mode.html#InsertInactiveTimestamps). Turning on
inactive timestamps, using v
[ in the agenda view, doesn't just pull up the CREATED time, but also the
state change time in LOGBOOK in addition to any other inactive timestamps
(either in the entry, notes in LOGBOOK, etc.). I've considered using the
special property TIMESTAMP_IA, but unfortunately, as shown above "CREATED:
..."
always ends up getting bumped down when a state change is made or note is
taken, and the :LOGBOOK: drawer is created.

I have no doubt that implementing CREATED as a special time would be non-
trivial.

Here are some solutions I've contemplated implementing:

1) Including the creation date in the logbook using a format consistent with
org-todo state changes:

* DONE Task
   CLOSED: [2014-11-06 Thu 10:59] DEADLINE: <2014-11-06 Thu>
   :LOGBOOK:
   - State "DONE"   from "TODO"   [2014-11-06 Thu 10:59]
   - State "TODO"   from ""   [2014-11-06 Thu 10:50]
   :END:
   :PROPERTIES:
   :Via:  Origin of this task
   :Note: Note describing task
   :ID:   64f7fa18-0936-46cb-a2c8-21a0fbc9bae3
   :END:

This seems to make a lot of sense (although I'm still unclear about how to
generate the aforementioned agenda view), but it breaks down for capture
templates that don't use org-todo-keywords (i.e. are ALWAYS stateless).

2) Including the creation date in the logbook using something similar to
note (C-c z):

* DONE Task
   CLOSED: [2014-11-06 Thu 10:59] DEADLINE: <2014-11-06 Thu>
   :LOGBOOK:
   - State "DONE"   from "TODO"   [2014-11-06 Thu 10:59]
   - Created from capture template on [2014-11-06 Thu 10:50]
   :END:
   :PROPERTIES:
   :Via:  Origin of this task
   :Note: Note describing task
   :ID:   64f7fa18-0936-46cb-a2c8-21a0fbc9bae3
   :END:

This makes sense, but breaks consistency with org-todo state changes and has
the same agenda problem described in (1).

3) Including the creation date in a the property drawer:

* DONE Task
   CLOSED: [2014-11-06 Thu 10:59] DEADLINE: <2014-11-06 Thu>
   :LOGBOOK:
   - State "DONE"   from "TODO"   [2014-11-06 Thu 10:59]
   - State "TODO"   from ""   [2014-11-06 Thu 10:50]
   :END:
   :PROPERTIES:
   :Via:  Origin of this task
   :Note: Note describing task
   :Created:  [2014-11-06 Thu 10:50]
   :ID:   64f7fa18-0936-46cb-a2c8-21a0fbc9bae3
   :END:

This would maintain consistency with org-todo, but I'm not sure how I would
generate the agenda view. It seems to be the preferred method for users of
org-expiry.el.



Not quite what you wanted, but I use CREATED in the PROPERTY draw:

("t" "Todo" entry (file+headline
"~/Documents/emacs/org/org_files/tasks/todo.org" "Tasks") "* TODO 
%?\nSCHEDULED: %^t\n

:PROPERTIES:\n:CREATED: %U\n:LOGGING

Re: [O] [RFC] Change property drawer syntax

[Sebastien Vauban]

Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> Isn't that somehow duplicate with `org-indent-mode' (which I don't
>> enable either)?
>
> `org-indent-mode' sets `org-adapt-indentation' to nil _and_ indents
> virtually (no modification to the document) body as if
> `org-adapt-indentation' wasn't nil.
>
> There's no duplication here.

Very clear, thank you.

>> Would I want to let the indentation following the level of the entries,
>> I'm not sure what I'd have to do:
>>
>> - (org-indent-mode), and/or
>> - (setq org-adapt-indentation t)?
>
> I cannot decide for you. But editing will certainly be snappier without
> `org-indent-mode' active.

I don't want neither physical nor virtual adaptation of the
indentation. My question was for the purpose of understanding more.

>> [1] And that simplifies A LOT file diffs...
>>
>> Hence, another question: shouldn't the default be reversed (no
>> adaption of indentation, by default)?
>
> I like the current default. However I don't mind changing it if it is
> very uncommon among users to set it to a non-nil value. 

For me, choosing one over the other is a question of taste, and can't be
debated as such. Here, though, as adapting the indentation complexifies
all diffs between different versions of the file, yes, I'd choose for
the "simpler" road as the default for the Org beginners.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [RFC] Change property drawer syntax

[Nicolas Goaziou]

Sebastien Vauban 
writes:

> Isn't that somehow duplicate with `org-indent-mode' (which I don't
> enable either)?

`org-indent-mode' sets `org-adapt-indentation' to nil _and_ indents
virtually (no modification to the document) body as if
`org-adapt-indentation' wasn't nil.

There's no duplication here.

> Would I want to let the indentation following the level of the entries,
> I'm not sure what I'd have to do:
>
> - (org-indent-mode), and/or
> - (setq org-adapt-indentation t)?

I cannot decide for you. But editing will certainly be snappier without
`org-indent-mode' active.

> [1] And that simplifies A LOT file diffs...
>
> Hence, another question: shouldn't the default be reversed (no
> adaption of indentation, by default)?

I like the current default. However I don't mind changing it if it is
very uncommon among users to set it to a non-nil value. 

Note that it doesn't appear in
.
Admittedly, the survey is outdated.

Regards,

Re: [O] Inline code :results replace not working

[Andreas Leha]

Hi Sebastien,

Sebastien Vauban  writes:
> Andreas Leha wrote:
>> Sebastien Vauban  writes:
>>> Andreas Leha wrote:
> For me, that's the correct behavior, as inline code blocks are
> *only expected to be evaluated during export*.

 I disagree here.
>>>
>>> Though, this is what Eric Schulte wrote:
>>>
>>>   ┌
>>>   │ Currently inline blocks like don't associate themselves with their
>>>   │ results, they are only expected to be evaluated on export.
>>>   └
>>>
>>> If things have changed, I'm not aware of it.
>>>
 As limiting the use of inline code to eval-on-export-only renders
 all the org-babel-execute-subtree and related functionality useless.
>>
>> I have been using inline results for reports quite a bit, but not
>> lately.  I might be wrong here, but from my memory they used to work
>> (i.e. were replaceable) for a while (at least when 'wrapped') unless
>> they were set to produce 'raw' results (which was a serious limitation
>> and led me to change my workflow).
>>
>> PS: a quick check reveals that they are indeed not replaceable (even
>> when wrapped)
>>
>> Nonetheless, from a literate programming perspective, I think that
>> replaceable (and raw) inline results are definitely desirable.
>> Regardless of the state of their implementation in orgmode right now.
>
> FWIW, I'm not -- yet? -- convinced we should see the results of inline
> code blocks inlined in the paragraph (and I'm not sure either it does
> not cause interpretation problems); but, for sure, I'd love to be able
> to preview the value interactively, at least.
>
>> So, I do not doubt, that you and Nicolas are right with that
>> replaceable inline results are not implemented and are -- from
>> orgmodes perspective -- expected to be evaluated only during export.
>>
>> My message was meant more as a feature request saying that I consider
>> replaceable inline results useful and would like to see them supported
>> by org.
>
> Could you better explain your statement: "Limiting the use of inline
> code to eval-on-export-only renders all the org-babel-execute-subtree
> and related functionality useless"?
>
> I'm not sure to fully understand your use-case.  That'd certainly be
> worth explaining why you think it must be changed in the first instance
> if you'd like Eric or Nicolas (or someone else) to change that.
>

Consider this simple toy example.  If you press 'C-c C-v s' in the
subtree, the document is 'broken' for export.  If you press 'C-c C-v s'
twice or more the document is 'broken' even for display.

--8<---cut here---start->8---
#+PROPERTY: header-args:R :session *testR*

* Simplistic Literate Program

Let us generate some data $X$ with

#+begin_src R :exports code :results none
  X <- rnorm(1:1000) 
#+end_src

and plot the density of it

#+begin_src R :results graphics :file test.png :exports both
  plot(density(X)) 
#+end_src

#+results:
[[file:test.png]]

This data has mean src_R{mean(X)}.
--8<---cut here---end--->8---

Regards,
Andreas

Re: [O] Inline code :results replace not working

[Sebastien Vauban]

Andreas Leha wrote:
> Sebastien Vauban  writes:
>> Andreas Leha wrote:
 For me, that's the correct behavior, as inline code blocks are
 *only expected to be evaluated during export*.
>>>
>>> I disagree here.
>>
>> Though, this is what Eric Schulte wrote:
>>
>>   ┌
>>   │ Currently inline blocks like don't associate themselves with their
>>   │ results, they are only expected to be evaluated on export.
>>   └
>>
>> If things have changed, I'm not aware of it.
>>
>>> As limiting the use of inline code to eval-on-export-only renders
>>> all the org-babel-execute-subtree and related functionality useless.
>
> I have been using inline results for reports quite a bit, but not
> lately.  I might be wrong here, but from my memory they used to work
> (i.e. were replaceable) for a while (at least when 'wrapped') unless
> they were set to produce 'raw' results (which was a serious limitation
> and led me to change my workflow).
>
> PS: a quick check reveals that they are indeed not replaceable (even
> when wrapped)
>
> Nonetheless, from a literate programming perspective, I think that
> replaceable (and raw) inline results are definitely desirable.
> Regardless of the state of their implementation in orgmode right now.

FWIW, I'm not -- yet? -- convinced we should see the results of inline
code blocks inlined in the paragraph (and I'm not sure either it does
not cause interpretation problems); but, for sure, I'd love to be able
to preview the value interactively, at least.

> So, I do not doubt, that you and Nicolas are right with that
> replaceable inline results are not implemented and are -- from
> orgmodes perspective -- expected to be evaluated only during export.
>
> My message was meant more as a feature request saying that I consider
> replaceable inline results useful and would like to see them supported
> by org.

Could you better explain your statement: "Limiting the use of inline
code to eval-on-export-only renders all the org-babel-execute-subtree
and related functionality useless"?

I'm not sure to fully understand your use-case.  That'd certainly be
worth explaining why you think it must be changed in the first instance
if you'd like Eric or Nicolas (or someone else) to change that.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [RFC] Change property drawer syntax

[Sebastien Vauban]

Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> It does work perfectly on the "meta-stuff" (SCHEDULED, DEADLINE,
>> etc.). Though, it moves as well the "body" text -- while I'm not using
>> `org-indent-mode'.
>>
>> * New section
>>
>> * The SCHED will be moved
>>   SCHEDULED: <2011-08-18 Thu>
>>
>> ** This one won't be moved along with the heading
>>SCHEDULED: <2011-08-18 Thu>
>>
>>  Because of this text here...
>> ^ Space inserted here.
>
> This is expected, actually. I realize that `org-adapt-indentation'
> docstring is not totally up-to-date.
>
> If your indentation shouldn't depend on the current headline level,

Yes, that's what I want [1]!

> you might want to set this variable to nil.

Isn't that somehow duplicate with `org-indent-mode' (which I don't
enable either)?

  ┌
  │ org-indent-mode is an interactive autoloaded Lisp function in 
`org-indent.el'.
  │ 
  │ (org-indent-mode &optional ARG)
  │ 
  │ When active, indent text according to outline structure.
  │ 
  │ Internally this works by adding `line-prefix' and `wrap-prefix'
  │ properties, after each buffer modification, on the modified zone.
  │ 
  │ The process is synchronous.  Though, initial indentation of
  │ buffer, which can take a few seconds on large buffers, is done
  │ during idle time.
  └

Would I want to let the indentation following the level of the entries,
I'm not sure what I'd have to do:

- (org-indent-mode), and/or
- (setq org-adapt-indentation t)?

Best regards,
  Seb

[1] And that simplifies A LOT file diffs...

Hence, another question: shouldn't the default be reversed (no
adaption of indentation, by default)?

-- 
Sebastien Vauban

Re: [O] Inline code :results replace not working

[Andreas Leha]

Hi,

Sebastien Vauban  writes:
> Andreas Leha wrote:
>>> For me, that's the correct behavior, as inline code blocks are *only
>>> expected to be evaluated during export*.
>>
>> I disagree here.  As limiting the use of inline code to
>> eval-on-export-only renders all the org-babel-execute-subtree and
>> related functionality useless.
>
> Though, this is what Eric Schulte wrote:
>
>   ┌ https://lists.gnu.org/archive/html/emacs-orgmode/2012-04/msg00490.html
>   │
>   │ Currently inline blocks like don't associate themselves with their
>   │ results, they are only expected to be evaluated on export.
>   └
>
> Admittedly, this is an old quote (2012).  If things have changed, I'm
> not aware of it -- but that does not mean it did not.

I have been using inline results for reports quite a bit, but not
lately.  I might be wrong here, but from my memory they used to work
(i.e. were replaceable) for a while (at least when 'wrapped') unless
they were set to produce 'raw' results (which was a serious limitation
and led me to change my workflow).

Nonetheless, from a literate programming perspective, I think that
replaceable (and raw) inline results are definitely desirable.
Regardless of the state of their implementation in orgmode right now.

So, I do not doubt, that you and Nicolas are right with that replaceable
inline results are not implemented and are -- from orgmodes perspective
-- expected to be evaluated only during export.

My message was meant more as a feature request saying that I consider
replaceable inline results useful and would like to see them supported
by org.

Regards,
Andreas

PS:
a quick check reveals that they are indeed not replaceable (even
when wrapped)
--8<---cut here---start->8---
* Test replacement of inline results

Here is an inline result src_R[:results wrap replace]{3+2}.
--8<---cut here---end--->8---

[O] Selection of TODO entry keyword with S-right arrow

[Sebastien Vauban]

Hello,

Up to recently, with the following customization:

--8<---cut here---start->8---
  (setq org-todo-keywords
'((sequence "NEW(n!)" "TODO(t!)" "STRT(s!)" "WAIT(w!)" "SDAY(y!)"
"|" "DONE(d!)" "CANX(x!)")
  (sequence "QTE(q!)" "QTD(Q!)"
"|" "APP(A!)" "REJ(R!)") 
  (sequence "OPENPO(O!)"
"|" "CLSDPO(C!)")))
--8<---cut here---end--->8---

To select the TODO state "NEW" or "TODO" for an entry which had no TODO
keyword, I just had to `S-right' once or twice:

1. NEW
2. TODO

Now, `S-right' does cycle in a new order:

1. OPENPO
2. CLSDPO
3. QTE
4. QTD
5. APP
6. REJ
7. NEW
8. TODO

See http://screencast.com/t/FyECLZ3y.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [RFC] Change property drawer syntax

[Nicolas Goaziou]

Sebastien Vauban 
writes:

> It does work perfectly on the "meta-stuff" (SCHEDULED, DEADLINE,
> etc.). Though, it moves as well the "body" text -- while I'm not using
> `org-indent-mode'.
>
> * New section
>
> * The SCHED will be moved
>   SCHEDULED: <2011-08-18 Thu>
>
> ** This one won't be moved along with the heading
>SCHEDULED: <2011-08-18 Thu>
>
>  Because of this text here...
> ^ Space inserted here.

This is expected, actually. I realize that `org-adapt-indentation'
docstring is not totally up-to-date.

If your indentation shouldn't depend on the current headline level, you
might want to set this variable to nil.


Regards,

Re: [O] Inline code :results replace not working

[Sebastien Vauban]

Andreas Leha wrote:
>> For me, that's the correct behavior, as inline code blocks are *only
>> expected to be evaluated during export*.
>
> I disagree here.  As limiting the use of inline code to
> eval-on-export-only renders all the org-babel-execute-subtree and
> related functionality useless.

Though, this is what Eric Schulte wrote:

  ┌ https://lists.gnu.org/archive/html/emacs-orgmode/2012-04/msg00490.html
  │
  │ Currently inline blocks like don't associate themselves with their
  │ results, they are only expected to be evaluated on export.
  └

Admittedly, this is an old quote (2012).  If things have changed, I'm
not aware of it -- but that does not mean it did not.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [RFC] Change property drawer syntax

[Sebastien Vauban]

Hello Nicolas,

Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> One question, now that this syntax is stabilized, can the following
>> long-standing bug be fixed: sometimes the SCHEDULED line (or
>> DEADLINE, or ...) is moved synchronously with the heading when
>> promoting/demoting, sometimes not.
>>
>> I found in which cases it does and when it does not: it depends on
>> the presence of text in the entry.
>>
>> So, for example:
>>
>> --8<---cut here---start->8---
>> * The SCHED will be moved
>>   SCHEDULED: <2011-08-18 Thu>
>>
>> * This one won't be moved along with the heading
>>   SCHEDULED: <2011-08-18 Thu>
>>
>> Because of this text here...
>> --8<---cut here---end--->8---
>>
>> becomes, when *demoted*:
>>
>> --8<---cut here---start->8---
>> * New section
>>
>> ** The SCHED will be moved
>>SCHEDULED: <2011-08-18 Thu>
>>
>> ** This one won't be moved along with the heading
>>   SCHEDULED: <2011-08-18 Thu>
>>
>> Because of this text here...
>> --8<---cut here---end--->8---
>>
>> This had been fixed by Bastien in August 2011, but the fix had reverted
>> afterward.
>
> I pushed a change that should make indentation shift hopefully smarter.

It does work perfectly on the "meta-stuff" (SCHEDULED, DEADLINE,
etc.). Though, it moves as well the "body" text -- while I'm not using
`org-indent-mode'.

--8<---cut here---start->8---
* New section

* The SCHED will be moved
  SCHEDULED: <2011-08-18 Thu>

** This one won't be moved along with the heading
   SCHEDULED: <2011-08-18 Thu>

 Because of this text here...
--8<---cut here---end--->8---
^ Space inserted here.

See http://screencast.com/t/2AkkSTpqe5.

> Thank you for reminding me about this.

Thanks to you for your continuous support!  We don't say it enough ;-(

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [bug?, ox-odt] Format DATE

[Rasmus]

Christian Moe  writes:

>>> Going by the documentation of org-odt-use-date-fields, the data styles
>>> "OrgDate1" and "OrgDate2" are supposed to be mapped from
>>> org-time-stamp-custom-formats, rather than
>>> org-export-date-timestamp-format. 
>>
>> Yeah, I saw that, but the description of
>> `org-time-stamp-custom-formats' looks a bit opaque.  I wondered if it
>> would affect the recognition of timestamps in buffer (since the
>> variable is not an org-export-· variable).  If it's truly *only*
>> affecting exports it should be renamed.
>
> No, judging by the manual entry, it was intended for customizing the
> appearance of timestamps in the buffer, which it does, see below. To
> accommodate people who think ISO time format is just too darned
> /sensible/...

O-o-okay.

> But it has the nice (and little-mentioned) side effect that you can use
> it to change the appearance of timestamps in exports, where
> non-geeky-looking everyday-language dates are often comme il faut. Works
> nicely in HTML, for instance, except that you still get geeky-looking
> brackets around the dates (may need a filter to remove those).

While I really want this functionality, I think that this way of using
it is a bug.  It should depend on a separate org-export-· variable. ..

> It's nice, for instance, if you have a document with a lot of dates in a
> European format and need to switch to an American format; you can do it
> by changing a setting.

Wait, so does this variable change how dates are interpreted or not?
I.e. can I "choose" whether <2010-01-10> is January 10th or October
first?  Or is an Org timestamp always in sensible ISO?

> And the ODT exporter builds on this to give date fields that can be
> further changed in LibreOffice.

Right.

>>> So this will apply to the output from the DATE keyword too.
>>>
>>> To make this happen, org-display-custom-times must be non-nil. 
>>> This affects not only the date in the heading from the DATE keyword,
>>> but also all other timestamps in the document.
>>>
>>> Having org-display-custom-times turned on all the time also puts
>>> overlays on the timestamps in your buffer, but if this annoys you you
>>> can bind it to be set during export only.
>>
>> OK.  I don't know this functionality.  It sounds less bad that what I
>> feared, but still the org-export-· variables should probably be
>> sufficient.
>>
>> Is `org-time-stamp-custom-formats' the recommend way of formatting
>> regular time stamps for export?
>
> I don't know about "recommended". It doesn't seem to be documented for
> export at all. And as for ODT, the code comments say the feature
> translating from custom time stamp formats to ODT date styles is
> "experimental". Seems to work OK, though.

I like the possibility, but I think export and buffer display should be
separated.

>>> But doing it this way still ignores
>>> org-export-date-timestamp-format, and any solution based on copying that
>>> variable into org-time-stamp-custom-formats makes unsafe assumptions about
>>> user preferences.
>>
>> Yes.
>>
>>> It seems to me that the export of the DATE keyword ought to honor a
>>> non-nil org-export-date-timestamp-format, whether or not the user is
>>> applying custom formatting to other timestamps. 
>>> But that would take some
>>> changes to several parts of ox-odt.el, I think.
>>
>> Yeah.  It's can be made even more complicated than that, since the
>> *document language* of the output also affects how dates are
>> formatted. . .
>
> In Org, or in LibreOffice once you set the language there? 

In LO some of the date formatting is a function of the document
language.  The document language (or maybe region language, I don't
really know...) is seen at the bottom.

Date has a gray background indicating it's special...  With sufficient
time and creativity you can get to a menu for formatting the date.  Some
of these formats (especially the "human-friendly" ones) will depend on
the language.

On the other hand, "Table of Contents" seems completely independent of
the document language. . .

> If the #+LANGUAGE keyword is supposed to affect date formatting in Org
> output, I must be missing a trick.

I think #+DATE might not be truly affected by #+LANGUAGE, after all, but
rather be affected of different system languages on my two home-PC and
work-PC (I'm unable to get this computer—which has English as a system
language—to export dates in other languages via
org-export-date-timestamp-format).  

This is probably a separate bug.

>> So a two step method would be: (0) make sure that the document
>> language is set correctly (similar to how the right babel language is
>> selected in LaTeX), and (1) be able to change the format of the date.
>>
>> Or we could lose the date-stamp-feature and insert the date as
>> plaintext.  This is probably simpler, but I don't know if this is the
>> "correct" way.

>>> Rasmus, will you be pursuing this?
>> If you are thinking about fixing this, I won't stop you!  I dread
>> ·xml.  This weekend sort 

Re: [O] Inline code :results replace not working

[Andreas Leha]

Hi

Sebastien Vauban  writes:
> Nicolas Goaziou wrote:
>> Hello,
>>
>> mcg  writes:
>>
>>> I use inline code for simple calculations to insert numeric results into
>>> text apart from "normal" code blocks for more complex calculations and
>>> graphics (all in R).
>>>
>>>
>>> The :results replace option is not working for inline code, even if I
>>> explicitly set it in the code block. So I get
>>>
>>> #+PROPERTY: session *R*
>>>
>>>   #+begin_src R :results replace value
>>> 2+3
>>>   #+end_src
>>>
>>>   #+RESULTS:
>>>   : 5
>>>
>>> src_R[:results replace value]{2+3} =5= =5= =5= =5= =5= =5=
>>>
>>> I would really like to have numeric outcome in the buffer (not only
>>> minibuffer upon evaluation) but also evaluate the whole buffer when
>>> exporting to have everything updated.
>>>
>>> What is the problem here? For now I would have to
>>> - evaluate only on export and keep :results silent
>>> - evaluate all manually - meaning I get repeated results if I call
>>> org-evaluate buffer
>>
>> :results replace is not implemented (yet?) for inline source blocks.
>
> For me, that's the correct behavior, as inline code blocks are *only
> expected to be evaluated during export*.
>

I disagree here.  As limiting the use of inline code to
eval-on-export-only renders all the org-babel-execute-subtree and
related functionality useless.

Regards,
Andreas

Re: [O] Inline code :results replace not working

[Sebastien Vauban]

Nicolas Goaziou wrote:
> Hello,
>
> mcg  writes:
>
>> I use inline code for simple calculations to insert numeric results into
>> text apart from "normal" code blocks for more complex calculations and
>> graphics (all in R).
>>
>>
>> The :results replace option is not working for inline code, even if I
>> explicitly set it in the code block. So I get
>>
>> #+PROPERTY: session *R*
>>
>>   #+begin_src R :results replace value
>> 2+3
>>   #+end_src
>>
>>   #+RESULTS:
>>   : 5
>>
>> src_R[:results replace value]{2+3} =5= =5= =5= =5= =5= =5=
>>
>> I would really like to have numeric outcome in the buffer (not only
>> minibuffer upon evaluation) but also evaluate the whole buffer when
>> exporting to have everything updated.
>>
>> What is the problem here? For now I would have to
>> - evaluate only on export and keep :results silent
>> - evaluate all manually - meaning I get repeated results if I call
>> org-evaluate buffer
>
> :results replace is not implemented (yet?) for inline source blocks.

For me, that's the correct behavior, as inline code blocks are *only
expected to be evaluated during export*.

They are not intended to be executed in the buffer during normal use.
Hence, the above behavior (having the results inlined) is weird, and/or
buggy.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] patch to add new link type "infoi" that leverages Info-index command

[Nicolas Goaziou]

Richard Kim  writes:

> Thanks for your feedback.  I agree that using the same link type is better.
> Hence I took an alternate approach as detailed in the attached patch.
>  Enhanced org-info-follow-link to attempt index lookup if node lookup fails.
> Following is my check in message found in the attached patch:

Thanks. I think it is better, indeed.

Some minor comments follow.

> Subject: [PATCH] Enhanced org-info-follow-link to attempt index lookup if node
>  lookup fails.
>
> Info index is almost always finer grain than info nodes.  For example
> with this change, [[info:libc#close]] brings up not only
> "(libc)Opening and Closing Files" info node, but also place the cursor
> on the line that documents "close" function within the node.  This is
> done by looking up "close"in the index upon failing to find a node
> named "close".  Hence one can now link function, variable and other
> names that are in the index rather than being limited to info node
> names.  Typically there are far more index items than there are node
> names.  For example libc manual has about 700 nodes, but over
> 4000 concept, type, function, and variables index items.

You need to reformat a bit the commit message, according to Org mode
rules (see ).
E.g.,

--8<---cut here---start->8---
  [PATCH] org-info: info links may attempt index lookup

  * lisp/org-info.el (org-info-follow-link): Attempt index lookup if node
lookup fails.

  * doc/org.texi (External links): Update info links.

  Info index is almost always...

  TINYCHANGE
--8<---cut here---end--->8---

You may also want to update "orgguide.texi".

> + ;; If nodename-or-index is invalid node name, then look it
> + ;; up in the index.
> + (condition-case nil
> + (Info-find-node filename nodename-or-index)
> +   (user-error (Info-find-node filename "Top")
> +   (condition-case nil
> +   (Info-index nodename-or-index)
> + (user-error (message "Could not find '%s' node or index 
> entry." 
> +  nodename-or-index))

`message' is not needed. Also, error message shouldn't end on a full
stop:

  (user-error "Could not find '%s' node or index entry" nodename-or-index)
  
>  (message "Could not open: %s" name)))

Not directly related to your patch, but shouldn't it be

  (user-error "Could not open: %s" name)


Regards,

Re: [O] Org and ledger

[Daniel Clemente]

El Mon, 10 Nov 2014 08:08:51 +0100 Bernhard Pröll va escriure:
> 
> I have been curious too and found this file:
> 
> https://bitbucket.org/blais/beancount/src/tip/examples/tutorial/example.beancount

Exactly. The first line defines org mode:
;; -*- mode: org; mode: beancount; -*-

Re: [O] [bug?, ox-odt] Format DATE

[Christian Moe]

[Forgot to "reply all", so part of the below discussion happened
off-list. Sorry. Back on track now. CM]

Rasmus writes:

> Hi Christian,
>
> Thanks for the helpful email.  Note that you did not sent it to the
> ML, though.
>
> Christian Moe  writes:
>
>> Going by the documentation of org-odt-use-date-fields, the data styles
>> "OrgDate1" and "OrgDate2" are supposed to be mapped from
>> org-time-stamp-custom-formats, rather than
>> org-export-date-timestamp-format. 
>
> Yeah, I saw that, but the description of
> `org-time-stamp-custom-formats' looks a bit opaque.  I wondered if it
> would affect the recognition of timestamps in buffer (since the
> variable is not an org-export-· variable).  If it's truly *only*
> affecting exports it should be renamed.

No, judging by the manual entry, it was intended for customizing the
appearance of timestamps in the buffer, which it does, see below. To
accommodate people who think ISO time format is just too darned
/sensible/...

But it has the nice (and little-mentioned) side effect that you can use
it to change the appearance of timestamps in exports, where
non-geeky-looking everyday-language dates are often comme il faut. Works
nicely in HTML, for instance, except that you still get geeky-looking
brackets around the dates (may need a filter to remove those).

It's nice, for instance, if you have a document with a lot of dates in a
European format and need to switch to an American format; you can do it
by changing a setting.

And the ODT exporter builds on this to give date fields that can be
further changed in LibreOffice.

>> So this will apply to the output from the DATE keyword too.
>>
>> To make this happen, org-display-custom-times must be non-nil. 
>> This affects not only the date in the heading from the DATE keyword,
>> but also all other timestamps in the document.
>>
>> Having org-display-custom-times turned on all the time also puts
>> overlays on the timestamps in your buffer, but if this annoys you you
>> can bind it to be set during export only.
>
> OK.  I don't know this functionality.  It sounds less bad that what I
> feared, but still the org-export-· variables should probably be
> sufficient.
>
> Is `org-time-stamp-custom-formats' the recommend way of formatting
> regular time stamps for export?

I don't know about "recommended". It doesn't seem to be documented for
export at all. And as for ODT, the code comments say the feature
translating from custom time stamp formats to ODT date styles is
"experimental". Seems to work OK, though.

>> But doing it this way still ignores
>> org-export-date-timestamp-format, and any solution based on copying that
>> variable into org-time-stamp-custom-formats makes unsafe assumptions about
>> user preferences.
>
> Yes.
>
>> It seems to me that the export of the DATE keyword ought to honor a
>> non-nil org-export-date-timestamp-format, whether or not the user is
>> applying custom formatting to other timestamps. 
>> But that would take some
>> changes to several parts of ox-odt.el, I think.
>
> Yeah.  It's can be made even more complicated than that, since the
> *document language* of the output also affects how dates are
> formatted. . .

In Org, or in LibreOffice once you set the language there? If the
#+LANGUAGE keyword is supposed to affect date formatting in Org output,
I must be missing a trick.

> So a two step method would be: (0) make sure that the document
> language is set correctly (similar to how the right babel language is
> selected in LaTeX), and (1) be able to change the format of the date.
>
> Or we could lose the date-stamp-feature and insert the date as
> plaintext.  This is probably simpler, but I don't know if this is the
> "correct" way.

>> Rasmus, will you be pursuing this?
>
> If you are thinking about fixing this, I won't stop you!  I dread
> ·xml.  This weekend sort of disappeared in (other kinds of) wasted
> efforts, so I haven't progressed on this.

Not anytime soon, I'm afraid; pressed for time.

Yours,
Christian

Re: [O] Org and ledger

[Eric S Fraga]

Sharon,

a reference to another possibly useful tutorial was posted to the ledger
newsgroup a while ago:

From: Simon Michael 
Subject: Re: ledger basics and habits
Newsgroups: gmane.comp.finance.ledger.general
To: ledger-cli-/jypxa39uh5tlh3mboc...@public.gmane.org
Date: Sun, 22 Jun 2014 08:28:28 -0700 (20 weeks, 16 hours, 2 minutes ago)

Thanks!

The http://matthewturland.com/2014/03/29/ledger-basics-and-habits post
is the best short-medium intro I've seen yet.

Now featuring on https://twitter.com/LedgerTips .

I've not had a chance to read the post so cannot say how good it might
be but you may wish to follow this up.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.1, Org release_8.3beta-372-gdd70cf