Re: [O] org-insert-heading rewritten from scratch

2013-09-01 Thread Nicolas Goaziou
Hello,

Carsten Dominik  writes:

> On 31.8.2013, at 16:34, Nicolas Goaziou  wrote:

>> Not really a bug, but I find some behaviour surprising: when at a the
>> beginning of a regular text line, there is no way to create a headline
>> just above it. In the following example:
>> 
>>  XCursor is at "X"
>> 
>> Neither M-RET, C-u M-RET, C-RET nor C-u C-RET can do it. Is it intended?
>
> Which behavior would you propose?  I guess you mean that, at the beginning of 
> a line,
> the result is so different for normal lines versus headlines?

Yes.

I never, ever, want to turn a regular text line into a headline. OTOH
during note taking, I very often write paragraphs and, afterwards,
decide to split them into sections.

Moreover, AFAICT, there's no more difference between C-u M-RET, which
meant "create headline right here" and M-RET.

> The way I was thinking about the behavior at the beginning of a non-headline
> is that it is the same as in the middle of a line:  Take the rest of the line
> and turn it into a headline.p
>
> To create a headline before a nonempty line, I use `C-o M-RET'

That's what I do. But that's not optimal and it introduces another
problem. In the following example

  * H

  XText

I want to create a headline above "Text" and point is at "X". I use C-o
M-RET and the latter greedily eat the blank line above, resulting in

  * H
  * X
  Text

as if I had typed C-p M-RET instead.

Again, I have `org-blank-before-new-entry' set to `auto' for headlines.
Since there is no information about how many blank lines I usually want
before headlines, I think the algorithm should trust me and do not
remove any blank lines (see `org-list-separating-blank-lines-number').

In the same vein, in the following situation

  * H1

Text1

  * H2

XText2

C-o M-RET should leave blank above "Text2" because it has information
about my preferences.

Oddly, in an empty buffer, it will create a blank line above.

>> Also in this case, I think C-RET should create the new headline _after_
>> the subtree, since that's its whole point anyway, AFAIU.
>
> That is what happens for me.  It does not for you?

It does, sorry about the noise.

> Hmm, I do find this behavior consistent. M-RET does not change the number
> of while lines after the current, only before, in order to either have
> an empty line or not.
>
> Which behavior would you propose?

Well same as above: I think it eats blank lines where it shouldn't. It
the following cases:

  * H1

  ** H2

 H
  X

and

  * H1

  * H2

H

  X  

I don't think there's any reason for M-RET to eat blank line before
point with either `org-blank-before-new-entry' set to `auto' or t. It
should know that a blank line is expected before the new entry and
therefore should create the headline at point.

>> I also suggest to write function specifications as tests in test-org.el.
>
> Yes, I have yet to write my first test.  Need to figure out how that
> works.

That's simple. You can use the following pattern:

  (ert-deftest test-org/insert-heading ()
"Test specifications for heading insertion."
;; In an empty buffer, headline should be created at its beginning,
;; notwithstanding value for `org-blank-before-new-entry'.
(should
 (equal "* "
(org-test-with-temp-text ""
  (let ((org-blank-before-new-entry '((heading . nil
(org-insert-heading))
  (buffer-string
(should
 (equal "* "
(org-test-with-temp-text ""
  (let ((org-blank-before-new-entry '((heading . t
(org-insert-heading))
  (buffer-string
(should
 (equal "* "
(org-test-with-temp-text ""
  (let ((org-blank-before-new-entry '((heading . auto
(org-insert-heading))
  (buffer-string
;; At the end of a single headline: Create headline below, following
;; `org-blank-before-new-entry' specifications.  When it is `auto',
;; since there's not enough information to deduce what is expected,
;; create it just below.
(should
 (equal "* H\n* "
(org-test-with-temp-text "* H"
  (end-of-line)
  (let ((org-blank-before-new-entry '((heading . nil
(org-insert-heading))
  (buffer-string
(should
 (equal "* H\n\n* "
(org-test-with-temp-text "* H"
  (end-of-line)
  (let ((org-blank-before-new-entry '((heading . t
(org-insert-heading))
  (buffer-string
(should
 (equal "* H\n* "
(org-test-with-temp-text "* H"
  (end-of-line)
  (let ((org-blank-before-new-entry '((heading . auto
(org-insert-heading))
  (buffer-string
;; Etc.
)

I suggest to always put the `should' (or `should-not', `should-error')
outside each test: it makes it easier to inspect results from partial
evaluations

Re: [O] Trouble with org-icalendar-combine-agenda-files

2013-09-01 Thread Nicolas Goaziou
Hello,

Bill Day  writes:

> Since August 17, I have not been able to create a combined icalendar file.
>
> I can create single file withe C-c C-e c f.
>
> I can create multiple files with C-c C-e c a.
>
> But when I try C-c C-e c c, the process starts to save temp files and
> quietly dies.
>
> Output in messages looks like this:
>
> Saving file /tmp/orgics5457fkf...
> Wrote /tmp/orgics5457fkf
> (New file)
> Saving file /tmp/orgics5457sul...
> Wrote /tmp/orgics5457sul
>
> When I enable the debugger in options it does not trip when the process
> dies.  There is an icalendar-errors buffer, but it is empty.
>
> I am using the following version of emacs on Debian Wheezy
>
>
> GNU Emacs 24.3.50.1 (x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
>  of 2013-08-22 on gkar, modified by Debian
>
> My org-mode version is as follows:
>
> Org-mode version 8.0.7 (release_8.0.7-415-g32bd54.dirty @
> /home/billday/elisp/org-mode/lisp/)
>
> Any help or advice would be much appreciated.

After a quick test, I'm unable to reproduce your problem (I'm not
a icalendar user, though).

What's your value for `org-icalendar-combined-agenda-file'?

Also, does this problem happen both synchronously and asynchronously?


Regards,

-- 
Nicolas Goaziou



Re: [O] org-insert-heading rewritten from scratch

2013-09-01 Thread Carsten Dominik
Hi Nioclas,

thank you for the feedback.

On 1.9.2013, at 10:19, Nicolas Goaziou  wrote:

> Hello,
> 
> Carsten Dominik  writes:
> 
>> On 31.8.2013, at 16:34, Nicolas Goaziou  wrote:
> 
>>> Not really a bug, but I find some behaviour surprising: when at a the
>>> beginning of a regular text line, there is no way to create a headline
>>> just above it. In the following example:
>>> 
>>> XCursor is at "X"
>>> 
>>> Neither M-RET, C-u M-RET, C-RET nor C-u C-RET can do it. Is it intended?
>> 
>> Which behavior would you propose?  I guess you mean that, at the beginning 
>> of a line,
>> the result is so different for normal lines versus headlines?
> 
> Yes.
> 
> I never, ever, want to turn a regular text line into a headline. OTOH
> during note taking, I very often write paragraphs and, afterwards,
> decide to split them into sections.

OK, I'll go along with this.  `C-c *' if for turning a line into a headline,
M-RET for making a *new* headline.  That is logical.  Fixed now.

> 
> Moreover, AFAICT, there's no more difference between C-u M-RET, which
> meant "create headline right here" and M-RET.

C-u means: Do not ask org-insert-item, just go ahead and insert a heading.
That is supposed to be the only difference.

> 
>> The way I was thinking about the behavior at the beginning of a non-headline
>> is that it is the same as in the middle of a line:  Take the rest of the line
>> and turn it into a headline.p
>> 
>> To create a headline before a nonempty line, I use `C-o M-RET'
> 
> That's what I do. But that's not optimal and it introduces another
> problem. In the following example
> 
>  * H
> 
>  XText
> 
> I want to create a headline above "Text" and point is at "X". I use C-o
> M-RET and the latter greedily eat the blank line above, resulting in
> 
>  * H
>  * X
>  Text
> 
> as if I had typed C-p M-RET instead.
> 
> Again, I have `org-blank-before-new-entry' set to `auto' for headlines.
> Since there is no information about how many blank lines I usually want
> before headlines, I think the algorithm should trust me and do not
> remove any blank lines (see `org-list-separating-blank-lines-number').

I believe this is now better, please check.

> 
> In the same vein, in the following situation
> 
>  * H1
> 
>Text1
> 
>  * H2
> 
>XText2
> 
> C-o M-RET should leave blank above "Text2" because it has information
> about my preferences.

I think this is fixed as well.

> 
> Oddly, in an empty buffer, it will create a blank line above.

Fixed.

> 
>>> Also in this case, I think C-RET should create the new headline _after_
>>> the subtree, since that's its whole point anyway, AFAIU.
>> 
>> That is what happens for me.  It does not for you?
> 
> It does, sorry about the noise.
> 
>> Hmm, I do find this behavior consistent. M-RET does not change the number
>> of while lines after the current, only before, in order to either have
>> an empty line or not.
>> 
>> Which behavior would you propose?
> 
> Well same as above: I think it eats blank lines where it shouldn't. It
> the following cases:
> 
>  * H1
> 
>  ** H2
> 
> H
>  X
> 
> and
> 
>  * H1
> 
>  * H2
> 
>H
> 
>  X  
> 
> I don't think there's any reason for M-RET to eat blank line before
> point with either `org-blank-before-new-entry' set to `auto' or t. It
> should know that a blank line is expected before the new entry and
> therefore should create the headline at point.

Please take another look.

Thank you!

- Carsten

> 
>>> I also suggest to write function specifications as tests in test-org.el.
>> 
>> Yes, I have yet to write my first test.  Need to figure out how that
>> works.
> 
> That's simple. You can use the following pattern:
> 
>  (ert-deftest test-org/insert-heading ()
>"Test specifications for heading insertion."
>;; In an empty buffer, headline should be created at its beginning,
>;; notwithstanding value for `org-blank-before-new-entry'.
>(should
> (equal "* "
>(org-test-with-temp-text ""
>  (let ((org-blank-before-new-entry '((heading . nil
>(org-insert-heading))
>  (buffer-string
>(should
> (equal "* "
>(org-test-with-temp-text ""
>  (let ((org-blank-before-new-entry '((heading . t
>(org-insert-heading))
>  (buffer-string
>(should
> (equal "* "
>(org-test-with-temp-text ""
>  (let ((org-blank-before-new-entry '((heading . auto
>(org-insert-heading))
>  (buffer-string
>;; At the end of a single headline: Create headline below, following
>;; `org-blank-before-new-entry' specifications.  When it is `auto',
>;; since there's not enough information to deduce what is expected,
>;; create it just below.
>(should
> (equal "* H\n* "
>(org-test-with-temp-text "* H"
>  (end-of-line)
>  (let ((org-blank-before-new-entry '((heading . nil
>(org-i

Re: [O] org-insert-heading rewritten from scratch

2013-09-01 Thread Nicolas Goaziou
Carsten Dominik  writes:

> Please take another look.

There is no new commit in maint or master.


Regards,

-- 
Nicolas Goaziou



Re: [O] [patch][org-entities] More symbols

2013-09-01 Thread Nicolas Goaziou
Hello,

Rasmus  writes:

> Subject: [PATCH] More org-entities.

Stylistic note for future patches: there should be no period at the end
of the title.

> * org-entities.el (org-entities): Add support for ell, imath, jmath,
> varphi, varpi, aleph, gimel, beth, dalet, cdots, S (§), dag, ddag,
> colon, therefore, because, triangleq, leq, geq, lessgtr, lesseqgtr,
> ll, lll, gg, ggg, prec, preceq, preccurleyeq, succ, succeq,
> succurleyeq, setminus, nexist(s), mho, check, frown, diamond.  Changes loz,
> vert, checkmark, smile and tilde.

Applied. Thank you.


Regards,

-- 
Nicolas Goaziou



Re: [O] [patch] Remove dependency on latexsym

2013-09-01 Thread Nicolas Goaziou
Hello,

Rasmus  writes:

> It's easy to remove the decency of latexsym as it only defines a very
> limited number of symbols (see texdoc latexsym).  Using amssymb
> symbols will even look better IMO, but check this document:

[...]


> Obviously, it requires the removal of Diamond (my entity patch) and
> Box (this patch)

Applied. Thank you.


Regards,

-- 
Nicolas Goaziou



[O] [0] Beamer export - scaling images

2013-09-01 Thread JBash
Hi,

I am having trouble getting images to scale using the #+ATTR_LaTeX: line
for an export.  I've tried in a full beamer frame, as below, as well as in
a column in a frame.  Then I put it in a non-beamer latex to pdf export and
had the same problem.  Can someone point out what I'm missing?

*** Frame Title
#+CAPTION:The Figure Caption
#+LABEL:  fig:figure1
#+ATTR_LaTeX: width=0.2\textwidth
file:./images/image7a.jpg

orgmode 8.0.7; emacs 24.3.1 on linux

Thanks,
Jerry


Re: [O] [0] Beamer export - scaling images

2013-09-01 Thread Suvayu Ali
On Sun, Sep 01, 2013 at 10:19:32AM -0400, JBash wrote:
> 
> #+ATTR_LaTeX: width=0.2\textwidth
> file:./images/image7a.jpg

Your syntax is wrong.  The new exporter uses property lists.



-- 
Suvayu

Open source is the future. It sets us free.



Re: [O] [0] Beamer export - scaling images

2013-09-01 Thread JBash
Thank you, Suvayu


On Sun, Sep 1, 2013 at 10:24 AM, Suvayu Ali wrote:

> On Sun, Sep 01, 2013 at 10:19:32AM -0400, JBash wrote:
> >
> > #+ATTR_LaTeX: width=0.2\textwidth
> > file:./images/image7a.jpg
>
> Your syntax is wrong.  The new exporter uses property lists.
>
> <
> http://orgmode.org/manual/LaTeX-specific-attributes.html#LaTeX-specific-attributes
> >
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
>
>


[O] export question

2013-09-01 Thread Manfred Lotz
Hi all,
I have an org file which looks like this:

* My list
** item1
   - p1 :: something
   - p2 :: 23232
   ...
   - p14 :: bla
** item2
   - p1 :: another valu 
   - p2 :: 21
   ...
   - p14 :: more bla
...
** itemn
   - p1 :: hm
   - p2 :: 3842
   ...
   - p14 :: more more bla


... in the p list means there are also p3 till p13
... in the item list indicates there are n items actually.


Now I want to export the file to an ascii buffer/file where show the
content as a table. I want to omit certain p lines.

So I would like to have something like this where I would like to
show only certain columns.



 val p1 p14   
--
 item 1  something  bla   
 item n  hm more more bla 



How do I achieve this? I see basically two possibilities like follows:

1. write my own special exporter 

2. write an external program which does it


I guess 1. makes much sense. In this case I like to know if there is a
tutorial showing how to do my own exporter or where to find specific
documentation how to do this?

Perhaps there is something very simple I do not even think of?

Any hints appreciated.



-- 
Thanks a lot in advance,
Manfred






[O] export tex file to different directory

2013-09-01 Thread Johannes Rainer
Hi all,

is there a way that I could export the generated tex files to a different
directory upon export?

thanks, jo


Re: [O] export tex file to different directory

2013-09-01 Thread Suvayu Ali
On Sun, Sep 01, 2013 at 07:58:42PM +0200, Johannes Rainer wrote:
> Hi all,
> 
> is there a way that I could export the generated tex files to a different
> directory upon export?

If you are using subtree export, you can set the EXPORT_FILE_NAME
property to dir/file.pdf.  If you are exporting the whole file, take a
look at the publishing facility in the manual.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.



Re: [O] export question

2013-09-01 Thread Suvayu Ali
On Sun, Sep 01, 2013 at 06:49:01PM +0200, Manfred Lotz wrote:
> 
> Now I want to export the file to an ascii buffer/file where show the
> content as a table. I want to omit certain p lines.
> 
> So I would like to have something like this where I would like to
> show only certain columns.
> 
> 
> 
>  val p1 p14   
> --
>  item 1  something  bla   
>  item n  hm more more bla 

 [...chomp...chomp...chomp...]

> I guess 1. makes much sense. In this case I like to know if there is a
> tutorial showing how to do my own exporter or where to find specific
> documentation how to do this?

ox-odt.el has a feature like this, list to tables.  You can take a look
there for hints.

-- 
Suvayu

Open source is the future. It sets us free.



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

2013-09-01 Thread Julien Cubizolles
Charles Philip Chan  writes:


> Yes, you can, it just won't show up until you sync, pull, refile and
> sync.

Do you mean that you need to get back to your emacs computer in order to
have an entry captured on the phone actually appear on the phone ?
I noticed that if you untick and tick the "Delete on assimilation"
option, all entries captured in MobileOrg are immediately added to the
android calendar.

I'm also not sure about the Assimilate calendar entries and its "Delete
on assimilation" option. Does it prevent the entry appearing twice in
the calendar : once for the entry added outside MobileOrg and once when
MobileOrg adds it to the calendar after having added it to the org
files ?

If 
* I configure MobileOrg to "Synchronize with calendar", "Assimilate
  Calendar entries" and "Delete on assimilation"

* Add an event on the Android Calendar

* Synchronize from Mobile Org

Should I have the entry appear in both the Android Calendar and the
Capture node of MobileOrg ? And will it remain in the Android Calendar
after I've run org-mobile-pull and refiled it ? 

Julien.




[O] fold paragraphs, export only contents of a node, hiding the 'node heading text'

2013-09-01 Thread . .
Hello:

Is there a way to export to Latex the text under a heading but 
not-exporting/printing to the .tex file the heading/TODO (node line) itself?

The idea is to be able to fold paragraphs (via node creation for the paragraphs 
under it).
But if I set the node to noexport (to hide the unnecessary heading/TODO text 
which was only there to allow folding the text under it) then the paragraph 
can't be exported either!

This would be great to permit folding with great granularity and use the 
heading to describe the paragraph without showing it (like a comment only it 
folds!).


Thanks,
Best regards,
Mark


[O] Adding a side bar of TOC to exported pages

2013-09-01 Thread Pushpendre Rastogi
Hi,

I am trying to publish some of the org file which I have written 
(mostly they are like personal tutorials.) 
I have set up org-publish to publish the files for example at 
http://cs.jhu.edu/~prastog3/active_learn_info.html.

However, I really want to add a TOC to every page that I generate, 
just because it makes it jump across and navigate. 
Is this something that is supported out of the box? 
I noticed that the worg site uses it. 
Is there an undocumented options that might enable it? 

just to clarify i want a sitemap like 
http://cs.jhu.edu/~prastog3/active_learn_info.html 
to be embedded into an expandable table in every page.

Thanks
Pushpendre





Re: [O] fold paragraphs, export only contents of a node, hiding the 'node heading text'

2013-09-01 Thread John Hendy
On Sun, Sep 1, 2013 at 4:17 PM, . .  wrote:
> Hello:
>
> Is there a way to export to Latex the text under a heading but 
> not-exporting/printing to the .tex file the heading/TODO (node line) itself?
>
> The idea is to be able to fold paragraphs (via node creation for the 
> paragraphs under it).
> But if I set the node to noexport (to hide the unnecessary heading/TODO text 
> which was only there to allow folding the text under it) then the paragraph 
> can't be exported either!
>
> This would be great to permit folding with great granularity and use the 
> heading to describe the paragraph without showing it (like a comment only it 
> folds!).
>

I never did dig into this as it still was a bit above my head, but it
seems like this could do what you want:
- https://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01329.html

In other words, you'd define a custom function like this:

(defun mapcdi-org-latex-headline-function (todo todo-type priority text tags)
  "The docstring of my function."
  (concat
   (and todo (format "{\\bfseries\\sffamily %s} " todo))
   (and priority (format "\\framebox{\\#%c} " priority))
   text
   (and tags
(format "\\hfill{}\\textsc{%s}" (mapconcat 'identity tags ":")


I think you'd just omit that "text" bit, and probably remove the other stuff to.

ETA: I just went ahead and gave it a whirl. It looks like this, or
something close, should let you do whatever you want with headlines
(go ahead and use priorities, tags, todo keywords, and the like and
still just get a blank headline:

(defun mapcdi-org-latex-headline-function (todo todo-type priority text tags)
  "The docstring of my function."
  (concat
   (and todo (format "{}" todo))
   (and priority (format "{} " ))

   (and tags
(format "\\hfill{}\\textit{}" (mapconcat 'identity tags ":")

There most likely is a blank line where the headline *would* go. I
played around with trying to \vspace a negative line space like so,
and I think it's doing the right thing, or is at least close (there's
less space between the contents line and the paragraph text):

(defun mapcdi-org-latex-headline-function (todo todo-type priority text tags)
  "The docstring of my function."
  (concat
   (and todo (format "{}" todo))
   (and priority (format "{} " ))
   (and text (format "{\\vspace{-\\baselineskip}}" ))
   (and tags
(format "\\hfill{}\\textit{}" (mapconcat 'identity tags ":")

The only thing I noticed is that within a section, paragraphs by
default have no space and are indented (well, the first isn't, but
following paragraphs are). With this method, paragraphs within
sections are going to have the typical post-section spacing compared
to being treated like truly consecutive paragraphs. If you're okay
with that, then this will work. If not, you'll have to make a custom
latex template somehow so that the whole document is treated like one
long section. I'm not sure if that's possible given org's headline ->
section internals. You might be able to fiddle with something like the
above \vspace{} trick, though? You'd also have to have every paragraph
indented so that they weren't treated like the first paragraph in a
section (un-indented).

Anyway, hopefully this gets you on the right path!

#+begin_src test-file

#+bind: org-latex-format-headline-function mapcdi-org-latex-headline-function
#+options: num:nil

* todo headline 1   :test:

blah blah blah.

* headline 2

blah blah blah

* headline 3

A couple of separate paragraphs to see how far apart two paragraphs would be
normally. We'll add enough to line break just to make it interesting.

A couple of separate paragraphs to see how far apart two paragraphs would be
normally. We'll add enough to line break just to make it interesting.

#+end_src



Best regards,
John



>
> Thanks,
> Best regards,
> Mark



Re: [O] clocktable column order e.g. :properties at rightmost position?

2013-09-01 Thread Carsten Dominik
Hi Jeff,

there is not way to change the order of columns easily.  What you can do is 
copy the function `org-clocktable-write-default' and change the output in the 
way you like.  The time string for clock tables is currently not configurable.

Sorry.

- Carsten

On 1.9.2013, at 14:47, "frie...@michelfetzer.de"  
wrote:

On 31.8.2013, at 18:58, Jeff Kowalczyk  wrote:

> Is there a way to configure column order in clocktable output? I have a
> workable way to display TAGS now for clocked task now, but the width of
> multiply-tagged items will make the clocktable output less usable. I'd
> prefer to move it over to the right-most position:
> 
> : #+BEGIN: clocktable :maxlevel 2 :scope file :emphasize nil :block today 
> : :link nil :indent nil :properties ("TAGS")
> : #+CAPTION: Clock summary at [2013-08-31 Sat 09:25], 
> :for Saturday, August 31, 2013.
> : | TAGS  | Headline   | Time   |  |
> : |---+++--|
> : |   | *Total time*   | *1:05* |  |
> : |---+++--|
> : |   | <2013-08-31 Sat>   | 1:05   |  |
> : |   | TODO db query test || 0:18 |
> : |   | TODO time-tracking-tools   || 0:26 |
> : | :foo:bar: | DONE jsmith re: new idea   || 0:15 |
> : | :bar: | DONE article attack driven defense...  || 0:06 |
> : #+END:
> 
> The option:
> 
> : :formatter A function to format clock data and insert into the buffer.
> 
> sounds promising if it could advise the existing function without
> reimplementing large parts of it. I'm searching for :formatter
> documentation and examples, haven't found any direct references yet.
> 
> Secondary question: with the today and yesterday tracking clocktables
> I'm using, can I configure formatting of the string:
> "for Saturday, August 31, 2013." as a normal org timestamp:
> "for [2013-08-31 Sat]."?
> 
> Thanks,
> Jeff
> 
> 
> 




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

2013-09-01 Thread Carsten Dominik

On 31.8.2013, at 08:22, Bastien  wrote:

> 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

Done.

- Carsten

> 
> Thanks!
> 
> -- 
> Bastien




Re: [O] [PATCH] Handle literal 'hline arguments passed to ruby.

2013-09-01 Thread Carsten Dominik
Hi Rick,

are you a signed contributor?

- Carsten

On 15.8.2013, at 20:50, Rick Frankel  wrote:

> Solution shamelessly copied from ob-python.
> 
> * lisp/ob-ruby.el: New customizations `org-babel-ruby-hline-to' and
> `org-babel-ruby-nil-to'
> (org-babel-ruby-var-to-ruby): Convert incoming 'hlines.
> (org-babel-ruby-table-or-string): Convert outgoing nils.
> ---
> lisp/ob-ruby.el | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/lisp/ob-ruby.el b/lisp/ob-ruby.el
> index 20fb418..d15d288 100644
> --- a/lisp/ob-ruby.el
> +++ b/lisp/ob-ruby.el
> @@ -50,6 +50,20 @@
> (defvar org-babel-ruby-command "ruby"
> "Name of command to use for executing ruby code.")
> 
> +(defcustom org-babel-ruby-hline-to "nil"
> +  "Replace hlines in incoming tables with this when translating to ruby."
> +  :group 'org-babel
> +  :version "24.4"
> +  :package-version '(Org . "8.0")
> +  :type 'string)
> +
> +(defcustom org-babel-ruby-nil-to 'hline
> +  "Replace 'nil' in ruby tables with this before returning."
> +  :group 'org-babel
> +  :version "24.4"
> +  :package-version '(Org . "8.0")
> +  :type 'string)
> +
> (defun org-babel-execute:ruby (body params)
> "Execute a block of Ruby code with Babel.
> This function is called by `org-babel-execute-src-block'."
> @@ -115,13 +129,21 @@ Convert an elisp value into a string of ruby source code
> specifying a variable of the same value."
> (if (listp var)
> (concat "[" (mapconcat #'org-babel-ruby-var-to-ruby var ", ") "]")
> -(format "%S" var)))
> +(if (equal var 'hline)
> + org-babel-ruby-hline-to
> +  (format "%S" var
> 
> (defun org-babel-ruby-table-or-string (results)
> "Convert RESULTS into an appropriate elisp value.
> If RESULTS look like a table, then convert them into an
> Emacs-lisp table, otherwise return the results as a string."
> -  (org-babel-script-escape results))
> +  ((lambda (res)
> + (if (listp res)
> +  (mapcar (lambda (el) (if (equal el 'nil)
> +   org-babel-ruby-nil-to el))
> +  res)
> +   res))
> +   (org-babel-script-escape results)))
> 
> (defun org-babel-ruby-initiate-session (&optional session params)
> "Initiate a ruby session.
> -- 
> 1.8.0
> 
> 




Re: [O] Using org-goto loses org-todo-keyword-faces settings

2013-09-01 Thread Carsten Dominik
Hi Dale,

thank you for the report and detailed example.  I have followed your recipe and 
cannot reproduce the issue.

Regards

- Carsten

On 21.8.2013, at 02:25, Dale  wrote:

> Hi,
> 
>   My thanks to everyone who works on org-mode.  It is a truly 
> indispensable tool.
> 
>   I'm not sure if I have a bug or a feature request: I have custom faces 
> set up for my todo keywords (see my file local variable for 
> org-todo-keyword-faces at the bottom of this report).   When I use org-goto 
> (C-c C-j) and then exit goto mode, my custom colors for todo keywords are 
> reset to the defaults.
> 
>   Explicitly:
> 
> 1. Create and save an org file with the following contents:
> 
> --8<--Cut here--8<--
> * WAITING test1
> 
> #+TODO: NEW(n) PENDING(p!) WAITING(w!) HOLD(h!) | DONE(d!) CANCELLED(c!)
> 
> # Local Variables:
> # org-todo-keyword-faces: (("WAITING" . "dark orange")
> #  ("HOLD" . "dark orange"))
> # End:
> --8<--Cut here--8<--
> 
> 2. Revert the buffer to pick up the in-buffer configuration including file 
> local variables.
> 
> 3. C-c C-j followed by C-g to exit goto mode.
> 
> What I expected: WAITING would still be "dark orange" when I exit goto mode.
> 
> What I observed: WAITING reverts to the default red color when I exit goto 
> mode.
> 
> (WAITING is also red while I'm in org-goto mode, which is less of a problem 
> for me.  I'd be happy enough if the color was just restored when I'm done 
> with org-goto.)
> 
>   I would, of course, be grateful if my org-todo-keyword-faces would 
> still be respected after using goto mode.
> 
>   I am using Emacs 24.3.1, apparently, the unofficial Emacs Mac Port 
> (ftp://ftp.math.s.chiba-u.ac.jp/emacs/).  I just confirmed this behavior 
> using org-mode's master branch from git://orgmode.org/org-mode.git as of a 
> few minutes ago.  The output from org-submit-bug-report is below.
> 
> Thanks for everything,
> Dale
> 
> 
> Emacs  : GNU Emacs 24.3.1 (x86_64-apple-darwin12.4.0, Carbon Version 1.6.0 
> AppKit 1187.39)
> of 2013-06-26
> Package: Org-mode version 8.0.7 (release_8.0.7-383-g927f1b @ 
> /Users/dale/.emacs.d/packages/org-mode/)
> 
> current state:
> ==
> (setq
> org-hide-leading-stars t
> org-tab-first-hook '(org-hide-block-toggle-maybe
>  org-src-native-tab-command-maybe
>  org-babel-hide-result-toggle-maybe
>  org-babel-header-arg-expand)
> org-speed-command-hook '(org-speed-command-default-hook
>  org-babel-speed-command-hook)
> org-reverse-note-order t
> org-time-clocksum-format "%d:%02d"
> org-occur-hook '(org-first-headline-recenter)
> org-metaup-hook '(org-babel-load-in-session-maybe)
> org-agenda-todo-ignore-deadlines 'far
> org-src-window-setup 'other-window
> org-confirm-shell-link-function 'yes-or-no-p
> org-agenda-todo-ignore-scheduled 1
> org-default-notes-file "~/todo.org"
> org-startup-indented t
> org-after-todo-state-change-hook '(org-clock-out-if-current)
> org-src-mode-hook '(org-src-babel-configure-edit-buffer
> org-src-mode-configure-edit-buffer)
> org-tags-column -76
> org-agenda-before-write-hook '(org-agenda-add-entry-text)
> org-babel-pre-tangle-hook '(save-buffer)
> org-agenda-dim-blocked-tasks nil
> org-mode-hook '(#[nil "\300\301\302\303\304$\207"
>   [org-add-hook change-major-mode-hook org-show-block-all
>append local]
>   5]
> #[nil "\300\301\302\303\304$\207"
>   [org-add-hook change-major-mode-hook
>org-babel-show-result-all append local]
>   5]
> org-babel-result-hide-spec org-babel-hide-all-hashes
> my:org-mode-hook)
> org-outline-path-complete-in-steps nil
> org-agenda-todo-list-sublevels nil
> org-replace-disputed-keys t
> org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
>  org-babel-execute-safely-maybe)
> org-refile-use-outline-path t
> org-enforce-todo-dependencies t
> org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
>  org-cycle-hide-inline-tasks org-cycle-show-empty-lines
>  org-optimize-window-after-visibility-change)
> org-after-refile-insert-hook '(my:org-maybe-note-refile)
> org-metareturn-hook '(my:org-meta-return-hook)
> org-confirm-elisp-link-function 'yes-or-no-p
> org-metadown-hook '(org-babel-pop-to-session-maybe)
> org-default-priority 68
> org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent)
> org-completion-use-ido t
> org-src-preserve-indentation t
> org-clock-in-hook '(my:org-clock-in-set-pending-hook)
> org-agenda-files '("~/todo.org")
> org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
> )
> 
> In-buffer configuration:
> 
> #+TODO: NEW(n) PENDING(p!) WAITING(w!) HOLD(h!) | DONE(d!) CANCELLED(c!)
> 
> # Local Variables:
> # org-todo-keyword-faces: (("

Re: [O] Strange behaviour while assigning date to task

2013-09-01 Thread Carsten Dominik

On 19.8.2013, at 11:09, G. Martin Butz  wrote:

> Hello,
> 
> since I upgraded to Emacs 24 (24.3.50) using org (8.0.7) I sometimes 
> encounter a strange behaviour while assigning or reassignig a date to a task. 
> The calendar buffer is being displayed at least in two windows; the agenda 
> window disappeards and when trying to choose a date Emacs says e.g.: No 
> window up from selected window. When I hit enter the debugger says:
> 
> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
>  org-agenda-switch-to()
>  call-interactively(org-agenda-switch-to nil nil)
>  command-execute(org-agenda-switch-to)
> 
> See a screenshot here to illustrate, what I see: 
> 
> 
> I can not reliably reproduce this behaviour, sometimes it happens, sometimes 
> not. Usually I have to restart Emacs in order to get the date assignment to 
> work at all.
> 
> Any tipps how I could find out, what this behaviour is about?

Hi Martin,

anything less than a reproducible case will not help us to figure this out, 
sorry.
Have you tried with emacs -Q -l path/to minimal.emacs ?

Regards

- Carsten


Re: [O] skip:t option not working

2013-09-01 Thread Carsten Dominik

On 10.8.2013, at 20:46, Scott Randby  wrote:

> On 08/10/2013 02:00 PM, Nick Dokos wrote:
>> Scott Randby  writes:
>> 
>>> On 08/09/2013 10:58 PM, Nick Dokos wrote:
 Scott Randby  writes:
 
> I cannot get the skip:t option to work with HTML export. This option is
> listed in the manual, and it worked before Org-8. Am I missing
> something? Below is a simple sample in which skip:t doesn't work, even
> with emacs -q. I'm using Emacs 24.2.1 with Org 8.0.3.
> 
 
 I don't think it exists any longer.
 
>>> 
>>> If the option no longer exists, then it might be a good idea to remove
>>> it from the manual.
>>> 
>> 
>> Indeed, but afaict, it's no longer in the current (8.0.7) manual. Are
>> you looking at an older version of the manual perhaps? I might have
>> missed the reference of course, in which case if you post the details,
>> somebody will fix it.
>> 
> 
> You can find a reference to the skip option on this page:
> 
> http://orgmode.org/manual/Export-options.html
> 
> It seems that this is the old 12.2 page, but it still links up to the
> 8.0.7 manual. No wonder I've been confused. The correct 12.2 page is
> given by this link:
> 
> http://orgmode.org/manual/Export-back_002dends.html#Export-back_002dends
> 
> The current export options (which I missed before) are now in section 12.3:
> 
> http://orgmode.org/manual/Export-settings.html#Export-settings
> 
> I think the website needs to be cleaned up a bit.

Is this still an issue?

Thanks.

- Carsten

> 
> Scott Randby
> 




[O] bug#14605: bug#14605: Problem with export an .org file to .pdf does not open pdf file

2013-09-01 Thread Carsten Dominik

On 13.8.2013, at 15:14, Petr Hracek  wrote:

> Hi,
> 
> I have browsed the lisp code of org.el
> where  is mentioned:
> "External applications for opening `file:path' items in a document.
> Org-mode uses system defaults for different file types, but
> you can use this variable to set the application for a given file
> extension.  The entries in this list are cons cells where the car identifies
> files and the cdr the corresponding command.  Possible values for the
> file identifier are
> \"string\"A string as a file identifier can be interpreted in different
>   ways, depending on its contents:
> 
>   - Alphanumeric characters only:
> Match links with this file extension.
> Example: (\"pdf\" . \"evince %s\")
>  to open PDFs with evince.
> 
> What does it mean system defaults?
> What command is used for getting default programs?
> xdg-mine or another?
> Thank you in advance

Hi Petr,

these defaults come from

`org-file-apps-defaults-macosx'
`org-file-apps-defaults-windowsnt'
`org-file-apps-defaults-gnu'

They are basically the "open" commands for MacOS X and Windows, and mailcap for 
Unix/Linux.

Hope this helps

- Carsten

> 
> greetings
> Petr
> 
> On 06/25/2013 01:07 PM, Petr Hracek wrote:
>> On 06/13/2013 03:28 PM, Petr Hracek wrote:
>>> Hi folks,
>>> 
>>> I would like to export some .org file into .pdf file.
>>> This should also open PDF after export is done but it does not.
>>> 
>>> This is done by command C-c C-e d.
>>> In some case emacs freezes.
>>> 
>>> Could you please help me?
>>> 
>> Hi
>> 
>> I have find out that if file org/org.el where are defined variables like 
>> org-file-apps
>> is mentioned
>> ("\\.pdf\\'" . default)
>> 
>> When I changed them to e.g xpdf then pdf file is openned properly.
>> 
> 
> 
> -- 
> Best regards / S pozdravem
> Petr Hracek
> 
> 
> 
> 






Re: [O] Calendar change date on OS X Mountain Lion doesn't work

2013-09-01 Thread Carsten Dominik
Hi Chris,

On 13.8.2013, at 09:25, Chris Henderson  wrote:

> When using C-c C-s or C-s C-d to schedule or deadline a task, shift - left or 
> right arrow doesn't work for changing the date. Is there any alternate key 
> combo for OS X?
> 
> org mode 8.0.3 on Emacs 24.3.1.

This does work fine for me.

- Carsten

> 
> Thanks.




Re: [O] org-speed-commands-default 1 2 3

2013-09-01 Thread Carsten Dominik
Hi Oleh,

you have good arguments - but I still think this is a matter of workflow and 
preferences, so I am not going to change the defaults.  This is what we have 
user options for.

Thanks for taking the time to discuss is, and sorry for the slow reply.

- Carsten

On 8.8.2013, at 15:02, Oleh  wrote:

> On Thu, Aug 8, 2013 at 9:01 AM, Carsten Dominik
>  wrote:
>> 
>> On 23.7.2013, at 15:48, Oleh  wrote:
>> 
>>> Hi all,
>>> 
>>> I've recently started using `org-use-speed-commands', and I like it a lot,
>>> except I had to make one tweak:
>>> 
>>>   (setq org-use-speed-commands t)
>>>   (setq org-speed-commands-user
>>> '(("1" . (org-shifttab 1))
>>>   ("2" . (org-shifttab 2))
>>>   ("3" . (org-shifttab 3
>>> 
>>> The corresponding values of `org-speed-commands-default' aren't that useful
>>> for GTD:
>>> 
>>>   ("1" org-priority 65)
>>>   ("2" org-priority 66)
>>>   ("3" org-priority 67)
>> 
>> That depends on wether you work with priorities.  I find S-TAB easy enough, 
>> so I do not
>> really see the need for speed commands here.
> 
> Maybe I should elaborate my point of view on the usability.
> Priorities don't normally need "buttons" to jump between states,
> a "knob" is enough: only increase/decrease priority, not jump to priority 1,
> jump to priority 2 etc.
> 
> Outlines, on the other hand, can benefit from the ability to jump between
> the levels of expansion.
> 
> Level 1 is very useful - it minimizes everything, showing the
> structure of the file. S-TAB is useful and simple, but you have to
> repeat several times,
> checking each time if it has brought you to the level that you wanted to be 
> on.
> 
> Level 2 is very useful - and cannot, unlike Level 1, be reached by S-TAB.
> For my gtd.org, it shows the tasks and appointments, without expanding
> them, as well as the project names, but not what they contain.
> This gives a nice overview of my projects.
> 
> Level 3 is very useful - and cannot be reached by S-TAB.
> It shows me the separate TODOs for my projects, without revealing my
> notes on them, just the headings.
> I even bound the rest of the digits to levels and it is useful sometimes.
> 
> In my opinion, these shortcuts make org-mode a better outlining tool,
> and should be given priority before the priority shortcuts.
> 
> Slightly off-topic, these type of shortcuts is why I use Ubuntu Unity (I think
> I managed to turn off the spying). It's got a feature that Super+1-9
> switches between applications in the sidebar slots 1-9. Sure, it's
> possible to do with Alt-TAB, and that's what most other desktops do,
> but Super+1-9 is superior, since you don't have to wait for feedback,
> you instantly get what you want.
> 
> regards,
> Oleh







Re: [O] disable org-replace-disputed-keys for org-read-date

2013-09-01 Thread Carsten Dominik
Hi Miro,

I have implemented this.

Please test and make sure it works.

Regards

- Carsten

On 15.5.2013, at 11:37, Miro Bezjak  wrote:

> Hi all,
> 
> for orgmode 7.9.x I had the following defadvice.
> 
> 
> (defadvice org-read-date (around my-no-disputed-keys activate)
>   "Ignore org-replace-disputed-keys when calendar is active."
>   (let ((org-replace-disputed-keys nil))
> ad-do-it))
> 
> 
> Contrary to the `org-replace-disputed-keys' documentation (only being 
> relevant at load-time), the advice worked because in 7.9.x `org-read-date' 
> used `org-defkey' to add the relevant keybindings each time it was called.
> 
> In 8.0.x, this advice no longer works since 
> `org-read-date-minibuffer-local-map' is being used.
> 
> Basically, I'm trying to use windmove keys, but not when I'm entering dates 
> through calendar. In calendar, shift + arrow keys are really handy and 
> calendar is not active for a long time.
> 
> Does anyone have any suggestion how I can achieve that in 8.0.x without 
> patching org.el?
> 
> Should I make a patch to introduce defcustom that will ignore disputed keys 
> while setting up `org-read-date-minibuffer-local-map'? Anyone else interested 
> in this besides me?
> 
> Kind Regards,
> Miro
> 




Re: [O] Export subtree options not working

2013-09-01 Thread Carsten Dominik
Hi Edward,

these properties come only into effect is the export is restricted to the 
subtree carrying these properties.

HTH

- Carsten

On 28.7.2013, at 01:49, Edward DeMeulle  wrote:

> It appears that I'm using the properties syntax correctly, however I
> cannot seem to get export to use the options I set in the properties
> drawer. If I move the LaTeX_CLASS and OPTIONS over to their #+
> equivalents at the top of the file they work just fine. Is there
> something (hopefully not *too* obvious) that I'm doing wrong?
> 
> :PROPERTIES:
> :EXPORT_LaTeX_CLASS: report
> :EXPORT_OPTIONS: toc:nil num:nil H:4
> :COLUMNS: %25ITEM %TODO %15Business %16Start-Date %16Last-Update
> :EXPORT_PROPERTIES: 2 Business Start-Date Last-Update
> :END:
> 
> 




Re: [O] Completion of `*' gives wrong number of arguments

2013-09-01 Thread Carsten Dominik
Hi Dieter,

On 2.8.2013, at 16:53, "Dieter Wilhelm, H."  wrote:

> Dear (),
> 
> is the completion of an asterix `*' broken in the latest org or is it
> my configuration?

This was a bug in Org mode.  WOrks again now.

> 
> (I'm sorry I still can't run a pristine Emacs -Q without loading the
> old org mode)
> 
> Remark: It would be wonderful if the completion of headlines would
> also work within C-c C-l...

That would be a lot more work.

Regards

- Carsten

> 
> Have a nice weekend
> --
> Best wishes
> 
>H. Dieter Wilhelm
> 
> Darmstadt
> Germany
> 




Re: [O] [PATCH] Enable silent visibility cycling

2013-09-01 Thread Carsten Dominik

On 19.7.2013, at 19:54, Eric S Fraga  wrote:

> Thorsten Jolitz  writes:
> 
>> Eric S Fraga  writes:
>> 
>>> Would you wrap it all up in a patch and submit it?  It would be great to
>>> have incorporated.
>> 
>> ok, done. 
> 
> Brilliant!  Thanks.

This works now.

Kind regards

- Carsten

> -- 
> : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.0.6-341-g338603
> 
>