Re: [O] Tracking time from one state to another?

[Ken Mankoff]

Hi Malcom,

I think we're talking about two different things here. When you change TODO 
state, the time of the change is recorded. This is what you're doing.

Org also has a time-tracking feature that is totally separate. You can "clock 
in" and "clock out" of a task which starts and stops a timer. You can then 
generate reports about that timer. The timer can be activated regardless of the 
TODO state, but you could also have the timer start (clock in) every time you 
set the state to "WORKING_ON_IT" or "INPROGRESS", and the timer stop (clock 
out) whenever the task is in NEXT or WAITING state.

Then you can generate a CLOCK REPORT for each task and sub-task, which is the 
amount of time you actually worked on it (i.e. the amount of time it spent in 
the WORKING_ON_IT state.

This is a different workflow than your current one - it uses the Org clocking 
feature, not just the TODO status feature.

  -k.

On 2019-04-23 at 08:07 +0200, Malcolm Matalka  wrote...
> Ken Mankoff  writes:
>
>> Hi Malcom,
>>
>> On 2019-04-17 at 14:20 +0200, Malcolm Matalka  wrote...
>>> Is it possible in org-mode to track, and report, the duration of
>>> certain state transitions in org-mode? In particular, I'm interested
>>> in tracking how long it takes me to go from a state that means I'm
>>> actively working on an item to it being in a done state?
>>>
>>> In my case, an item might go from working, to waiting, to working, to
>>> done.  And in this case I'm only really interested in the last working
>>> to done time.
>>
>> Org doesn't have a built-in feature to turn on/off the clock when you
>> change state, as far as I know. But it has the opposite - you can
>> change state when you clock in or out of a task.
>
> I don't want to turn on/off the clock when I change state, I want to get
> a report on the time between certain state transitions.  That
> information is stored in the LOGBOOK (assuming one has that turned on).
>
>>
>> See section 7 here 
>> https://writequit.org/denver-emacs/presentations/2017-04-11-time-clocking-with-org.html#helpful-things
>>
>> And/or maybe thread here w/ some code 
>> https://lists.gnu.org/archive/html/emacs-orgmode//2009-04/msg00315.html
>>
>> So perhaps you can achieve this by changing your workflow a bit. Instead of 
>> changing state, just clock in and have the state set to INPROGRESS. Clock 
>> otu and have it set to WAITING. When it is done, it may be a two-step 
>> process of setting to DONE and making sure the clock is stopped.
>>
>> Would this achieve what you're looking for?
>
> Unfortunately no.  I need to track the total time I spend in a task for
> billing reasons, but what I'm interested in here is how quickly I
> complete a task when there are no blockers/dependencies.  And the way
> that presents itself in my LOGBOOK is the time between the final
> transition from NEXT to DONE.  Before that, a TODO can go from NEXT, to
> WAITING, and back and forth.
>
>>
>>   -k.

Re: [O] Tracking time from one state to another?

[Malcolm Matalka]

Ken Mankoff  writes:

> Hi Malcom,
>
> On 2019-04-17 at 14:20 +0200, Malcolm Matalka  wrote...
>> Is it possible in org-mode to track, and report, the duration of
>> certain state transitions in org-mode? In particular, I'm interested
>> in tracking how long it takes me to go from a state that means I'm
>> actively working on an item to it being in a done state?
>>
>> In my case, an item might go from working, to waiting, to working, to
>> done.  And in this case I'm only really interested in the last working
>> to done time.
>
> Org doesn't have a built-in feature to turn on/off the clock when you
> change state, as far as I know. But it has the opposite - you can
> change state when you clock in or out of a task.

I don't want to turn on/off the clock when I change state, I want to get
a report on the time between certain state transitions.  That
information is stored in the LOGBOOK (assuming one has that turned on).

>
> See section 7 here 
> https://writequit.org/denver-emacs/presentations/2017-04-11-time-clocking-with-org.html#helpful-things
>
> And/or maybe thread here w/ some code 
> https://lists.gnu.org/archive/html/emacs-orgmode//2009-04/msg00315.html
>
> So perhaps you can achieve this by changing your workflow a bit. Instead of 
> changing state, just clock in and have the state set to INPROGRESS. Clock otu 
> and have it set to WAITING. When it is done, it may be a two-step process of 
> setting to DONE and making sure the clock is stopped.
>
> Would this achieve what you're looking for?

Unfortunately no.  I need to track the total time I spend in a task for
billing reasons, but what I'm interested in here is how quickly I
complete a task when there are no blockers/dependencies.  And the way
that presents itself in my LOGBOOK is the time between the final
transition from NEXT to DONE.  Before that, a TODO can go from NEXT, to
WAITING, and back and forth.

>
>   -k.

[O] install confusion

[Lawrence Bottorff]

I've got this in my init, which is in an org file with embedded elisp
blocks:

(use-package org-plus-contrib
  :defer t
  :ensure t
  )

then right after I have

(use-package org
:ensure t
:bind (("C-c a" . org-agenda)
   ("C-c c" . org-capture)
   ("C-c l" . org-store-link))
:config
(setq org-ellipsis " ")
   . . .
)

where the use-package org form has extensive config info in it. Am I wrong
with having both? In my ELPA directory I only see org-plus-contrib-20...
which has such things as org.el. I'm using "https://orgmode.org/elpa/ BTW.

LB

Re: [O] [Proposal] Source Blocks with Post-Extensions

[Tim Cross]

YMMV, but personally, I think the real problem here is combining your
tests with your definition. i.e. square = lambda x: x * x is your real
code block while the return line is really just part of
testing/debugging and should not be in your definition block.

Tests are very important, but I find they 'clutter' the code and make it
harder to read/think about the core functionality - especially after
leaving and returning some time later to worik on the core code.

My approach is to keep the code blocks as 'pure' as possible and put all
the tests in a separate section of the org file. It does make code test
coverage a bit more challenging because you don't have the two 'side by
side', but I find that is offset by the increased clarity with the main
code.

just an alternative view 

Dmitrii Korobeinikov  writes:

> For your convenience, I have attached this e-mail as an org-mode file.
>
> When I write several source blocks, which depend on one another, I tend to
> debug them one by one.
>
> So, I write this function and test it:
>
> #+NAME: square
> #+BEGIN_SRC python
> square = lambda x: x * x
> return square(5)
> #+END_SRC
>
> #+RESULTS: square
> : 25
>
> After I see that the test is successful, I write this client function:
>
> #+BEGIN_SRC python :noweb yes
> <>
> return 5 + square(5)
> #+END_SRC
>
> #+RESULTS:
> : 25
>
> And here, to get the correct result, I have to remove the ~return
> square(5)~ line in ~<>~.
> But I don't want to lose testing!
> So I find nothing better to do than to seperate the source block:
>
> #+NAME: square-1
> #+BEGIN_SRC python
> square = lambda x: x * x
> #+END_SRC
>
> And, by the way, there was no error/warning that I have just redefined
> ~<>~,
> so, for the test-snippet below to work, I renamed it to ~<>~.
> I think the org-mode team is aware of it, but anyway:
>
> - [ ] no error checking of the description of a code block.
>
> #+NAME: square-1-tester
> #+BEGIN_SRC python :noweb yes
>   <>
>   return square(5)
> #+END_SRC
>
> #+RESULTS: square-1-tester
> : 25
>
> - [ ] For every such source block used for testing purposes, you have to
> repeat the inclusion statement and part of the name, which is cumbersome.
>
> A fair solution is maybe to extend the block like this:
>
> #+NAME: square-1
> #+BEGIN_SRC python
>   square = lambda x: x * x
> #+END_SRC
>   return square(5)
> #+END_SRC_TEST
>
> When I call this individually, the test part would run, but when I :noweb
> it in another block, the test part would be ommited.
>
> As an extension of this idea, it could be useful to have several test
> attachments like this, each producing its own result. Maybe, the TEST part
> could as well be ommited. Custom names are also an option:
>
> #+NAME: square-multiple
> #+BEGIN_SRC python
>   square = lambda x: x * x
> #+END_SRC
>   return square(5)
> #+END_SRC NAME: ext_1
>   return square(10)
> #+END_SRC NAME: ext_2
>
> #+RESULTS: square-multiple-ext-1
> : 25
>
> #+RESULTS: square-multiple-ext-2
> : 100
>
> Overall, these techniques should reduce noise and increase usability.


-- 
Tim Cross

Re: [O] [latex export/babel] pass arguments to \includegraphics from code blocks

[Jakob Schöttl]

Am 22.04.19 um 21:13 schrieb Nick Dokos:

Jakob Schöttl  writes:

Hi, I want to use code blocks to generate and include images of sheet music:

#+BEGIN_SRC lilypond :file test.png :exports results
\header{tagline=""}
{ a b c }
#+END_SRC


When doing a latex export the result is:

\begin{center}
\includegraphics[width=.9\linewidth]{test.png}
\end{center}

Is there a way to specify the arguments for \includegraphics? For
example I want to change the display width.

Putting these lines above the code block have no effect:

#+ATTR_LATEX: :width 4cm

#+CAPTION: xxx

Maybe this requires a change in ob-lilypond.el to introduce new header
arguments for the source block?


What I do in such cases is evaluate the block and then add the caption and
attribute line above the #+RESULTS line:

--8<---cut here---start->8---
#+BEGIN_SRC lilypond :file test.png :exports results
\header{tagline=""}
{ a b c }
#+END_SRC


#+ATTR_LATEX: :width 4cm
#+CAPTION: xxx
#+RESULTS:
[[file:test.png]]
--8<---cut here---end--->8---



Thank you, Nick! That's perfect.

[O] Regression in org-table-recalculate-buffer-tables and #+startup: shrink [devel branch]

[Kaushal Modi]

Hello,

Lately (past week), I have noticed a failure for all functions to run from
my org-mode-hook, because I got an error like:

File mode specification error: (user-error Not at a table)

This error happens if:

1. I call M-x org-table-recalculate-buffer-tables (I have that function in
my org-mode-hook).
2. The Org buffer has #+startup: shrink, and
3. An Org table with column width cookies has #+caption.

Here's a minimal reproducible example:

=
#+title: User-error when trying to recalculate tables in buffer with shrink
enabled
#+startup: shrink

#+caption: Foo
| <25> |
| Foo  |
=

1. Save above to an Org file, close and reopen that file so that #+startup
gets evaluated.
2. M-x org-table-recalculate-buffer-tables and you will get the
"user-error: Not at a table" error.

Interestingly, this error does not show up if simply that #+caption line is
removed.

I believe that this commit caused this regression:
https://code.orgmode.org/bzg/org-mode/commit/222408d70a3674f06ddd6b77e4e1126c602e7361
.

Org mode version 9.2.3 (release_9.2.3-336-g09a1a2 @
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/)

Thanks!

--
Kaushal Modi

Re: [O] orgalist and refill a paragraph

[Tim Cross]

Just in case it is relevant, if your using a recent emacs, you might be
running into a bug which was recently reported to do with changes in
text-mode. The bug was found by an orglist user and affected subsequent
line indentation. See the emacs devel list archives for details (was
within the last 2 weeks from memory).

Tim

Nicolas Goaziou  writes:

> Hello,
>
> Uwe Brauer  writes:
>
>> I am using orgalist-mode in mail buffers via.
>>
>> (add-hook 'mail-mode-hook #'orgalist-mode)
>> (add-hook 'message-mode-hook #'orgalist-mode)
>>
>>
>> The filling works nicely if I start like this 
>>
>> 1.  Akja kjkajsdk fjadkfjaksdjfa kajskfj sajflksajdf lkjsaljfksadjf
>> ksajfdkajsd fkjsadlkfj
>>
>>
>> However if I have already some long text say 
>>
>>
>> Ajdfkaj fkasjdkfjasf akjasjfkajslkfj aslkjf asdkj flks ajfk ajslkfj
>> sakfjksa 
>>
>> And put the cursor on the first word and insert intent + a number like
>> this
>>
>>
>>
>> 1.  Ajdfkaj fkasjdkfjasf akjasjfkajslkfj aslkjf asdkj flks ajfk ajslkfj
>> sakfjksa 
>>
>>
>> Then the filling M-q and friends does not result in 
>>
>> 1.  Akja kjkajsdk fjadkfjaksdjfa kajskfj sajflksajdf lkjsaljfksadjf
>> ksajfdkajsd fkjsadlkfj
>>
>>
>> Any idea how to achieve this desired filling?
>
> Use TAB on the second line. In any case, I don't think orgalist should
> do it. The second line doesn't belong to the list, by definition.
>
> Regards,


-- 
Tim Cross

Re: [O] [latex export/babel] pass arguments to \includegraphics from code blocks

[Nick Dokos]

Jakob Schöttl  writes:

> Hi, I want to use code blocks to generate and include images of sheet music:
>
> #+BEGIN_SRC lilypond :file test.png :exports results
> \header{tagline=""}
> { a b c }
> #+END_SRC
>
>
> When doing a latex export the result is:
>
> \begin{center}
> \includegraphics[width=.9\linewidth]{test.png}
> \end{center}
>
> Is there a way to specify the arguments for \includegraphics? For 
> example I want to change the display width.
>
> Putting these lines above the code block have no effect:
>
> #+ATTR_LATEX: :width 4cm
>
> #+CAPTION: xxx
>
> Maybe this requires a change in ob-lilypond.el to introduce new header 
> arguments for the source block?
>

What I do in such cases is evaluate the block and then add the caption and
attribute line above the #+RESULTS line:

--8<---cut here---start->8---
#+BEGIN_SRC lilypond :file test.png :exports results
\header{tagline=""}
{ a b c }
#+END_SRC


#+ATTR_LATEX: :width 4cm
#+CAPTION: xxx
#+RESULTS:
[[file:test.png]]
--8<---cut here---end--->8---

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] orgalist and refill a paragraph

