[O] Updating :PROPERTIES: :ACTUAL: with total clocked time

[Shakthi Kannan]

Hi,

I would like to know how we can update the :ACTUAL: field in
:PROPERTIES: for a DONE task with the total clocked time. A MWE:

=== sample.org ===

* IN_PROGRESS Task A
:PROPERTIES:
:ESTIMATED: 4.0
:ACTUAL:
:END:
:LOGBOOK:
CLOCK: [2017-01-26 Thu 19:00]--[2017-01-26 Thu 19:30] =>  0:30
CLOCK: [2017-01-26 Thu 13:00]--[2017-01-26 Thu 14:30] =>  1:30
:END:

=== END ===

As soon as I mark the above task as DONE, the total clocked time needs
to be updated in the :ACTUAL: field as shown below:

=== sample.org ===

* DONE Task A
:PROPERTIES:
:ESTIMATED: 4.0
:ACTUAL: 2.0
:END:
:LOGBOOK:
CLOCK: [2017-01-26 Thu 19:00]--[2017-01-26 Thu 19:30] =>  0:30
CLOCK: [2017-01-26 Thu 13:00]--[2017-01-26 Thu 14:30] =>  1:30
:END:

=== END ===

How can this be achieved?

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

Re: [O] org-babel-capitalize-example-region-markers

[Vicente Vera]

Nice, thank you.

2017-01-27 1:12 GMT+00:00 Kyle Meyer :

> Kyle Meyer  writes:
>
> [...]
>
> > Here's a patch.  I'll apply it to master in a day or two if there are no
> > objections.
>
> Applied with 9c111f63 (with :version changed from 25.2 to 26.1).
>
> --
> Kyle
>

Re: [O] Bug: clock comments [9.0.2 (9.0.2-elpaplus @ c:/USR/FJM/APP/.emacs.d/elpa/org-plus-contrib-20161214/)]

[Nicolas Goaziou]

Hello,

"Francis J. Monari, Esquire"  writes:

> The question remains "How can I make the notes associated with the Clock
> entry follow the Clock entry?

Short answer : put everything in the same drawer, i.e., LOGBOOK.

Long answer :

I considered re-introducing the behaviour you suggest, but there is one
issue.

