Re: [O] clocking into an inline task before any headings

[Myles English]

Hi Carsten,

Carsten Dominik writes:

> On 14.8.2013, at 16:36, Myles English  wrote:
>
>> Are inline tasks allowed to be used before any other headings?  (I hope
>> they are.)
>
> No, they are not.
>
> Why don't you just make it a normal headline?

Okay, I can put the inline task under a normal headline with a
:noheading: tag that causes a filter to omit the headline itself, and
this is good enough for my needs:

* Like This   :noheading:

*** TODO Something inline
*** END

Just to explain what I am doing though: writing a report, e.g.:

* Introduction
* Method
* Conclusions

Adding tasks as headings breaks up the structure undesirably:

* TODO Decide on a layout for the whole document
* Introduction
* TODO Finish writing the introduction
* Method
* Conclusions

Alternatively, using inline tasks, the document structure is still easy
to see (scanning down the left side) and they fold nicely:

*** TODO Decide on a layout for the whole document...
* Introduction
*** TODO Finish writing the introduction...
* Method
* Conclusions

Labouring the point at bit, I see the headlines as the fingers on my
left hand and the inline tasks are the fingers on my right hand and they
interleave:

*** TODO Decide on a layout for the whole document...
* Introduction
*** TODO Finish writing the introduction...
* Method
** Setup
*** Safety
*** TODO Add fire exits...
 Insurance
*** TODO Ring broker...
* Conclusions

Changing the inline task before the Introduction to be under a headline
works but breaks up the document a little at the start:

* First task   :noheading:
*** TODO Decide on a layout for the whole document...
* Introduction
*** TODO Finish writing the introduction...
* Method
** Setup
*** Safety
*** TODO Add fire exits...
 Insurance
*** TODO Ring broker...
* Conclusions

(Another issue that may be related to this is that the preamble in a
complicated document for LaTeX export takes up a whole screen and it
would be nice to be able to fold it.)

Thanks,

Myles

[O] What is the URL of orgmode license evidence

[James Kang]