[Nicolas Goaziou]

Hello,

Uwe Brauer  writes:

> I am using orgalist-mode in mail buffers via.
>
> (add-hook 'mail-mode-hook #'orgalist-mode)
> (add-hook 'message-mode-hook #'orgalist-mode)
>
>
> The filling works nicely if I start like this 
>
> 1.  Akja kjkajsdk fjadkfjaksdjfa kajskfj sajflksajdf lkjsaljfksadjf
> ksajfdkajsd fkjsadlkfj
>
>
> However if I have already some long text say 
>
>
> Ajdfkaj fkasjdkfjasf akjasjfkajslkfj aslkjf asdkj flks ajfk ajslkfj
> sakfjksa 
>
> And put the cursor on the first word and insert intent + a number like
> this
>
>
>
> 1.  Ajdfkaj fkasjdkfjasf akjasjfkajslkfj aslkjf asdkj flks ajfk ajslkfj
> sakfjksa 
>
>
> Then the filling M-q and friends does not result in 
>
> 1.  Akja kjkajsdk fjadkfjaksdjfa kajskfj sajflksajdf lkjsaljfksadjf
> ksajfdkajsd fkjsadlkfj
>
>
> Any idea how to achieve this desired filling?

Use TAB on the second line. In any case, I don't think orgalist should
do it. The second line doesn't belong to the list, by definition.