When `org-clock-into-drawer' is set to an integer, an the number of
clocks in the entry get past it, all pre-existing clocks are moved to
log drawer (by default "LOGBOOK"). Unfortunately, it is not possible to
preserve association between the note and the clock (i.e., the list item
after the clock may or may not be a note relative to the clock). So we
cannot guarantee that both the note and the clock are always kept
together.

Basically, the two features are incompatible.

I'm open to suggestions.


Regards,

-- 
Nicolas Goaziou

Re: [O] src block: 'C-c C-c can do nothing useful here' if cursor on blank line

[Nicolas Goaziou]

Hello,

"Charles C. Berry"  writes:

> Nor I. Perhaps it was just an oversight.
>
> FWIW, in `org-ctrl-c-ctrl-c'
>
> :(looking-at-p "[ \t]*$")
>
> could be
>
> #+BEGIN_SRC emacs-lisp
>(and
> (looking-at-p "[ \t]*$")
> (not (eq 'src-block (org-element-type (org-element-context))
> #+END_SRC
>
> without causing a lot of grief. I think `src-block' is the only
> relevant case.

In almost all cases, you don't want C-c C-c to do anything on a blank
line. Commit 0b6a2e2416b0acc28469661d7013f92f82a34267 pointed out before
was pushed because calling C-c C-c on the blank lines right after
a blank line would call `org-set-tags'.

What you suggest is sub-optimal, tho. The point of this quick check is
to eschew `org-element-context' call a few lines below. This would make
two calls instead of one.

I think a proper solution is to bite the bullet and make the check after
calling `org-element-context', in a pcase branch. This is what I did in
ebb9da0d0.

Please let me know if it doesn't solve the issue.


Regards,

-- 
Nicolas Goaziou

Re: [O] src block: 'C-c C-c can do nothing useful here' if cursor on blank line

[Charles C. Berry]

On Fri, 27 Jan 2017, Kyle Meyer wrote:


Eric S Fraga  writes:


On Friday, 27 Jan 2017 at 18:44, John Hendy wrote:

Perhaps this is the intended behavior, but I noticed that I go to
execute a code block and get the message "C-c C-c can do nothing
useful here" if I'm not on the actual src block definition or a line
of code. If I'm on a blank line inside it, it doesn't execute. Here
was my test:


I have noticed this recently as well.  Not sure if it was always the
case, mind you, but it would be nice if C-c C-c would work even when the
cursor is on a blank line (within a src block, that is).


I think this changed with 0b6a2e241 (C-c C-c does nothing when at a
blank line, 2013-02-15).  I wasn't able to figure out the motivation for
that change.


Nor I. Perhaps it was just an oversight.

FWIW, in `org-ctrl-c-ctrl-c'

:(looking-at-p "[ \t]*$")

could be

#+BEGIN_SRC emacs-lisp
  (and
   (looking-at-p "[ \t]*$")
   (not (eq 'src-block (org-element-type (org-element-context))
#+END_SRC

without causing a lot of grief. I think `src-block' is the only
relevant case.

Chuck

Re: [O] src block: 'C-c C-c can do nothing useful here' if cursor on blank line

[Kyle Meyer]

Eric S Fraga  writes:

> On Friday, 27 Jan 2017 at 18:44, John Hendy wrote:
>> Perhaps this is the intended behavior, but I noticed that I go to
>> execute a code block and get the message "C-c C-c can do nothing
>> useful here" if I'm not on the actual src block definition or a line
>> of code. If I'm on a blank line inside it, it doesn't execute. Here
>> was my test:
>
> I have noticed this recently as well.  Not sure if it was always the
> case, mind you, but it would be nice if C-c C-c would work even when the
> cursor is on a blank line (within a src block, that is).

I think this changed with 0b6a2e241 (C-c C-c does nothing when at a
blank line, 2013-02-15).  I wasn't able to figure out the motivation for
that change.

-- 
Kyle

Re: [O] src block: 'C-c C-c can do nothing useful here' if cursor on blank line

[Eric S Fraga]

On Friday, 27 Jan 2017 at 18:44, John Hendy wrote:
> Perhaps this is the intended behavior, but I noticed that I go to
> execute a code block and get the message "C-c C-c can do nothing
> useful here" if I'm not on the actual src block definition or a line
> of code. If I'm on a blank line inside it, it doesn't execute. Here
> was my test:

I have noticed this recently as well.  Not sure if it was always the
case, mind you, but it would be nice if C-c C-c would work even when the
cursor is on a blank line (within a src block, that is).

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50.1, Org release_9.0.3-241-gc3d67b


signature.asc
Description: PGP signature

Re: [O] src block: 'C-c C-c can do nothing useful here' if cursor on blank line

[John Kitchin]

I get this all the time too. It would be nice if it went away, I also
find it annoying.

John Hendy writes:

> Perhaps this is the intended behavior, but I noticed that I go to
> execute a code block and get the message "C-c C-c can do nothing
> useful here" if I'm not on the actual src block definition or a line
> of code. If I'm on a blank line inside it, it doesn't execute. Here
> was my test:
>
> #+begin min_config
>
> (add-to-list 'load-path "~/.elisp/org/lisp/")
> (add-to-list 'load-path "~/.elisp/org/contrib/lisp")
>
> (org-babel-do-load-languages
>  'org-babel-load-languages
>  '((R . t)))
>
> #+end
>
> Start with =emacs -Q= and then =M-x load-file RET
> ~/path/to/min-config=, then use this test file:
>
> * heading
>
> #+begin_src R
> ^
> x <- 1:10
> x
>
> #+end_src
>
> With the cursor at ^ it won't run. I would understand if this were in
> interactive mode using =C-c '=, but the behavior of C-c C-c is to run
> the whole block anyway. It seems like Org doesn't know I'm in a src
> block. Since blank lines are common, I'd expect not to have to make
> *sure* I'm on an actual line of code and that being anywhere in a src
> block should work.
>
> Thoughts?
>
>
> Thanks,
> John


-- 
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] test.org

[Eric S Fraga]

On Friday, 27 Jan 2017 at 16:55, Jude DaShiell wrote:
> Interesting, I put a vertical on a line to start an org-mode table and 

[...]

> followed by hyphen followed by tab.  I got onto line 4 in column 3 but 
> line one acquired all of the verticals from line 2 in addition to what it 
> already had.

There's no question there?  What you got is what is expected as you
defined a table as soon as you put a | at the start of a line and on
subsequent lines and a table has all rows with the same number of
columns. 
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50.1, Org release_9.0.3-241-gc3d67b


signature.asc
Description: PGP signature

Re: [O] startup with 2 levels of headings shown?

[Thierry Banel]

Le 27/01/2017 09:57, Eric S Fraga a écrit :
> Hello,
>
> Is there an easy way to have an org file start up with 2 levels of
> headings shown without having to evaluate
>
> (org-content 2)
>
> ?
>
> E.g. it would be nice to be able to say:
>
> #+startup: overview 2
>
> or similar.  I only want this for some files (typically files intended
> to be exported via beamer, i.e. presentation slides) as otherwise I
> would use a hook.
>
> Thanks,
> eric
>

I have that at the end of the file:

  : Local Variables:  :
  : coding:utf-8  :
  : eval:(org-shifttab 2) :
  : End:  :

[O] src block: 'C-c C-c can do nothing useful here' if cursor on blank line

[John Hendy]

Perhaps this is the intended behavior, but I noticed that I go to
execute a code block and get the message "C-c C-c can do nothing
useful here" if I'm not on the actual src block definition or a line
of code. If I'm on a blank line inside it, it doesn't execute. Here
was my test:

#+begin min_config

(add-to-list 'load-path "~/.elisp/org/lisp/")
(add-to-list 'load-path "~/.elisp/org/contrib/lisp")

(org-babel-do-load-languages
 'org-babel-load-languages
 '((R . t)))

#+end

Start with =emacs -Q= and then =M-x load-file RET
~/path/to/min-config=, then use this test file:

* heading

#+begin_src R
^
x <- 1:10
x

#+end_src

With the cursor at ^ it won't run. I would understand if this were in
interactive mode using =C-c '=, but the behavior of C-c C-c is to run
the whole block anyway. It seems like Org doesn't know I'm in a src
block. Since blank lines are common, I'd expect not to have to make
*sure* I'm on an actual line of code and that being anywhere in a src
block should work.

Thoughts?


Thanks,
John

[O] startup with 2 levels of headings shown?

[Eric S Fraga]

Hello,

Is there an easy way to have an org file start up with 2 levels of
headings shown without having to evaluate

(org-content 2)

?

E.g. it would be nice to be able to say:

#+startup: overview 2

or similar.  I only want this for some files (typically files intended
to be exported via beamer, i.e. presentation slides) as otherwise I
would use a hook.

Thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50.1, Org release_9.0.3-241-gc3d67b


signature.asc
Description: PGP signature

[O] test.org

[Jude DaShiell]

Interesting, I put a vertical on a line to start an org-mode table and 
keyed data dictionary in followed by a space another vertical and a return 
key.  Then I put vertical followed by a space followed by variable 
followed by space followed by vertical followed by type followed by space 
followed by vertical followed by space followed by description followed by 
space followed by vertical followed by return followed by vertical 
followed by hyphen followed by tab.  I got onto line 4 in column 3 but 
line one acquired all of the verticals from line 2 in addition to what it 
already had.


| data dictionary |  | |
| variable| type | description |
|-+--+-|
| |  | |

--

Re: [O] org-faq page on Worg seems busted

[Nick Dokos]

Michael Welle  writes:

> Hello,
>
> Michael Welle  writes:
>
>> Hello,
>>
>> Nick Dokos  writes:
>> [...]
>>> that, but publishing locally fails at a couple of [[id:][foo]] links:
>>>
>>>Unable to resolve link: "id:facac2a6-3526-450d-ac42-8d36b16c6bab"
>>>
>>> What's up with that?
>> hm, I dimly remember having that (or a similar) problem. (require 'org-id)
>> fixed that for me.
> if the link target exists, of course.
>

That seems to do the job indeed - thanks!
-- 
Nick

[O] Bug: Emacs hangs with badly defined multi characters key hierarchy in org-capture-templates [9.0 (9.0-dist @ /cygdrive/c/Users/re/.emacs.d/site-lisp/org-9.0/lisp/)]

[Roland Everaert]

Hi,

When using multicharacters keys, if a key definition entry is missing,
emacs hangs and must be killed.

Example of an offending org-capture-templates definition:

(setq org-capture-templates
  '(("t" "Todo" entry (file+headline "~/somefile.org" "Tâches")
 "* TODO %?\n  %i\n"  :clock-in t :clock-resume t)
("l" "Mail" entry (file+datetree "~/somefile.org" "Divers")
 "* EMAIL %?\n  %i\n" :clock-in t :clock-resume t)
("fm" "some Menu - level 2")
("fmm" "template defintion - level 3 " entry (file+olp "~/somefile.org"
"Level 1" "level 2")
 "* MEETING %?\n  %i\n" :clock-in t :clock-resume t)
("fmt" "another template definition - level 3" entry (file+olp "~/
somefile.org" "Level 1" "level 2")
 "*** TODO %?\n  %i\n" :clock-in t :clock-resume t)))

The definition of the "f" key is missing.

In such case, org-mode should display a message and, do nothing or ignore
the offending tree.

Emacs  : GNU Emacs 25.1.1 (x86_64-unknown-cygwin)
 of 2016-09-17
Package: Org mode version 9.0 (9.0-dist @
/cygdrive/c/Users/re/.emacs.d/site-lisp/org-9.0/lisp/)


Regards,

Re: [O] titles on tables

[Eric S Fraga]

On Friday, 27 Jan 2017 at 04:46, Jude DaShiell wrote:
> Is it possible to do something like:
> | Data Dictionary |
> | variable | type| description|
> |-
>
> As a table header or maybe even somehow have data dictionary centered?
> I made a table earlier without the title line and tried doing a retrofit 
> that didn't work.  If this isn't possible and the table won't be exported 
> to html or other formats does another way exist to do this?

Not possible but maybe just use #+caption: ?
#+begin_src org
  ,#+caption: Data Dictionary 
  | variable | type| description |
  |-
#+end_src

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50.1, Org release_9.0.3-241-gc3d67b


signature.asc
Description: PGP signature

[O] [BUG?] is [org-image-actual-width] deprecated? setting it in config crashes emacs?

[Xebar Saram]

Hi all

after bisecting today i discovered today that the thing the kept crashing
emacs was this variable `org-image-actual-width` which was set this way in
my config

(setq org-image-actual-width '(400))

did i not define it correctly? and if so why is it crashing emacs when i
load a org file with images and open a header that will present such an
image?

attached is a backtrace i created when the variable was on

thx

Z
address@hidden:~|⇒  gdb /usr/bin/emacs
GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/emacs...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/emacs 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffe8836700 (LWP 9649)]
[New Thread 0x7fffe7c1d700 (LWP 9650)]
[New Thread 0x7fffe741c700 (LWP 9651)]
[New Thread 0x7fffd21ad700 (LWP )]
[New Thread 0x7fffd19ac700 (LWP 1)]
[New Thread 0x7fffd11ab700 (LWP 10001)]

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x004c4e27 in x_draw_glyph_string ()
(gdb) thread apply all bt

Thread 7 (Thread 0x7fffd11ab700 (LWP 10001)):
#0  0x7fffee7e757e in futex_wait (val=8, addr=0xb148644) at 
/build/gcc-multilib/src/gcc/libgomp/config/linux/x86/futex.h:44
#1  0x7fffee7e757e in do_wait (val=8, addr=0xb148644) at 
/build/gcc-multilib/src/gcc/libgomp/config/linux/wait.h:67
#2  0x7fffee7e757e in gomp_barrier_wait_end (bar=0xb148640, state=8) at 
/build/gcc-multilib/src/gcc/libgomp/config/linux/bar.c:48
#3  0x7fffee7e4d80 in gomp_thread_start (xdata=) at 
/build/gcc-multilib/src/gcc/libgomp/team.c:123
#4  0x71718454 in start_thread () at /usr/lib/libpthread.so.0
#5  0x7145b7df in clone () at /usr/lib/libc.so.6

Thread 6 (Thread 0x7fffd19ac700 (LWP 1)):
#0  0x7fffee7e757e in futex_wait (val=8, addr=0xb148644) at 
/build/gcc-multilib/src/gcc/libgomp/config/linux/x86/futex.h:44
#1  0x7fffee7e757e in do_wait (val=8, addr=0xb148644) at 
/build/gcc-multilib/src/gcc/libgomp/config/linux/wait.h:67
#2  0x7fffee7e757e in gomp_barrier_wait_end (bar=0xb148640, state=8) at 
/build/gcc-multilib/src/gcc/libgomp/config/linux/bar.c:48
#3  0x7fffee7e4d80 in gomp_thread_start (xdata=) at 
/build/gcc-multilib/src/gcc/libgomp/team.c:123
#4  0x71718454 in start_thread () at /usr/lib/libpthread.so.0
#5  0x7145b7df in clone () at /usr/lib/libc.so.6

Thread 5 (Thread 0x7fffd21ad700 (LWP )):
#0  0x7fffee7e757e in futex_wait (val=8, addr=0xb148644) at 
/build/gcc-multilib/src/gcc/libgomp/config/linux/x86/futex.h:44
#1  0x7fffee7e757e in do_wait (val=8, addr=0xb148644) at 
/build/gcc-multilib/src/gcc/libgomp/config/linux/wait.h:67
#2  0x7fffee7e757e in gomp_barrier_wait_end (bar=0xb148640, state=8) at 
/build/gcc-multilib/src/gcc/libgomp/config/linux/bar.c:48
#3  0x7fffee7e4d80 in gomp_thread_start (xdata=) at 
/build/gcc-multilib/src/gcc/libgomp/team.c:123
#4  0x71718454 in start_thread () at /usr/lib/libpthread.so.0
#5  0x7145b7df in clone () at /usr/lib/libc.so.6

Thread 4 (Thread 0x7fffe741c700 (LWP 9651)):
#0  0x7145248d in poll () at /usr/lib/libc.so.6
#1  0x748d3786 in  () at /usr/lib/libglib-2.0.so.0
#2  0x748d3b12 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x750e0316 in  () at /usr/lib/libgio-2.0.so.0
#4  0x748fb0d5 in  () at /usr/lib/libglib-2.0.so.0
#5  0x71718454 in start_thread () at /usr/lib/libpthread.so.0
#6  0x7145b7df in clone () at /usr/lib/libc.so.6

Thread 3 (Thread 0x7fffe7c1d700 (LWP 9650)):
#0  0x7145248d in poll () at /usr/lib/libc.so.6
#1  0x748d3786 in  () at /usr/lib/libglib-2.0.so.0
#2  0x748d389c in g_main_context_iteration () at 
/usr/lib/libglib-2.0.so.0
#3  0x7fffe7c254bd in  () at /usr/lib/gio/modules/libdconfsettings.so
#4  0x748fb0d5 in  () at /usr/lib/libglib-2.0.so.0
#5  0x71718454 in start_thread () at /usr/lib/libpthread.so.0
#6  0x7145b7df in clone () at /usr/lib/libc.so.6

Thread 2 (Thread 0x7fffe8836700 (LWP 9649)):
#0  0x7145248d in poll () at /usr/lib/libc.so.6
#1  0x748d3786 in  () at /usr/lib/libglib-2.0.so.0
#2  0x748d389c in g_main_context_iteration () at 
/usr/lib/libglib-2.0.so.0
#3  

Re: [O] org-faq page on Worg seems busted

[Michael Welle]

Hello,

Michael Welle  writes:

> Hello,
>
> Nick Dokos  writes:
> [...]
>> that, but publishing locally fails at a couple of [[id:][foo]] links:
>>
>>Unable to resolve link: "id:facac2a6-3526-450d-ac42-8d36b16c6bab"
>>
>> What's up with that?
> hm, I dimly remember having that (or a similar) problem. (require 'org-id)
> fixed that for me.
if the link target exists, of course.

Regards
hmw

Re: [O] org-faq page on Worg seems busted

[Michael Welle]

Hello,

Nick Dokos  writes:
[...]
> that, but publishing locally fails at a couple of [[id:][foo]] links:
>
>Unable to resolve link: "id:facac2a6-3526-450d-ac42-8d36b16c6bab"
>
> What's up with that?
hm, I dimly remember having that (or a similar) problem. (require 'org-id)
fixed that for me.

Regards
hmw