I know orgmode is under GPL but my search didn't turn up anything
clear from orgmode.Org.
I need this official information for an access. :-(

Thanks

Re: [O] What is the URL of orgmode license evidence

[Peter Neilson]

On Fri, 30 Aug 2013 09:35:13 -0400, James Kang  wrote:


I know orgmode is under GPL but my search didn't turn up anything
clear from orgmode.Org.
I need this official information for an access. :-(

Thanks


Do these help?

http://orgmode.org/manual/index.html#Top
http://orgmode.org/w/?p=org-mode.git;a=blob_plain;f=lisp/ob-plantuml.el;hb=HEAD

Re: [O] [AGENDA VIEW] Isn't g supposed to refresh agenda views ?

[Carsten Dominik]

On 15.8.2013, at 23:23, nore...@maillard.im wrote:

> Jonathan Leech-Pepin  writes:
> 
 Though it effectively does something, it does not really refresh
>> my
 agenda view since, as of the date of today (Wednesday 14th), it is
>> stuck
 to yesterday...
 
>>> 
>>> I've never tried leaving an agenda buffer open overnight and refresh
>> it
>>> in the morning: if I remember, I'll try it tonight and see what
>> happens
>>> (I could simulate the whole thing right now but no time).
>>> 
>> 
>> I have, it maintains the old date as current for the agenda view. I
>> dint see this as a problem however since the agenda can look at any
>> arbitrary date, not just "today". Changing the date to today by
>> hitting "." should update the agenda view appropriately.

Indeed.  It is on purpose that the agenda sticks to the same day, because you 
might be looking at a past date and you would not want to shift this one either 
at midnight. ".", or exiting the agenda with "x" and rebuilding it are the 
solutions.

- Carsten

> 
> Great ! I should have read C-h m more closely ;)
> 
> Thank you
> -- 
> XMA
> 
> 

Re: [O] Some orgtbl doc issues

[Carsten Dominik]

Hi Rustom, 

thanks for this.

On 16.8.2013, at 16:30, Rustom Mody  wrote:

> Ive recently been poking around in orgtbl mode and encountered some
> issues.  Not sure how much is my own lack of understanding and how
> much there are some little doc issues.
> 
> 1 Option names dont match
> =
> 
>  - Its orgtbl-radio-table-templates in emacs
>  - Its orgtbl-radio-tables in doc Appendix A.6.2

Fixed, thanks.

> 
> 
> 2 Receiving string
> ==
> 
>  - Seems to be "RECEIVE ORGTBL"

It is BEGIN RECEIVE ORGTBL followed by a table name.  As the example in the 
manual shows.  Does this have to be more explicit?

>  - String seems to be hardwired. Which may be ok if its by design.

Yes, hardwired by design.

>  - Not clear what is the relation of this string and
>orgtbl-radio-templates

The templates insert a BEGIN RECEIVE/END RECEIVE table template with
*proper commenting* around it in different programming modes.
I improved this in the docs.

>  - I find 1 space is fixed between RECEIVE and ORGTBL. Multiple
> allowed between ORGTBL and table-name

OK, I have removed this restriction.

>  - Its not clear from the doc whether its "RECEIVE ORGTBL" or
>  "/* RECEIVE ORGTBL"

That depends on the programming mode.  The documentation says that the lines 
must be comments in the current mode, I would think that this is clear enough.

>  - Subtle interaction between # in org and host mode comment char -- #
>in python, shell etc -- could do with some elaboration

Can you propose something for the documentation?

> 
> 
> 3 hook system
> =
> 
>  - What are the hooks for orgtbl?
>  - How do the org hooks relate to the orgtbl hooks?
>  - Note: orgtbl is for those who are not otherwise using orgmode

What to you mean?  Mode hooks, or hooks for specific functionality of the 
table?  If table commands run hooks, the corresponding trgtbl commands will do 
so as well, because they simply call the table functions in an environment 
where the proper keys bindings are not accessible.

orgtbl-mode is a standard minor mode and has `orgtbl-mode-hook', similar to all 
other minor modes.  See the documentation of define-minor-mode.  Do you feel 
the manual should say so?  It does not document many other hooks in org either, 
because there are too many.


> 
> 4 Long header line
> ==
> 
>  I could not figure out how to split a long
>  :#+ORGTBL: SEND...  line

It cannot be split.

Regards

- Carsten

> 
> Regards
> Rusi
> 

Re: [O] org-mode markup

[Carsten Dominik]

Hi Mehul,

Yes, you have hit an unfortunate case where the heuristic parser assumptions 
fail you.  It is cause by the comma as the last character.

Unfortunately, I do not have a good workaround.

- Carsten

On 22.8.2013, at 20:02, Mehul Sanghvi  wrote:

> 
> I have the following:
> 
>   
>  The =\,= allows you to put a Lisp expression there and the =#= is
> 
> What I end up with is that the everything between the 1st '=' and the last 
> '=' ends up becoming one marked-up section, rather than having two separate 
> mark-ups.
> 
> Is there something I'm missing or doing wrong ?  
> 
> 
> 
> -- 
> Mehul N. Sanghvi
> email: mehul.sang...@gmail.com

[O] angle brackets around timestamps in html export

[Matt Price]

Hello again,

I'm trying to get rid of angle brackets in HTML export.  I've set
org-export-date-timestamp-format to "%a, %b %d".  I also have
timestamp overlays turned on, and the displayed custom format set to
"<%a, %b %d>" (that seems unlikely to be relevant, but I've changed it
just in case).

Sorry I can't find the answer in the docs, I'm sure it's there
somewhere but I'm missing it somehow!

Matt

Re: [O] org-capture changes the buffer ring in a confusing way

[Carsten Dominik]

Hi Samuel,

Unfortunately, right now, I don't know a good way to avoid this.  Org switches 
to a special buffer while filling in the template, in order to allow 
interactive prompts, and I think this might be the cause of messing with the 
buffer list.

- Carsten

On 19.8.2013, at 05:44, Samuel Wales  wrote:

> When I use capture, the buffer ring ordering changes from what it was
> before the capture.  It even changes when I cancel the capture.  Is
> there a way to keep it exactly as it was in all cases?
> 
> What I expected was that previous-buffer would be the same before and
> after and that next-buffer would be the same before and after.  [In
> other words, that capture + capture finalizing would not change
> anything.  The philosophy of capture, to my understanding, is that
> capture is intended to allow you to take a note with minimum
> distraction.]
> 
> What I tried was org-capture.
> 
> What I noticed was that the buffer ring ordering had changed.
> 
> I have previous-buffer and next-buffer set to function keys, and I
> find them extremely useful.  But when the buffer ring ordering
> changes, I get confused.  So capture confuses me.
> 
> Also, it seems to always split the window.  Is there a way to fix that
> that is better than my current method of deleting other windows in the
> hook?  I always require a single window.
> 
> Thanks.
> 
> Samuel
> 
> -- 
> The Kafka Pandemic: http://thekafkapandemic.blogspot.com
> 
> The disease DOES progress.  MANY people have died from it.  ANYBODY can get 
> it.
> 
> Denmark: free Karina Hansen NOW.
> 

Re: [O] #+TAGS has some groups with many entries, suppress hotkey assignment

[Carsten Dominik]

On 17.8.2013, at 04:04, Jeff Kowalczyk  wrote:

> I am using a tagging strategy that required some mutually exclusive tag 
> groups
> to have large numbers of entries. In the example below facilty and customer 
> can
> be 30-50 entries to start, and grow slowly from there.
> 
> #+TAGS: { category: admin(a) development(d)
> #+TAGS: { facility: fac1 fac2 fac3 fac4}
> #+TAGS: { customer: cust1 cust2 cust3 }
> #+TAGS: { billing: billable(b) nonbillable(o) }
> 
> This works well in testing, but the hotkey selection UI automatically assigns 
> a
> character to all entries. After running out of alphanumerics, it moves on to
> punctuation and then to unicode characters.
> 
> Is there a way to selectively suppress automatic hotkey assignment? If
> supressing all automatic hotkey assignment is the only/better option, I would 
> be
> content to have no hotkeys unless explicitly set with the tag(x) syntax.
> 
> Thanks for any suggestions,

Please take a look at the variable org-use-fast-tag-selection and see if there 
is a setting that you find useful.

Cheers

- Carsten

> 
> Jeff
> 
> 
> 

Re: [O] [PATCH] Center currently clocked headline to top of screen

[Carsten Dominik]

Hi Daniel and Sebastien, 

On 22.8.2013, at 13:36, Daniel Clemente  wrote:

> 
> Seeing a bit of context is nice; maybe putting it at line 2 or 3 is better 
> than at the top and I think it is better than centered. It could also be 
> configurable.

Yup, I have made this a (recenter 2).  Non-configurable until arrival of more 
votes.

Cheers

- Carsten

> 
> 
> El Thu, 22 Aug 2013 10:36:00 +0200 Sebastien Vauban va escriure:
>> 
>> Hello,
>> 
>> When jumping to the currently clocked headline (via `C-c C-x C-j'), it seems
>> (to me) more logical to recenter that headline at the top of the screen (vs 
>> at
>> the center of the screen, that is the current behavior).
>> 
> 

Re: [O] What is the URL of orgmode license evidence

[Suvayu Ali]

On Fri, Aug 30, 2013 at 10:47:03AM -0400, Peter Neilson wrote:
> On Fri, 30 Aug 2013 09:35:13 -0400, James Kang  wrote:
> 
> >I know orgmode is under GPL but my search didn't turn up anything
> >clear from orgmode.Org.
> >I need this official information for an access. :-(
> >
> >Thanks
> 
> Do these help?
> 
> http://orgmode.org/manual/index.html#Top
> http://orgmode.org/w/?p=org-mode.git;a=blob_plain;f=lisp/ob-plantuml.el;hb=HEAD
> 

Look at COPYING in the top directory of the Org source tree.



-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] using gnuplot's "splot" and "every" commands on org-mode table data

[Paul Stansell]

Dear Eric,

Recently you made some nice changes to the way gnuplot plots surface
data from org tables.  Your changes are present on
git://orgmode.org/org-mode.git, but I switched to using ELPA recently
and I've just noticed that your changes are not yet present on
http://orgmode.org/elpa/.  Do you know if it's just because the latter
lags the former by 3 months or more?

As far as I can tell, I'm using the following versions:

  From git: org-version: 8.0.7 (release_8.0.7-406-g4b7490)
  From ELPA: Org-mode version 8.0.7 (8.0.7-7-g9e5104-elpa (org-20130826)

Kind regards,

Paul

On 17 May 2013 22:33, Paul Stansell  wrote:
> Hi Eric,
>
> That's seems perfect now; I can't see any other issues.  Thanks!
>
> Kind regards,
>
> Paul

Re: [O] Bug: heading visibility cycling and org-narrow-to-subtree

[Carsten Dominik]

Hi Ali,

hmmm, this is clearly a bug.  But one that is hard to fix.  I remember that it 
was problematic to extend the narrowing region to include the newline directly 
before the next heading.  I do not exactly remember why this caused problems, 
but it did.

I suggest to just live with it.

Thank you for the report none the less!

- Carsten

On 22.8.2013, at 22:30, Ali Tofigh  wrote:

> After narrowing to a subtree, folding the top level heading hides all
> text except for the last letter in the last paragraph. An example:
> 
> - 8< -
> * one
> ** two
>   hello world
> * three
> --
> 
> with cursor on heading "one", do M-x org-narrow-to-subtree (C-x n s),
> then press tab, and you get:
> 
> - 8< -
> * one...d
> --
> 
> with the "d" of "hello world" being visible.
> 
> emacs version: 24.3.1
> Org-mode version: 8.0.7 (8.0.7-6-g13cb28-elpa)
> OS: Mac OSX
> emacs was started with the -Q flag
> 
> /ali
> 

Re: [O] using gnuplot's "splot" and "every" commands on org-mode table data

[Achim Gratz]

Paul Stansell writes:
> I've just noticed that your changes are not yet present on
> http://orgmode.org/elpa/.  Do you know if it's just because the latter
> lags the former by 3 months or more?

ELPA doesn't lag anything like three months.  However, it is tracking
maint, not master.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [O] Bug: heading visibility cycling and org-narrow-to-subtree

[Samuel Wales]

Hmm, I have found and reported several bugs of this nature also.  For
example, sorting in a narrowed region usually corrupted the buffer by
joining lines.  This bug went unnoticed for possibly years becuase it
was tricky to correlate the sorting operation with the buffer
corruption [because diff is often unreadable in such cases].

Here's my take:

I don't know if it is relevant in this case, but I found that the
cause of most of these bugs is Outline mode, not Org or Emacs.
Outline does not include the final newline.

In most of Emacs, you typically mark bol, then move down a few lines,
then perform the operation.  This marks lines including their
newlines.

But in Outline, you have to guard against the special case of the
narrowed region not doing this.  That is, all code that uses outline
subtree marking has to code defensively and work around what amounts
to a special case.

A lot of code in Emacs subtly assumes a newline at the end of a
narrowed region, and does not consider this special case.

A philosopher would say that it's a matter of whether newlines are
line separators or line terminators, but much of line-operating and
region-operating functionality in Emacs has made the pragmatic
decision that they are line terminators.  While I acknowledge the
other point of view, and I am aware of the potential religious war
that might ensue, I agree with that decision and don't think it's best
to try to change all of Emacs to accommodate Outline mode's view in
this case.[1]

In summary, while this decision is up to Org developers, IMO Outline's
peculiar way of marking a subtree will continue to cause subtle bugs
and require defensive coding and workarounds until, somehow, a subtree
in Org is defined to include the final newline, at least everywhere
except eob.

Dunno if that helps or is relevant, but I hope it provides a little
context, even if tangential.

Samuel

[1]  The first line does not include the newline before it.  The last
line does include its own newline.  Thus, lines at buffer boundaries
do not have to be treated specially.  If you don't use a final newline
in the file, such bugs become apparent quickly and can be fixed with
require-final-newline.

Furthermore, point and mark are both at bol in all cases when you are
performing such operations.

As a user, I find it disconcerting to do end-of-buffer and have point
not be at bol.

Finally, applications like cron often require final newlines.  Did you
know that if you don't do that, and run certain crons, the final line
will be silently skipped?  Surprise :).

===

On 8/30/13, Carsten Dominik  wrote:
> Hi Ali,
>
> hmmm, this is clearly a bug.  But one that is hard to fix.  I remember that
> it was problematic to extend the narrowing region to include the newline
> directly before the next heading.  I do not exactly remember why this caused
> problems, but it did.
>
> I suggest to just live with it.
>
> Thank you for the report none the less!
>
> - Carsten
>
> On 22.8.2013, at 22:30, Ali Tofigh  wrote:
>
>> After narrowing to a subtree, folding the top level heading hides all
>> text except for the last letter in the last paragraph. An example:
>>
>> - 8< -
>> * one
>> ** two
>>   hello world
>> * three
>> --
>>
>> with cursor on heading "one", do M-x org-narrow-to-subtree (C-x n s),
>> then press tab, and you get:
>>
>> - 8< -
>> * one...d
>> --
>>
>> with the "d" of "hello world" being visible.
>>
>> emacs version: 24.3.1
>> Org-mode version: 8.0.7 (8.0.7-6-g13cb28-elpa)
>> OS: Mac OSX
>> emacs was started with the -Q flag
>>
>> /ali
>>
>
>
>

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY can get it.

Denmark: free Karina Hansen NOW.

[O] #+CALL and remote execution

[Kel Chan]

Hi list,

I'm implementing an executable worksheet in org and wonder if I can call a 
source block with a :dir arguments.

It doesn't seem orgmode support this out of the box. I tried #+CALL: 
ping-network()[:results values replace :dir /posiadmin@10.161.25.37:] and 
noticed two problems: the :dir argument was ignored and only the first row of 
output was shown in #+RESULT block. 

any ideas for workarounds?

cheers,
kel

Re: [O] from Android to org's calendar in a painless way?

[Renato]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 28 Aug 2013 11:44:37 -0400
Charles Philip Chan  wrote:

> Renato  writes:
> 
> Hi Renato:
> 
> > and this might be exactly what I wanted:
> >
> > https://github.com/dengste/org-caldav
> >
> > I'll have a go at it when I have some time these next days
> 
> This won't solve your problem.
> 
> Charles
> 

Hi Charles, actually it seems to be the best solution for me. I've made
some test runs and it really runs smoothly - you just run
org-caldav-sync in emacs and your orgmode and google calendar are
synced. The phone's default calendar is himself synced to google. It's
actually so painless I'm surprised, and I'm kind of expecting some
pitfall... we'll see :)

Next step will be to install owncloud (which org-caldav also supports)
on my VPS and bypass google. 

I'll still use MobileOrg for consulting my more wiki-style org
files, but for pure agenda stuff, org-caldav is far smoother IMO.

Thanks anyways for your detailed replies! 

cheers,
renato
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (GNU/Linux)

iQEcBAEBAgAGBQJSIQi0AAoJEBz6xFdttjrfCCkIAKijZ0dWw3kvamThIKFsFnQ7
M0S4C1zoW5Qkq/Ch4z4lcsbWRNzZR5rWNOz6wLkvy1KLNxs5Z9yzsIc6JcVAqPWL
y0Y0HbGnQbi9Er61AHVobgrYbiviGA3LLVsh0Dieh4xgdiYIXtixog+ba3AsbBcV
T1lwY3p71DngvJ7tgmajwiFFM9aFi4ZuUr/3tzEzQXWv/hCuNpa5Z+S0Q7pGhTQC
lf4pWfZ9CvvjMbRlgE1OgUpkCOql7o7h6b7GSWxKaQjWqpiZbmc5w5MycY80Gms+
uBUv0fXFjXJ7wqxl/oE6zfREjhhq6K7XXUocPv0T8CG+tse31ldFNMKIRMQMAyU=
=BFxa
-END PGP SIGNATURE-

[O] getting started with publishing

[Kevin Buchs]

I tried to get going with publishing to html, starting from this guide:
http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html . I am
running emails 24.3 on Windows with the latest ELPA org mode. I am getting
a complaint when I try to publish:

org-refresh-category-properties: Invalid function:
org-with-silent-modifications

Here is my setup

(require 'org-publish)
(setq org-publish-project-alist
   '(
  ("RCS-Notes"
  :publishing-function org-html-publish-to-html
  :base-directory "I:/SHARED/KevinBuchs/org"
  :publishing-directory "I:/SHARED/KevinBuchs/html"
  :base-extension "org"
  :recursive t ; include subdirs
  :headline-levels 4  ; default for this project
  :preparation-function nil ; functions called prior to publishing
  :completion-function nil ; functions called after publishing
  :auto-preamble t)
  ("RCS-Static"
  :publishing-function org-publish-attachment
  :base-directory "I:/SHARED/KevinBuchs/org"
  :publishing-directory "I:/SHARED/KevinBuchs/html"
  :base-extension "css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|swf"
  :recursive t) ; include subdirs
  ("RCS"
  :components ("RCS-Notes" "RCS-Static")) ))

What might I be missing?

Thanks
Kevin Buchs

[O] Failure to Build

[Robert Love]

When I try to build Org 8.0.7 I get many, many of this warning, then I get the 
error

org.el:15592:4:Warning: attempt to open-code `anonymous lambda' with too many 
arguments
org.el:15592:4:Warning: attempt to open-code `anonymous lambda' with too many 
arguments
org.el:15592:4:Error: Variable binding depth exceeds max-specpdl-size

No org.elc is ever produced.

$> emacs --version
GNU Emacs 23.1.1

When I tried Googling this error I see something about Xemacs but nothing is 
really relevant.

I asume production code would build without errors.  Is there something with my 
emacs? 

Anybody else encounter this?

--
Bob Love

Re: [O] Escaping an underscore in LaTeX export

[John Hendy]

On Tue, Aug 27, 2013 at 6:14 PM, Nicolas Goaziou  wrote:
> Hello,
>
> John Hendy  writes:
>
>> LaTeX recommends \_ as an "escaped" underscore. In other words,
>> "really use the underscore, not a subscript." When I do this in
>> Org-mode and export via =C-e l p=, I don't get that behavior.
>>
>> Here's my options header:
>>
>> #+OPTIONS: *:t TeX:t LaTeX:t
>>
>> a\_b  -> a$\backslash$$_{\text{b}}$
>> a$\_$b  ->  a\$\_\$b
>> a $\_$ b  ->  a $\_$ b
>>
>> What *does* work, is this:
>>
>> a\(\_\)b  ->  a\_b
>
> You can use the entity : \under{}, e.g.
>
>   a\under{}b
>
> or limit subscript to _{...} constructs., e.g.,
>
>   #+options: ^:{}
>   a_b

I'll look into this. I probably should have sooner, and it wouldn't
bother me *that* much to have to specify underscore and superscript
LaTeX entities with {} vs. having them picked up automatically.

Thanks for the tip!
John

>
>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] faster agenda with properties support disabled (no org-refresh-properties)