Regards,

-- 
Nicolas Goaziou

[O] [latex export/babel] pass arguments to \includegraphics from code blocks

[Jakob Schöttl]

Hi, I want to use code blocks to generate and include images of sheet music:

#+BEGIN_SRC lilypond :file test.png :exports results
\header{tagline=""}
{ a b c }
#+END_SRC

When doing a latex export the result is:

\begin{center}
\includegraphics[width=.9\linewidth]{test.png}
\end{center}

Is there a way to specify the arguments for \includegraphics? For 
example I want to change the display width.


Putting these lines above the code block have no effect:

#+ATTR_LATEX: :width 4cm
#+CAPTION: xxx

Maybe this requires a change in ob-lilypond.el to introduce new header 
arguments for the source block?


Regards, Jakob

Re: [O] [Proposal] Source Blocks with Post-Extensions

[Berry, Charles]

> On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov  wrote:
> 
> Thank you!
> That's a handy technique and it does help.
> As I understand, there's no way to extend that to multiple lines?

AFAICS, no there is no way to split the :epilogue arg to multiple lines.

Of course, you can always follow a src block that provides a function with 
another src block that imports the code via noweb and then tests the function 
with as many lines of code as you need. 

Chuck

Re: [O] [Proposal] Source Blocks with Post-Extensions