[Carsten Dominik]

Hi Daniel,

I have implemented a different version of the patch.  Please take a look at the 
new variable
org-agenda-ignore-drawer-properties.

Regards, and thanks!

- Carsten

On 23.8.2013, at 11:24, Daniel Clemente  wrote:

>>> So I would like to ask: is there a clean way to disable calls to
>>> org-refresh-properties?
>> 
>> No, that would require a patch and a config variable.
>> 
>> - Carsten
>> 
> 
>  I send a patch to do this. Setting this new variable to t reduced 10
> seconds my agenda export time (down from 1 minute 6 seconds) as well
> as the update.
>  You may add a comment about what to expect if your agenda depends on
> property data.
> 
> 
> diff --git a/lisp/org.el b/lisp/org.el
> index 572b797..167e7a8 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -17656,6 +17656,14 @@ is not set, the tables are not re-aligned, etc."
>   :version "24.3"
>   :group 'org-agenda)
> 
> +(defcustom org-agenda-ignore-properties nil
> +  "Avoid updating text properties when building the agenda.
> +Properties are used for effort estimation, appointments, categories.
> +If you don't use these in the agenda, set it to t and it will be faster."
> +  :type 'boolean
> +  :version "24.3"
> +  :group 'org-agenda)
> +
> (defun org-duration-string-to-minutes (s &optional output-to-string)
>   "Convert a duration string S to minutes.
> 
> @@ -18017,9 +18025,11 @@ When a buffer is unmodified, it is just
> killed.  When modified, it is saved
>   ;; this is only run for setting agenda tags from setup
>   ;; file
>   (org-set-regexps-and-options)))
> - (org-refresh-category-properties)
> - (org-refresh-properties org-effort-property 'org-effort)
> - (org-refresh-properties "APPT_WARNTIME" 'org-appt-warntime)
> + (unless org-agenda-ignore-properties
> +   (org-refresh-category-properties)
> +   (org-refresh-properties org-effort-property 'org-effort)
> +   (org-refresh-properties "APPT_WARNTIME" 'org-appt-warntime)
> + )
>   (setq org-todo-keywords-for-agenda
> (append org-todo-keywords-for-agenda org-todo-keywords-1))
>   (setq org-done-keywords-for-agenda
> 

Re: [O] Some orgtbl doc issues

[Rustom Mody]

Running just now... will answer in detail later
Just want to say for now that this was prompted by a discussion on python
list in which a half-dozen people expressed a wish for something like this.
Nobody seemed to know/mention org and since I could not work out all the
details, Ive not so far answered


On Fri, Aug 30, 2013 at 10:16 PM, Carsten Dominik  wrote:

> Hi Rustom,
>
> thanks for this.
>
> On 16.8.2013, at 16:30, Rustom Mody  wrote:
>
> > Ive recently been poking around in orgtbl mode and encountered some
> > issues.  Not sure how much is my own lack of understanding and how
> > much there are some little doc issues.
> >
> > 1 Option names dont match
> > =
> >
> >  - Its orgtbl-radio-table-templates in emacs
> >  - Its orgtbl-radio-tables in doc Appendix A.6.2
>
> Fixed, thanks.
>
> >
> >
> > 2 Receiving string
> > ==
> >
> >  - Seems to be "RECEIVE ORGTBL"
>
> It is BEGIN RECEIVE ORGTBL followed by a table name.  As the example in
> the manual shows.  Does this have to be more explicit?
>
> >  - String seems to be hardwired. Which may be ok if its by design.
>
> Yes, hardwired by design.
>
> >  - Not clear what is the relation of this string and
> >orgtbl-radio-templates
>
> The templates insert a BEGIN RECEIVE/END RECEIVE table template with
> *proper commenting* around it in different programming modes.
> I improved this in the docs.
>
> >  - I find 1 space is fixed between RECEIVE and ORGTBL. Multiple
> > allowed between ORGTBL and table-name
>
> OK, I have removed this restriction.
>
> >  - Its not clear from the doc whether its "RECEIVE ORGTBL" or
> >  "/* RECEIVE ORGTBL"
>
> That depends on the programming mode.  The documentation says that the
> lines must be comments in the current mode, I would think that this is
> clear enough.
>
> >  - Subtle interaction between # in org and host mode comment char -- #
> >in python, shell etc -- could do with some elaboration
>
> Can you propose something for the documentation?
>
> >
> >
> > 3 hook system
> > =
> >
> >  - What are the hooks for orgtbl?
> >  - How do the org hooks relate to the orgtbl hooks?
> >  - Note: orgtbl is for those who are not otherwise using orgmode
>
> What to you mean?  Mode hooks, or hooks for specific functionality of the
> table?  If table commands run hooks, the corresponding trgtbl commands will
> do so as well, because they simply call the table functions in an
> environment where the proper keys bindings are not accessible.
>
> orgtbl-mode is a standard minor mode and has `orgtbl-mode-hook', similar
> to all other minor modes.  See the documentation of define-minor-mode.  Do
> you feel the manual should say so?  It does not document many other hooks
> in org either, because there are too many.
>
>
> >
> > 4 Long header line
> > ==
> >
> >  I could not figure out how to split a long
> >  :#+ORGTBL: SEND...  line
>
> It cannot be split.
>
> Regards
>
> - Carsten
>
> >
> > Regards
> > Rusi
> >
>
>


-- 
http://www.the-magus.in
http://blog.languager.org

Re: [O] odt export version conflict on emacs for mac os x

[Carsten Dominik]

Hi,

can someone please summarize this discussion for me and tell me what action is 
required?

Thank you!

- Carsten

On 29.8.2013, at 20:25, Skip Collins  wrote:

> Jambunathan K  wrote:
>>> After I do an ODT export, many ox-odt variables are duplicated with
>>> old variable names:
>>>| [-]-\ Group Org Export ODT
>>>|  |  |--- Option Org Odt Schema Dir
>>>|  |  |--- Option Org Odt Content Template File
>> 
>> Above ones come from NEW exporter, ox-odt.el
>> 
>>>|  |  |--- Option Org Export Odt Schema Dir
>>>|  |  |--- Option Org Export Odt Content Template File
>> 
>> Above ones come from LEGACY exporter.  Not used by ox-odt.el.
>> 
>> This is confusing but the behaviour is expected and NOT BUGGY.
> 
> Thank you for clarifying a confusing situation. I am not sure why I
> assumed that the org-export-odt variables were the newer ones.
> 
> Suggestion for maintainers: a new, separate customization group, with
> appropriate pointers in the documentation, would be helpful.
> 

Re: [O] Invalid specification of styles.xml: nil

[Jambunathan K]

Luca Ferrari  writes:

> Hi all,
> when exporting to OpenOffice using a ott file as template I get the
> error "Invalid specification of styles.xml: nil", even if I placed the
> property
> #+ODT_STYLES_FILE: /home/luca/letter.ott
> in the org file. Regular exports to ODT works out of the box, of course!

> What am I missing?

The double quotes.  See the following section in the manual.

(info "(org) Applying custom styles")

>
> Thanks,
> Luca

Re: [O] don't show author and date on odt export?

[Jambunathan K]

Matt Price  writes:

> On Mon, Aug 26, 2013 at 2:49 PM, Matt Price  wrote:
>
>> I'm trying to figure out how best to tell org not to display my name
>> and the date at the top of the page when it exports document.
>> Currently, it seems I can do htis by setting
>>
>> #+OPTIONS: author:nil date:nil
>>
>> However, this also removes the relevant info from the file metadata.
>> I would prefer to somehow change the export template so that these
>> lines aren't produced.  Anyone know if that's possible? Would I have
>> to modify ox-odt.el directly -- and is that hard to do?  It looks like
>> the relevant lines in that file are around 1488-1541.  I'm a little
>> loathe to modify the code directly though, as I like to just git pull
>> from the master branch...
>
> I realize I also don't quite understand how to preformat the header
> and footer of each page.  I feel like this should be possible, as at
> least some footer info is generated by default (page number in centre
> of footer).  But despite some inspection of both ox-odt.el and the
> styles.xml and content.xml of my exported document, I can't figure out
> how the content of the footer is determined.

With a page style applied, click on the footer, insert a pagenumber
field and save the document.  The resulting changes will be stored in
the styles.xml under

Do you see text:page-number down below?

  

  


  


.
  

Use ODT_STYLES_FILE and the newly created ott file to pick up new
header/footer configuration.


> Thanks again!
> Matt

Re: [O] odt export version conflict on emacs for mac os x

[Jambunathan K]

Skip Collins  writes:

> I started digging into this when I noticed some odd behavior while
> using ODT export. I think I am stuck using the older, buggier ox-odt
> and my setup is mixing two versions of org.

Your settings seem OK to me.

> 1) an odt file is generated (good)

This is what matters!

> Explicitly setting org-export-backends, org-export-odt-schema-dir, and
> org-export-odt-styles-file in minimalinit.el has no effect. These
> variables seem to be superseded when ox-odt is invoked.

org-export-odt-*   => These are LEGACY settings. IGNORE THEM.
org-odt=> Settings used by NEW exporter, ox-odt.el

> I immediately browse the ODT customization options showing that all
> variables are prefixed with org-export-odt-. 

You will see that 

M-x customize-group RET org-export-odt RET

shows variables with both the prefixes `org-export-odt-*' and
`org-odt-*'.  It is the later one that you should use.

Seeing both the old and new custom variables is NORMAL and nothing to
worry about.  You will similar behaviour for other exporters - latex and
html - as well.  This mixing up of LEGACY and NEW variables will go away
with Emacses that have new ox-odt.el. 

If the new variables are not seen do

M-x load-library RET ox-odt RET

Also remember to add odt to 

   M-x customize-variable RET org-export-backends RET


> 2) These Emacs messages appear (bad):
> Debug (ox-odt): Searching for OpenDocument styles files...
> Debug (ox-odt): Trying /usr/share/emacs/etc/org/styles/... [2 times]
> Debug (ox-odt): Trying /usr/local/share/emacs/etc/styles/...
> Debug (ox-odt): Trying /usr/local/share/emacs/site-lisp/org/etc/styles/...
> Debug (ox-odt): Trying /Applications/Emacs.app/Contents/Resources/etc/org/...

The *BEST* way to pick the right styles file is to set the
`org-odt-data-dir' directly.

I have the following setting in my .emacs

(setq org-odt-data-dir "~/src/org-mode/etc/")

OrgOdtStyles.xml is under styles/ subdir of that dir.

Modify the above variable according to your setting.

> The newer org, which I intend to completely supplant the version that
> comes with Emacs, was installed with prefix /usr/local/share using the
> 'make up2' command.

make is what sets up `org-odt-data-dir' for you.  In your setting check
the value of `org-odt-data-dir' and make sure that the OrgOdtStyles.xml
file is available where the ODT exporter looks for it.

Ping Achim Gratz if you think make is not doing the right thing.

Btw, (I think) you will get the right behaviour if you do

make install

> Debug (ox-odt): Using styles under
> /Applications/Emacs.app/Contents/Resources/etc/org/

The above directory is `data-directory' of Vanilla Emacs.

> Debug (ox-odt): Searching for OpenDocument schema files...
> Debug (ox-odt): Trying /usr/share/emacs/etc/org/schema/... [2 times]
> Debug (ox-odt): No OpenDocument schema files installed

Absence of schema files is just a normal warning.  A user need not
bother about it.

Re: [O] Changing page style in odt export

[Jambunathan K]

Vikas Rawal  writes:

> I have a wide table in my org document which I want on a separate
> landscape page in between the document. In my style file, I have a
> page style "Landscape". Normally, in Libreoffice, I insert a page
> break with Landscape page style before the table, and another page
> break with "Default" page style after the table. How would one do it
> in org mode to get the same behaviour on exporting to odt?

Attached the wrong files.

LibreOffice takes some time to display the Table within a Text Box
within a Landscape page.  If you hover over the table a bit it becomes
visible.  This is the behaviour on LibreOffice 4.0.

-
Pagebreaks created via #+PAGEBREAK are a mere expedience.  These
create extraneous "empty" paragraphs which take up "extra space".  A
typographer will chide you for resorting to such underhanded means to
create pagebreaks.

As an expedient, it has it's uses.  See `org-odt-special-block' for a
realistic example of how pagebreak can be to service.

#+ATTR_ODT: :style "Text_20_body_20_bold"
The right way to create pagebreaks is to create new styles -
custom or automatic - that set the "before/after" pagebreak
of an element (a paragraph, table etc).

For example, consider pagebreaks created as below.

Text in first page.

#+ATTR_ODT: :style "OrgPageBreakDefault"
#+PAGEBREAK:

This text goes in next page.

Now look at the page that is introduced with forced page
break.  You will realize that the first line of text in that
page is a bit displaced [fn:1] from other pages created by
LibreOffice.  A keen eye will definitely catch this
aberration.



Textboxes an be used for centering tables etc horizontally
and vertically within a page.

In the example below, a landscape and centered table is
created in the middle of what is essentially a portrait
document.

Leading text.

#+ATTR_ODT: :style "OrgPageBreakLandscape"
#+PAGEBREAK:

#+ATTR_ODT: :width 5 :style "OrgPageImage" :anchor "page"
#+BEGIN_TEXTBOX
| a  | b  |
| e  | f  |
#+END_TEXTBOX

#+ATTR_ODT: :style "OrgPageBreakDefault"
#+PAGEBREAK:

-

You can customize paragraphs - standalone one and those occurring
within lists - using `:style' and `:p-style' attributes.  Try out
the following example and see for yourself what you can achieve.

#+ATTR_ODT: :style "OrgBulletedList" :p-style "Text_20_body_20_bold"
1. N1
   1. N11
   2. N12
2. N2
   #+ATTR_ODT: :style "OrgNumberedList" :p-style "Preformatted_20_Text"
   * B21

   * B22
 - B221

   First paragraph.

   #+ATTR_ODT: :style "OrgBibliographyList" :p-style "Text_20_body"
   1. one
   2. two
   3. three

   #+ATTR_ODT: :style "Text_20_body_20_indent"
   Second paragraph.

 - B222
   * B23
3. N3

* Footnotes

[fn:1] Does anyone know how to clearout the extraneous "space" created
by the pagebreak?
--


> Vikas



parstyles-and-pagebreaks.odt
Description: application/vnd.oasis.opendocument.text

Re: [O] odt export version conflict on emacs for mac os x

[Jambunathan K]

Skip Collins  writes:

> After I do an ODT export, many ox-odt variables are duplicated with
> old variable names:
> | [-]-\ Group Org Export ODT
> |  |  |--- Option Org Odt Schema Dir
> |  |  |--- Option Org Odt Content Template File

Above ones come from NEW exporter, ox-odt.el

> |  |  |--- Option Org Export Odt Schema Dir
> |  |  |--- Option Org Export Odt Content Template File

Above ones come from LEGACY exporter.  Not used by ox-odt.el.

> I think this is a bug. Can someone confirm? 

Not a bug.  This is expected on Emacses that don't ship with ox-odt.el.
Currently none of the Emacses has ox-odt.el.  So everyone - even those
with the right installation - will see it.

This is confusing but the behaviour is expected and NOT BUGGY.

Talk to Org maintainers (may be Nicolas Goaziou) and request that *ALL*
the new exporters - latex, html, odt, blah - all use a new defgroup for
their variables.

> This is apparently caused by interference from an old version of
> org-mode that is bundled inside my OS X Emacs.app. How can I
> completely disable the old version?

It has nothing to do with "mixed" installation.  Seeing mixed variables
is normal and nothing to worry about.

[O] (error "Stack overflow in equal")

[Jambunathan K]

Export the below file to ODT.  You will see the following stacktrace.

Debugger entered--Lisp error: (error "Stack overflow in equal")
  gethash(((table (:type org :attr_odt (":style \"GriddedTable\"") :parent)) . 
0))
  org-export-table-cell-width((table-cell (:parent (table-row (:type standard 
 )
  org-odt-table-cell((table-cell ))
  org-export-data((table-cell ))

Just to remind you, the table is created on fly by manipulating the
tree.  Using an `eq' as predicate in `org-export-table-cell-width'
solves the problem.  I am not sure this would be the right fix though. 

The last I have seen/worked (which is long time back), there was no
caching.

ps: If you aren't seeing the above trace in org repo, just pull from my
repo.

Web URL: http://repo.or.cz/w/org-mode/org-kjn.git
Pull URL: http://repo.or.cz/r/org-mode/org-kjn.git

#+ATTR_ODT: :list-table t
- Row 1
  - 1.1
  - 1.2
  - 1.3
- Row 2
  - 2.1
  - 2.2
  - 2.3

#+ATTR_ODT: :list-table t
- Row 3
  - 3.1
  - 3.2
  - 3.3
- Row 4
  - 4.1
  - 4.2
  - 4.3

Re: [O] don't show author and date on odt export?

[Jambunathan K]

Matt Price  writes:

> Hi,
>
> I'm trying to figure out how best to tell org not to display my name
> and the date at the top of the page when it exports document.
> Currently, it seems I can do htis by setting
>
> #+OPTIONS: author:nil date:nil
>
> However, this also removes the relevant info from the file metadata.
> I would prefer to somehow change the export template so that these
> lines aren't produced.  Anyone know if that's possible? Would I have
> to modify ox-odt.el directly -- and is that hard to do?  It looks like
> the relevant lines in that file are around 1488-1541.  I'm a little
> loathe to modify the code directly though, as I like to just git pull
> from the master branch...

I have difficulty grasping what you are saying here.  You are talking
about meta.xml and content.xml.

You want title and author in ... and don't want title and author in 

Better still, on what counts is the current arrangement unsatisfactory.
i.e., what is your use-case?

> Thanks!
> Matt

Re: [O] Carriage return in macro

[Jambunathan K]

Tim  writes:

> At Mon, 26 Aug 2013 12:16:53 +0200,
> Nicolas Goaziou wrote:
>> > Is there any way to have carriage returns within the text of the
>> > macro ?
>> 
>> No, there isn't. Macros target small substitutions.
>> 
>> > I have already tried using the #+BEGIN_ODT...#+END_ODT construct, but that
>> > *really* messes with the format of the text within it.
>> 
>> What do you mean? I don't know odt exporter very well, but contents of
>> the block should be included as-is.
>> 
> If I put several lines into an #+BEGIN_ODT..#+END_ODT block, all whitespace 
> formating is lost.  A list like
>
> - List one
> - List two
> - List three 
>
> becomes
>
> - List one - List two - List three
>
> This is why I started puting the formatting on each line, and rather than 
> type all of the  with that i guess... still better than using a word processer ;-) 
>
> Thanks
> Tim

The attached document shows how you can attach custom styles to
standalone paragraphs and the paragraph within lists.  You can export
with and without ATTR_ODT lines and see whether it offers what you want.

The changes are available from my git repository at 

Web URL:  http://repo.or.cz/w/org-mode/org-kjn.git
Pull URL: http://repo.or.cz/r/org-mode/org-kjn.git

Note that the above URL is my own repository and not the official
Orgmode's.

I am CCing Nicolas.  Just in case...

> --


parstyles.odt
Description: application/vnd.oasis.opendocument.text
* COMMENT Simple paragraphs

Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing

#+ATTR_ODT: :style "Text_20_body_20_indent"
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing

#+ATTR_ODT: :style "Text_20_body_20_bold"
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing

* COMMENT Paragraphs in Simple list

1. L1N1
2. L1N4
3. L1N5

#+ATTR_ODT: :p-style "Text_20_body_20_bold"
1. L1N1
2. L1N4
3. L1N5

* Paragraphs in Complex list

#+ATTR_ODT: :style "OrgBulletedList" :p-style "Text_20_body_20_bold"
1. N1
   1. N11
   2. N12
2. N2
   #+ATTR_ODT: :style "OrgNumberedList" :p-style "Preformatted_20_Text"
   * B21

   * B22
 - B221

   First paragraph.

   #+ATTR_ODT: :style "OrgBibliographyList" :p-style "Text_20_body"
   1. one
   2. two
   3. three

   #+ATTR_ODT: :style "Text_20_body_20_indent"
   Second paragraph.

 - B222
   * B23
3. N3

Re: [O] Changing page style in odt export

[Jambunathan K]

Vikas Rawal  writes:

> I have a wide table in my org document which I want on a separate
> landscape page in between the document. In my style file, I have a
> page style "Landscape". Normally, in Libreoffice, I insert a page
> break with Landscape page style before the table, and another page
> break with "Default" page style after the table. How would one do it
> in org mode to get the same behaviour on exporting to odt?
>
> Vikas

The attached document should be self-explanatory.  Pull my changes from

Web URL: http://repo.or.cz/w/org-mode/org-kjn.git
Pull URL: http://repo.or.cz/r/org-mode/org-kjn.git

Note that the above URL is NOT orgmode.org URL.

---

* COMMENT Simple paragraphs

Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing

#+ATTR_ODT: :style "Text_20_body_20_indent"
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing

#+ATTR_ODT: :style "Text_20_body_20_bold"
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing Testing testing testing testing
Testing testing testing testing

* COMMENT Paragraphs in Simple list

1. L1N1
2. L1N4
3. L1N5

#+ATTR_ODT: :p-style "Text_20_body_20_bold"
1. L1N1
2. L1N4
3. L1N5

* Paragraphs in Complex list

#+ATTR_ODT: :style "OrgBulletedList" :p-style "Text_20_body_20_bold"
1. N1
   1. N11
   2. N12
2. N2
   #+ATTR_ODT: :style "OrgNumberedList" :p-style "Preformatted_20_Text"
   * B21

   * B22
 - B221

   First paragraph.

   #+ATTR_ODT: :style "OrgBibliographyList" :p-style "Text_20_body"
   1. one
   2. two
   3. three

   #+ATTR_ODT: :style "Text_20_body_20_indent"
   Second paragraph.

 - B222
   * B23
3. N3



---



parstyles.odt
Description: application/vnd.oasis.opendocument.text

Re: [O] How to set C-o back to open-line?

[Carsten Dominik]

Hi Christopher,

Would you like to prepare a patch to this effect?

- Carsten

On 17.5.2013, at 00:38, Christopher Allan Webber  wrote:

> I really hate org-open-line... I can see why people might want it, but
> it's messed up my workflow.  I'd like to set C-o back.
> 
> However, I have no idea what org-defkey is doing, but I expected this to
> work:
> 
>  (define-key org-mode-map (kbd "C-o") 'open-line)
> 
> it isn't working!
> 
> How to get the standard-ol-open-line behavior back?
> 

Re: [O] CDLaTeX (4.0) not working in Org mode (8.0.3)?

[Carsten Dominik]

On 20.5.2013, at 10:59, Omid  wrote:

> Thanks. I confirm that this in fact solves the problem.


This is also fixed in CDLaTeX 4.6 at 
http://staff.science.uva.nl/~dominik/Tools/cdlatex

- Carsten

> 
> 
> On Mon, May 20, 2013 at 3:57 AM, Longmin WANG  wrote:
> 
> 
> On Mon, May 20, 2013 at 11:14 AM, Omid  wrote:
> I see the following strange behavior from Org-CDLaTeX (OCDL).
> 
> Outside a * heading it works. Inside a * heading (or anything under that) it 
> does NOT work. What can be causing this?
> 
> Here is a minimal example:
> 
> # Org CDLaTeX (OCDL) works here (at least does not issue an error)
> \[
> x^2
> \]
> 
> * heading
> ** subheading
># Org CDLaTeX (OCDL) does NOT work here. Pressing ^ (caret) or _
># (underscore) causes the following error to appear in *Messages*
># buffer:
># 
># call-interactively: Symbol's value as variable is void:
># last-command-char
>\[
>x
>\]
># Same error here.
>\begin{align*}
>x
>\end{align*}
> 
> 
> last-command-char should be changed to last-command-event in cdlatex.el. 
> 
> -- 
> Longmin Wang (http://wanglm.droppages.com/)
> Nankai University, 94 Weijin Road, Tianjin 300071, P. R. China
> 

Re: [O] Switch org-agenda-get-* defuns to operate on date ranges

[Carsten Dominik]

Hi Jörg,

I think it would be feasible to write such a modification.

- Carsten

On 20.5.2013, at 15:36, Jonas Hörsch  wrote:

> hello everyone,
> 
> i've just started to use calfw to get a nice calendar-like display of my
> agenda. unfortunately i was slighly dismayed at the build-up speed
> easily exceeding a few seconds on my not so packed schedule. profiling
> into the code i found that the problem mainly is:
> 
> there exists only the possibility to retrieve agenda data for one day
> day, org-agenda.el's org-agenda-get-day-entries, rather than for a range
> of days. this makes it necessary to loop over --get-day-entries to collect
> all entries to show in the monthly calendar.
> 
> --get-day-entries for its part has to parse (basically regex-search
> through) the respective org agenda file completely on each invocation;
> effectively done by org-agenda-get-{todos,blocks,sexps,...}.
> 
> i imagine it is quite feasible to implement
> (defun org-agenda-get-entries (file beg end &rest args) ...)
> to sift through FILE but once and return an alist like
> ((date . (entry1 entry2 ..)) ..)
> containing all entries between dates BEG and END, inclusive.
> 
> neglecting the extra overhead for sorting entries into the alist, this
> promises to speed up typical weekly agenda collection by a factor of 7
> and calfw even by a factor of approx. 30, shouldn't it?
> 
> before i start a local branch to try myself on this refactoring work,
> i'd welcome a few comments, why i should be likely to fail or succeed!
> 
> cheers,
> jonas
> 
> 

Re: [O] Counter-intuitive behavior of org-insert-heading

[Carsten Dominik]

Hi Matt,

is this problem fixed now, or still present?

Thanks!

- Carsten

On 20.5.2013, at 18:07, Matt Lundin  wrote:

> The following commit introduced a bug in org-insert-heading.
> 
> commit 3449c6d001b8d261b104bc9dd42bf1290d74bc0b
> Author: Bastien Guerry 
> Date:   Thu Apr 11 00:35:31 2013 +0200
> 
> org.el (org-insert-heading): Convert the current line into a headline
> 
> * org.el (org-insert-heading-respect-content): Fix docstring.
> (org-insert-heading): When in a non-empty non-headline line,
> convert the current line into a headline.
> 
> Thanks to Bernt Hansen for reporting this issue
> 
> I have org-insert-heading-respect-content set to nil.
> 
> Previously, when hit M-Ret at the end of a line, a new headline was
> created on the next line. Pressing return at the end of the line
> containing the date would result in a new headline, as expected. E.g.,
> 
> * A heading
>  [2013-05-20 Mon 11:02]
> 
> ...would become
> 
> * A heading
>  [2013-05-20 Mon 11:02]
> * 
> 
> ... with the cursor placed after the new asterisk
> 
> And if the cursor was at the end of a folded headline, such as.
> 
> * A heading...
> 
> ...a new heading would be created as expected...
> 
> * A heading...
> *
> 
> With the commit above, however, the following happens when I hit the
> cursor at the end of the line:
> 
> * A heading
> * [2013-05-20 Mon 11:02]
> 
> And with a folded headline, the same thing happens. When the cursor is 
> placed after the invisible section and I hit M-Ret:
> 
> * A heading...
> 
> ...unfolds and becomes...
> 
> * A heading
> * [2013-05-20 Mon 11:02]
> 
> Best,
> Matt
> 
> 

Re: [O] faster agenda with properties support disabled (no org-refresh-properties)

[Bastien]

Hi all,

Carsten Dominik  writes:

> I have implemented a different version of the patch.  Please take a look at 
> the new variable
> org-agenda-ignore-drawer-properties.

Great -- could someone document this on this page?
http://orgmode.org/worg/agenda-optimization.html

Thanks!

-- 
 Bastien

Re: [O] [PATCH] org.el: Don't flyspell check within source code blocks

[Carsten Dominik]

On 25.5.2013, at 09:17, Trevor Murphy  wrote:

> 
> Hi, list.
> 
> I recently started using flyspell, but I wasn't pleased with the spell
> checking in my source code blocks.  After digging a bit for a
> solution, I found a post to the list with a nice solution[0].
> However, it seems no patch was ever submitted.  So, here goes.
> 
> If there's a deeper reason this part of the code was never changed,
> please enlighten me.  I didn't see any further mailing list
> discussion, so I assumed it was still fair game.

Hi Trevor,

I would be worried that this has noticeable impact in Emacs performance during 
normal typing.  Are you a fst typist?  Have you noticed anything in this 
direction?

Thanks!

- Carsten


> 
> Thanks,
> 
> Trevor
> 
> [0]: http://lists.gnu.org/archive/html/emacs-orgmode/2012-12/msg00764.html
> 

Re: [O] [Attached] PDF documention for new exporter

[Carsten Dominik]

Hi THorsten,

have you made this available on Worg?

Thanks!

- Carsten

On 18.6.2013, at 10:58, Thorsten Jolitz  wrote:

> 
> Hi List, 
> 
> I extracted the documentation parts of the core exporter libraries and
> converted them to pdf, so they might serve as an detailled reference for
> the new exporter, much more detailled than any tutorial could be (the pdf's
> are still impressive in size, some 50 and 80 pages). 
> 
> ,
> | DISCLAIMER:
> | 
> | I did not go out of my way to produce these docs accurately and
> | complete, I just used 'outorg' to export to LaTeX and then ran some
> | replace commands and keyboard-macros on the .tex files. Things might
> | have gone wrong in some places, the resulting documents might be
> | incomplete or otherwise defective. But they might still be useful, so I
> | offer them here. When in doubt always refer to `ox.el' and
> | `org-elements.el' as reference.
> `
> 
> 
> 
> -- 
> cheers,
> Thorsten
> 

Re: [O] [PATCH 1/2] org-notify: Don't use obsolete flet and macrolet

[Carsten Dominik]

Hi Peter,

Please remind me then.

Thank you!

- Carsten

On 20.6.2013, at 13:52, Peter Münster  wrote:

> On Thu, Jun 20 2013, Carsten Dominik wrote:
> 
>>> The easiest solution is to simply do nothing, until Org drops support
>>> for Emacs 24.2 and earlier. The 'cl' library will be shipped with Emacs
>>> for a long time.
>>> 
>>> BTW, which Emacs versions does Org support? Is this documented anywhere?
>> 
>> No, but loosely, we have tried to support the current major version (i.e. 
>> 24) and
>> the previous major version (i.e. 23)
> 
> All right. Please apply this patch only later, when emacs 25 is out.
> 
> -- 
>   Peter
> 
> 

Re: [O] Bug: Messaging when moving in the agenda [7.9.2 (7.9.2-GNU-Emacs-24-3 @ /usr/share/emacs/24.2.50/lisp/org/)]

[Carsten Dominik]

On 6.8.2013, at 13:32, Michael Heerdegen  wrote:

> Hello,
> 
>> When I move around in the *Org Agenda* with up and down, the current
>> outline path is displayed in the echo area, which is good.
>> 
>> However, what is displayed gets also copied in the *Messages* buffer,
>> which is not helpful, but clutters *Messages* with useless noise.
>> 
>> So, IMHO `org-display-outline-path' should still display its stuff in
>> the echo area, but prevent logging in *Messages*.  AFAIK, the way to do
>> this is to bind `message-log-max' to nil.
> 
> Can we please try to make some progress here?  I don't want to suggest a
> patch because I don't know the org code base well, but binding
> `message-log-max' to nil at one or two location should totally suffice.
> Who can help?

Mi Michael,

I believe I have done it in the right place now, please confirm.

Thanks

- Carsten

> 
> 
> Regards,
> 
> Michael.
> 
>