[Dmitrii Korobeinikov]

Thank you!
That's a handy technique and it does help.
As I understand, there's no way to extend that to multiple lines?
One-liners for tests are enough sometimes, but not always.
For those cases, it is cumbersome to split as well.

пн, 22 апр. 2019 г. в 22:51, Berry, Charles :

> It looks like you want the :epilogue header argument. See inline.
>
> > On Apr 22, 2019, at 2:00 AM, Dmitrii Korobeinikov 
> wrote:
> >
> > When I write several source blocks, which depend on one another, I tend
> to debug them one by one.
> >
> > So, I write this function and test it:
> >
> > #+NAME: square
> > #+BEGIN_SRC python
> > square = lambda x: x * x
> > return square(5)
> > #+END_SRC
> >
> > #+RESULTS: square
> > : 25
> >
>
>
> Equivalently, you could run this:
>
> #+NAME: square
> #+BEGIN_SRC python :epilogue  return square(5)
> square = lambda x: x * x
> #+END_SRC
>
>
>
> > After I see that the test is successful, I write this client function:
> >
> > #+BEGIN_SRC python :noweb yes
> > <>
> > return 5 + square(5)
> > #+END_SRC
> >
> > #+RESULTS:
> > : 25
> >
> > And here, to get the correct result, I have to remove the ~return
> square(5)~ line in ~<>~.
> > But I don't want to lose testing!
> > S
>
> With my version of `square`, the epilogue is not included.
>
> So it works as you want it to.
>
> HTH,
>
> Chuck
>
>
>

Re: [O] source-block 'uncomment-region' comments out a second time

[Berry, Charles]

> On Apr 22, 2019, at 3:49 AM, Daniel Herzig  wrote:
> 
> I found a minor problem when editing source code blocks. I am on
> Org-Mode 8.2.10 that comes with Emacs 25.1.1 on Debian.

With more modern versions (9.2.3, for example), the behavior you describe does 
not occur.

viz., (un)commenting is language aware in the org buffer (as well as in the 
edit buffer).

HTH,

Chuck

Re: [O] [Proposal] Source Blocks with Post-Extensions

[Berry, Charles]

It looks like you want the :epilogue header argument. See inline.

> On Apr 22, 2019, at 2:00 AM, Dmitrii Korobeinikov  wrote:
> 
> When I write several source blocks, which depend on one another, I tend to 
> debug them one by one.
> 
> So, I write this function and test it:
> 
> #+NAME: square
> #+BEGIN_SRC python
> square = lambda x: x * x
> return square(5)
> #+END_SRC
> 
> #+RESULTS: square
> : 25
> 


Equivalently, you could run this:

#+NAME: square
#+BEGIN_SRC python :epilogue  return square(5)
square = lambda x: x * x
#+END_SRC



> After I see that the test is successful, I write this client function:
> 
> #+BEGIN_SRC python :noweb yes
> <>
> return 5 + square(5)
> #+END_SRC
> 
> #+RESULTS:
> : 25
> 
> And here, to get the correct result, I have to remove the ~return square(5)~ 
> line in ~<>~.
> But I don't want to lose testing!
> S

With my version of `square`, the epilogue is not included. 

So it works as you want it to.

HTH,

Chuck

[O] orgalist and refill a paragraph

[Uwe Brauer]

Hi 

I am using orgalist-mode in mail buffers via.

(add-hook 'mail-mode-hook #'orgalist-mode)
(add-hook 'message-mode-hook #'orgalist-mode)


The filling works nicely if I start like this 

1.  Akja kjkajsdk fjadkfjaksdjfa kajskfj sajflksajdf lkjsaljfksadjf
ksajfdkajsd fkjsadlkfj


However if I have already some long text say 


Ajdfkaj fkasjdkfjasf akjasjfkajslkfj aslkjf asdkj flks ajfk ajslkfj
sakfjksa 

And put the cursor on the first word and insert intent + a number like
this



1.  Ajdfkaj fkasjdkfjasf akjasjfkajslkfj aslkjf asdkj flks ajfk ajslkfj
sakfjksa 


Then the filling M-q and friends does not result in 

1.  Akja kjkajsdk fjadkfjaksdjfa kajskfj sajflksajdf lkjsaljfksadjf
ksajfdkajsd fkjsadlkfj


Any idea how to achieve this desired filling?

Thanks and regards

Uwe Brauer 

Re: [O] html export entire code block including template?

[Lawrence Bottorff]

Just found it here

.

On Tue, Apr 16, 2019 at 12:08 AM Lawrence Bottorff 
wrote:

> I'm doing this:
>
> #+begin_example
> #+begin_src emacs-lisp :var table=sandbox :exports both
>   (message "%S" table)
> #+end_src
> #+end_example
>
> to force html export into displaying the entire block, including the code
> block wrapper. Is there a more elegant way, perhaps in the #+begin line to
> tell export to include even the wrapper?
>
> LB
>

Re: [O] [PATCH] Feature proposal : support "scale=" includegraphics option in the builtin latex exporter.

[Emmanuel Charpentier]

Le lundi 22 avril 2019 à 15:26 +0200, Nicolas Goaziou a écrit :
> Emmanuel Charpentier  writes:
> 
> > Do you want a direct answer or a partch against /etc/ORG-NEWS ?
> 
> Anything that suits you.

A patch it is (enclosed).

If this documentation is customaty, this should be mentioned in the
"Contribute" page of Worg (which, IMHO, should be pointed to by the 
"Feedback" section of the manual).

--
Emmanuel Charpentier

From 99d503bb11ef7923393c7bbd0dd5cdc07e3fca6d Mon Sep 17 00:00:00 2001
From: Emmanuel Charpentier 
Date: Mon, 22 Apr 2019 16:56:00 +0200
Subject: [PATCH 2/2] Document the LATEX_ATTR :scale parameter in ORG-NEWS

* etc/ORG-NEWS: document the new builtin LaTeX exporters' LATEX_ATTR
  :scale parameter
---
 etc/ORG-NEWS | 25 +
 1 file changed, 25 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 79659ea50..3285c91d9 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -192,6 +192,31 @@ This is a function for convenience.
 The new paramater ~:dbconnection~ allows to specify a connection name
 in a SQL block header: this name is used to look up connection
 parameters in ~sql-connection-alist~.
+
+*** New ~LATEX_ATTR~ ~:scale~ supported by the built-in LaTeX exporters
+
+The builtin ~org-latex-export*~ exporters now accept and use a
+~:scale~ attribute, which scales an image by a given factor.
+
+This attribute is wrapped adound the ~scale=~ parameter of LaTeX's
+~\\includegraphics~ (bitmap images) or a ~TiKZ~'s
+~\\scalebox~. Therefore, its value should be some string palatable to
+LaTeX as a positive float Its default value is an empty string
+(i.e. disabled).
+
+This attribute *overrides* the ~:width~ and ~:height~ attributes ;
+therefore, while it can be given a default value, this should be done
+only under exceptional circumstances.
+
+#+begin_example
+
+#+name: Beastie
+#+caption: I think I saw this curious horse already, but where ?
+#+LATEX_ATTR: :scale 2
+[[https://orgmode.org/img/org-mode-unicorn-logo.png]]
+
+#+end_example
+
 ** New functions
 *** ~org-dynamic-block-insert-dblock~
 
-- 
2.20.1

Re: [O] Tracking time from one state to another?

[Ken Mankoff]

Hi Malcom,

On 2019-04-17 at 14:20 +0200, Malcolm Matalka  wrote...
> Is it possible in org-mode to track, and report, the duration of
> certain state transitions in org-mode? In particular, I'm interested
> in tracking how long it takes me to go from a state that means I'm
> actively working on an item to it being in a done state?
>
> In my case, an item might go from working, to waiting, to working, to
> done.  And in this case I'm only really interested in the last working
> to done time.

Org doesn't have a built-in feature to turn on/off the clock when you change 
state, as far as I know. But it has the opposite - you can change state when 
you clock in or out of a task.

See section 7 here 
https://writequit.org/denver-emacs/presentations/2017-04-11-time-clocking-with-org.html#helpful-things

And/or maybe thread here w/ some code 
https://lists.gnu.org/archive/html/emacs-orgmode//2009-04/msg00315.html

So perhaps you can achieve this by changing your workflow a bit. Instead of 
changing state, just clock in and have the state set to INPROGRESS. Clock otu 
and have it set to WAITING. When it is done, it may be a two-step process of 
setting to DONE and making sure the clock is stopped.

Would this achieve what you're looking for?

  -k.

Re: [O] Tracking time from one state to another?

[Malcolm Matalka]

Marcin Borkowski  writes:

> On 2019-04-18, at 17:34, Malcolm Matalka  wrote:
>
>> Marcin Borkowski  writes:
>>
>>> On 2019-04-17, at 14:20, Malcolm Matalka  wrote:
>>>
 Hello,

 Is it possible in org-mode to track, and report, the duration of certain
 state transitions in org-mode?  In particular, I'm interested in
 tracking how long it takes me to go from a state that means I'm actively
 working on an item to it being in a done state?

 In my case, an item might go from working, to waiting, to working, to
 done.  And in this case I'm only really interested in the last working
 to done time.

 For my case, I'm looking to do a weekly report on how long it takes me
 to complete tasks that I have said I will work on.
>>>
>>> Hi Malcolm,
>>>
>>> that sounds interesting.  Since you can turn on logging of state changes
>>> (as you probably know), this is in principle possible, though I don't
>>> think it is built in.
>>>
>>> I guess writing a bit of Elisp to accomplish this should not be very
>>> difficult, though it seems that currently the problem is a bit
>>> underspecified.  If you could elaborate, e.g., provide an example of
>>> your state change log and describe the result you would like to get,
>>> I could be tempted to coding this.
>>>
>>> Best,
>>
>> Sure!
>>
>> So for my use case, I'm mostly interested in the last transition to a
>> finished state, but for simplicity I'll specify the two states I'm
>> interested in:
>>
>> Given states NEXT and DONE, I want to know the time between going into
>> NEXT and over to DONE.
>>
>> For example, given the following logbook:
>>
>>:LOGBOOK:
>>- State "DONE"   from "NEXT"   [2019-04-01 Mon 11:07]
>>- State "NEXT"   from "TODO"   [2019-04-01 Mon 10:35]
>>- State "NEXT"   from "TODO"   [2018-07-02 Mon 11:03]
>>:END:
>>
>>
>> This item would be 32 minutes.
>>
>> This one:
>>
>>:LOGBOOK:
>>- State "DONE"   from "NEXT"   [2019-04-10 Wed 09:56]
>>- State "NEXT"   from "WAITING"[2019-04-10 Wed 09:40]
>>- State "WAITING"from "NEXT"   [2019-04-09 Tue 10:44]
>>- State "NEXT"   from "WAITING"[2019-04-09 Tue 10:10]
>>- State "WAITING"from "NEXT"   [2019-04-08 Mon 16:39]
>>- State "NEXT"   from "TODO"   [2019-04-08 Mon 11:14]
>>:END:
>>
>>
>> Would be 16 minutes.
>
> Are those :LOGBOOK: drawers real?  They are not sorted chronologically,
> as they probably should be (though I'm not sure, I don't se them
> much).

Yes they are real.  I'm not tracking going into a TODO state which is
hwy the first one looks funny.  And they are sorted chronologically, but
in reverse order, so top is most recent.

>
>> I'd like to specify what time range to do this for, and be able to sort
>> by duration.
>>
>> I think a dynamic block, like clocktable, would probably be a fine.
>>
>> Any idea what the level of work involved is to accomplish this?  I'm
>> guessing a very hacky version might be to modify clock table and look at
>> the logbook instead of clock and filter out all but the last transition?
>
> I don't think that's the best way - Org-mode code is famously
> complicated, it might be easier to do it from scratch (it'd be perhaps
> less general then, though).
>
> Anyway, it doesn't look like a lot of work - an hour or two for a rough
> prototype might be enough.

Is this something you're interested in doing?  If not if you have a
pointers I can try to take a poke at it.  My elisp skills are very-much
lacking but some progress is better than no progress.

>
>> Also, this is just the usecase I'm interested in, so if you have
>> thoughts on what a more general form would look like, that would be 
>> interested.
>
> No idea yet.
>
> Best,

[O] table --> org-drill

[Matt Price]

Hello everyone,

I'm taking an informal but intensive Nepali language class. There's no
textbook, and vocabulary comes rapidly from the teacher during lcass.  I
end up with notes that look like this:

 yo & tyo-based constructions

*yo*
| yatti  | this much  |
| katti  | how much   |
| yaha   | this place |
| kaahaa | where  |
| yasto  ||
| kasto  | how|
| yasari ||
| kasari ||

*tyo* and *u*

similar, but over there.  nearly synonymous is "u", which in principle is
reserved for persons, but is used for both. "u" can also be in between yo
and two, between this and that.

- u kosto manche ho? ::  what kind of person is he?
- u kosto manche ho? :: u asal manche ho

-
So there are two types of notes here --
- vocabulary in a 2-column table (sometimes there is a third or fourth
table, with devenagri and a note of some kind, ubt thosse have been rare)
- example sentences in definition lists -- sometimes they are nepali -->
english, and osmetimes question --> answer

I would like ot convert both these types of construction to flashcards
using org-drill, but doing so by hand would be prohibitively
time-consuming.  Has anyone already written some code to doe these kinds of
ocnversions? My head is so scrambled fro mthis ocurse that it's hard for me
to think in lisp...

THank you!

Matt
I would like to convert

Re: [O] [PATCH] Feature proposal : support "scale=" includegraphics option in the builtin latex exporter.

[Emmanuel Charpentier]

Possible duplicate answer (my email provider isn't very reliable at the
moment...).

Le lundi 22 avril 2019 à 14:04 +0200, Nicolas Goaziou a écrit :
> Hello,
> 
> Emmanuel Charpentier  writes:
> 
> > Attached is my proposal for the feature I suggested. My quick tests
> > pass[1]. Better tests by someone knowledgeable in graphics would
> > be 
> > useful, as well as a test in the test suite.
> 
> Applied, with some slight fixes.

Thank you !

> Could you provide an entry in ORG-NEWS?

Do you want some free text or a patch against etc/ORG-NEWS ?

--
Emmanuel Charpentier

Re: [O] [PATCH] Feature proposal : support "scale=" includegraphics option in the builtin latex exporter.

[Nicolas Goaziou]

Hello,

Emmanuel Charpentier  writes:

> Attached is my proposal for the feature I suggested. My quick tests
> pass[1]. Better tests by someone knowledgeable in graphics would be 
> useful, as well as a test in the test suite.

Applied, with some slight fixes.

Could you provide an entry in ORG-NEWS?

Thank you.

Regards,

-- 
Nicolas Goaziou

[O] source-block 'uncomment-region' comments out a second time

[Daniel Herzig]

Hi all!

I found a minor problem when editing source code blocks. I am on
Org-Mode 8.2.10 that comes with Emacs 25.1.1 on Debian.

My source code block looks something like:

#+BEGIN_SRC sh :shebang abc :tangle xyz
do this
do that
and that
#+END_SRC

If I enter the block with C-c ' and comment out a region like:

do this
do that

with M-x comment-region, everything works as expected, i.e.:

# do this
# do that

From outside the source-code editor it looks like this now (indentation 
ignored):

#+BEGIN_SRC sh :shebang abc :tangle xyz
# do this
# do that
and that
#+END_SRC

Sometimes I like to make changes to the code without entering the block
with C-c ' -- but if I mark:

# do this
# do that

from outside and hit M-x uncomment-region, my source-code block turns
into this:

#+BEGIN_SRC sh :shebang abc :tangle xyz
# # do this
# # do that
and that
#+END_SRC

I just tried -- it does not make a difference which command I use on the
region (comment-region or uncomment-region) from outside, it will
comment out as often as I use one of them (IF I just tried 3 levels). Inside 
the C-c ' environment
everything is top and working as expected.

It's clear that this kind of workflow is not intended, and I usually
work inside C-c ' for obvious reasions.  I just pointing at it, as in
this case 'comment-region' and 'uncomment-region' seem to do the same,
which is somewhat unexpected.

Best regards,
Daniel

[O] [Proposal] Source Blocks with Post-Extensions

[Dmitrii Korobeinikov]

For your convenience, I have attached this e-mail as an org-mode file.

When I write several source blocks, which depend on one another, I tend to
debug them one by one.

So, I write this function and test it:

#+NAME: square
#+BEGIN_SRC python
square = lambda x: x * x
return square(5)
#+END_SRC

#+RESULTS: square
: 25

After I see that the test is successful, I write this client function:

#+BEGIN_SRC python :noweb yes
<>
return 5 + square(5)
#+END_SRC

#+RESULTS:
: 25

And here, to get the correct result, I have to remove the ~return
square(5)~ line in ~<>~.
But I don't want to lose testing!
So I find nothing better to do than to seperate the source block:

#+NAME: square-1
#+BEGIN_SRC python
square = lambda x: x * x
#+END_SRC

And, by the way, there was no error/warning that I have just redefined
~<>~,
so, for the test-snippet below to work, I renamed it to ~<>~.
I think the org-mode team is aware of it, but anyway:

- [ ] no error checking of the description of a code block.

#+NAME: square-1-tester
#+BEGIN_SRC python :noweb yes
  <>
  return square(5)
#+END_SRC

#+RESULTS: square-1-tester
: 25

- [ ] For every such source block used for testing purposes, you have to
repeat the inclusion statement and part of the name, which is cumbersome.

A fair solution is maybe to extend the block like this:

#+NAME: square-1
#+BEGIN_SRC python
  square = lambda x: x * x
#+END_SRC
  return square(5)
#+END_SRC_TEST

When I call this individually, the test part would run, but when I :noweb
it in another block, the test part would be ommited.

As an extension of this idea, it could be useful to have several test
attachments like this, each producing its own result. Maybe, the TEST part
could as well be ommited. Custom names are also an option:

#+NAME: square-multiple
#+BEGIN_SRC python
  square = lambda x: x * x
#+END_SRC
  return square(5)
#+END_SRC NAME: ext_1
  return square(10)
#+END_SRC NAME: ext_2

#+RESULTS: square-multiple-ext-1
: 25

#+RESULTS: square-multiple-ext-2
: 100

Overall, these techniques should reduce noise and increase usability.


org-test-suite.org
Description: Binary data