Re: [O] Closing a task yesterday (or changing the day cutoff to 4am)

2019-02-01 Thread Marcin Borkowski


On 2019-02-02, at 01:29, Leo Gaspard  wrote:

> Hello!
>
> I have a few tasks marked as `:STYLE: habit`. And I relatively often
> finish one of those daily habits after midnight.
>
> Yet, I'd like to count it as having been finished the day before, so
> that day switch time happens while I sleep.
>
> I do understand that the best fix to this problem would be to fix my
> sleep schedule and to go to sleep before midnight, but, assuming I can't
> fix this up, do you know if there is a workaround to either:
>  * Make org-mode consider the day to switch at something like 4am
>  * Automatically close a task as though it was the day before, 23:59
>
> Currently my workaround is to close the task then manually fixup the
> `SCHEDULED`, `:LAST_REPEAT:` and `:LOGBOOK:` lines to set them to the
> day before, 23:59, but it's being… quite painful.

You do realize you are not the first one to have that problem, don't
you?  Have you seen `org-agenda-todo-yesterday'?

;-)

Notice, however, that IMHO this is only a dirty hack.  A real solution
to the same problem, as you have noticed, is something that
I implemented a few years ago, and that was a radical change of my
sleeping patterns.  Now I seldom go to bed after 22:30, and usually get
up before 5:30.  This has too many advantages to list them in a short
email. :-) (Of course, I am aware not everyone can pull this off, also
for objective reasons.  My sister is a nurse, for example.)

> Anyway, thank you for org-mode, that allows me to be mildly annoyed at
> things I wouldn't even have considered might become an issue someday
> with programs I used before!

Not sure whether this is a compliment, but I like it:-).

--
Marcin Borkowski
http://mbork.pl



[O] Closing a task yesterday (or changing the day cutoff to 4am)

2019-02-01 Thread Leo Gaspard
Hello!

I have a few tasks marked as `:STYLE: habit`. And I relatively often
finish one of those daily habits after midnight.

Yet, I'd like to count it as having been finished the day before, so
that day switch time happens while I sleep.

I do understand that the best fix to this problem would be to fix my
sleep schedule and to go to sleep before midnight, but, assuming I can't
fix this up, do you know if there is a workaround to either:
 * Make org-mode consider the day to switch at something like 4am
 * Automatically close a task as though it was the day before, 23:59

Currently my workaround is to close the task then manually fixup the
`SCHEDULED`, `:LAST_REPEAT:` and `:LOGBOOK:` lines to set them to the
day before, 23:59, but it's being… quite painful.

Anyway, thank you for org-mode, that allows me to be mildly annoyed at
things I wouldn't even have considered might become an issue someday
with programs I used before!

Cheers,
  Leo



Re: [O] Bug: org-map-drill-entries fails in org-tags-expand on empty string

2019-02-01 Thread Stig Brautaset
Robert Irelan  writes:

> Patch to fix attached.

I can confirm that this patch is required to make `org-drill' work for me in 
Org 9.2

Regards,

Stig



> From a3af9004fbc5a8a86ba8f990d393403ec671f9bf Mon Sep 17 00:00:00 2001
> From: Robert Irelan 
> Date: Wed, 23 Jan 2019 11:11:14 -0800
> Subject: [PATCH] org-drill: Fix tag match in org-map-drill-entries
>
> * contrib/lisp/org-drill.el: Change MATCH argument to ORG-MAP-ENTRIES
> from "" to nil.
>
> Without this, org-tags-expand will throw an error on the empty string.
> ---
>  contrib/lisp/org-drill.el | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/lisp/org-drill.el b/contrib/lisp/org-drill.el
> index c7f509bff..895003395 100644
> --- a/contrib/lisp/org-drill.el
> +++ b/contrib/lisp/org-drill.el
> @@ -1483,10 +1483,10 @@ the current topic."
>   (when (and (not (org-invisible-p))
>  (> (org-current-level) drill-entry-level))
> (when (or (/= (org-current-level) (1+ drill-entry-level))
> -(funcall test))
> + (funcall test))
>   (hide-subtree))
> (push (point) drill-sections)))
> -   "" 'tree))
> +   nil 'tree))
>  (reverse drill-sections)))



Re: [O] Bug: org-map-drill-entries fails in org-tags-expand on empty string

2019-02-01 Thread Robert Irelan
Hi, could someone take a look at this? Other people have noticed this
issue: https://lists.gnu.org/archive/html/emacs-orgmode/2019-01/msg00096.html

On Wed, Jan 23, 2019 at 11:18 AM Robert Irelan  wrote:
>
> Patch to fix attached.



-- 
Robert Irelan
rire...@gmail.com



Re: [O] Bug: src code blocks of type compilation-minor don't work when generating PDF [9.1.14 (9.1.14-dist @ /path/to/org/install/emacs/site-lisp/org/)]

2019-02-01 Thread Nick Dokos
John Ciolfi  writes:

> Hi
>
> Using following
>
>   emacs -q --batch -L /path/to/org/install/emacs/site-lisp/org -l 
> my-org-to-pdf.el
>
> the generated PDF is incorrect. The "compilation-minor" code block gets
> replaced with the "c" code block, i.e. the c code block is
> duplicated. If you generate HTML all is good. Running org-lint doesn't
> indicate that one cannot use compilation-minor code blocks.

Hi John,

Given that the produced foo.tex file looks correct, it seems that
since minted does not know what to do with the "compilation-minor"
"language", it goes off a cliff. If you compile it by hand:

   pdflatex --shell-escape foo.tex

it produces an error message:

,
| (./foo.out.pyg) (./foo.out.pyg) (./foo.toc) (./foo.out.pyg)Error: no
| lexer for alias 'compilation-minor' found system returned with code
| 256 (./foo.out.pyg)
`

but since it produces a (wrong) PDF, the org exporter does not dig any further.

Changing the language to "c" in the tex file (or in the
source block before re-exporting) produces something a bit better.
Ideally, you'd need to define a lexer for the "compilation-minor" "language",
but that's a minted/pygments project.

Not sure whether it's worth doing anything about this on the org mode side,
but that's not my call.

HTH.

PS. Constantine says "Hi" :-)

-- 
Nick

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




[O] Bug: src code blocks of type compilation-minor don't work when generating PDF [9.1.14 (9.1.14-dist @ /path/to/org/install/emacs/site-lisp/org/)]

2019-02-01 Thread John Ciolfi


Hi

Using following

  emacs -q --batch -L /path/to/org/install/emacs/site-lisp/org -l 
my-org-to-pdf.el

the generated PDF is incorrect. The "compilation-minor" code block gets
replaced with the "c" code block, i.e. the c code block is
duplicated. If you generate HTML all is good. Running org-lint doesn't
indicate that one cannot use compilation-minor code blocks.

I'm using Emacs 25.1.1 with the released version of org-mode
9.1.14. It would be nice if this was supported. Alternatively, if
compilation-minor (or compilation) code blocks are not supported could
and error be produced?

Thanks


--- my-org-to-pdf.el ---

(require 'org)
(require 'ox-latex)
(require 'ox-publish)

(defun my-org-to-pdf (org-file)
  "Convert current org-mode buffer to FILE.pdf"
  (find-file org-file)
  (if (not (eq major-mode 'org-mode))
  (error "%S current buffer is not an org file" org-file))
  (let ((org-latex-image-default-width "")
(org-latex-listings 'minted)
(org-latex-logfiles-extensions (remove "log" 
org-latex-logfiles-extensions))
(org-latex-packages-alist '(("cache=false" "minted")))
(org-latex-minted-options '(("xleftmargin" "1em")
("breaklines" "true")
("fontsize" "\\small")))
(org-latex-pdf-process
 '("pdflatex -shell-escape -interaction nonstopmode -output-directory 
%o %f"
   "pdflatex -shell-escape -interaction nonstopmode -output-directory 
%o %f"))
(pdf-file))
;; Color the hyper links, see
;; 
https://tex.stackexchange.com/questions/823/remove-ugly-borders-around-clickable-cross-references-and-hyperlinks
(add-to-list 'org-latex-default-packages-alist
 
'("colorlinks=true,linkcolor={red!50!black},citecolor={blue!50!black},urlcolor={blue!80!black}"
 "hyperref" nil))
(setq pdf-file (org-latex-export-to-pdf))
(set-buffer-modified-p nil)
(message "Created %S" pdf-file)))

(my-org-to-pdf "foo.org")


--- foo.org ---

#+STARTUP: showall

#+BEGIN_SRC c
double foo(double u) {
int k;

int u2 = u + k;

int u3 = u;

return(u2 * 2.0);
}
#+END_SRC


#+BEGIN_SRC compilation-minor
foo.c: In function ‘foo’:
foo.c:6:9: warning: unused variable ‘u3’ [-Wunused-variable]
 int u3 = u;
 ^~
foo.c:4:16: warning: ‘k’ is used uninitialized in this function 
[-Wuninitialized]
 int u2 = u + k;
  ~~^~~
#+END_SRC

<#part type="application/emacs-lisp" 
filename="/mathworks/devel/sandbox/ciolfi/projects/org_mode/issues/src_block_compilation_minor/my-org-to-pdf.el"
 disposition=attachment>
<#/part>

<#part type="text/x-org" 
filename="/mathworks/devel/sandbox/ciolfi/projects/org_mode/issues/src_block_compilation_minor/foo.org"
 disposition=inline>
<#/part>

<#part type="application/pdf" 
filename="/mathworks/devel/sandbox/ciolfi/projects/org_mode/issues/src_block_compilation_minor/foo.pdf"
 disposition=attachment>
<#/part>




Emacs  : GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2017-09-15, modified by Debian
Package: Org mode version 9.1.14 (9.1.14-dist @ 
/path/to/org/install/emacs/site-lisp/org/)

current state:
==
(setq
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-shell-link-function 'yes-or-no-p
 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-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-block-all append
local]
   5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all
append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("id" :follow org-id-open)
   ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store org-mhe-store-link)
   ("irc" :follow org-irc-visit :store 

Re: [O] org-today broken

2019-02-01 Thread Marcin Borkowski


On 2019-02-01, at 13:55, Marco Wahl  wrote:

> Kyle Meyer  writes:
>
>> Samuel Wales  writes:
>>
>>> recent versions of maint and probably master have nil instead of
>>> current time in org-today.
>>>
>>> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>>>   time-subtract(nil (0 0 0))
>>>   org-today()
>>>   (message "org today is %s" (org-today))
>>
>> Thanks for the report.  I introduced this and a handful of other related
>> incompatibilities with my port of Emacs's c75f505de.  I've reverted the
>> problematic spots.
>
> Thanks for the revert!
>
> Occasionally I like to bend time to see what the agenda would look like
> if another day was current.  This can be achieved conveniently when
> solely function "current-time" is the source for the current time.
>
> So I'm all for using the explicit calls to current-time instead of using
> alternatve sources for the current time.

You are aware that datefudge exists, aren't you?

http://manpages.ubuntu.com/manpages/trusty/man1/datefudge.1.html

My 2 cents,

-- 
Marcin Borkowski
http://mbork.pl



Re: [O] org-today broken

2019-02-01 Thread Marco Wahl
Kyle Meyer  writes:

> Samuel Wales  writes:
>
>> recent versions of maint and probably master have nil instead of
>> current time in org-today.
>>
>> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>>   time-subtract(nil (0 0 0))
>>   org-today()
>>   (message "org today is %s" (org-today))
>
> Thanks for the report.  I introduced this and a handful of other related
> incompatibilities with my port of Emacs's c75f505de.  I've reverted the
> problematic spots.

Thanks for the revert!

Occasionally I like to bend time to see what the agenda would look like
if another day was current.  This can be achieved conveniently when
solely function "current-time" is the source for the current time.

So I'm all for using the explicit calls to current-time instead of using
alternatve sources for the current time.


My 2ct,  Marco



[O] org-icalendar: Change dates to today in VEVENT export

2019-02-01 Thread Michaël Cadilhac
Hi there yall;

I use org-icalendar to export my TODOs and events to an ics, that is then
imported in Google Calendar.  As far as I can see, Google Calendar still
doesn't support VTODOs, so only the VEVENTs are relevant.  *My goal is to
have my day on Google Calendar looks like my Org Agenda; *in particular
this means:

1.   I want my repeats to appear today.

To do this, I have to artificially bump the timestamp of the VEVENTs that
correspond to a not-DONE TODO to today (and maybe add the "72x" indicating
that the TODO was scheduled 72 days ago).  How can I do that?

I believe this is not doable out of the box and that I'll have to
modify org-icalendar-entry; is that correct?

2.   I want my DEADLINEs to show up `org-deadline-warning-days` days before
in the export.

Again this means that I have to artificially change the date of the VEVENT
(and maybe add the "in 6d.").  How can I do that?

Thanks very much!

Cheers;
M.


Re: [O] [PATCH] Add feature to org-drill to auto pronounce word

2019-02-01 Thread Stig Brautaset


stardiviner  writes:

[...]

> @@ -1486,7 +1521,7 @@ the current topic."
>  (funcall test))
>   (hide-subtree))
> (push (point) drill-sections)))
> -   "" 'tree))
> +   nil 'tree))
>  (reverse drill-sections)))

Could we have this part of the patch applied separately? org-drill on
Org 9.2 doesn't work for me without it. Other people have this problem
too, as I found a reference to this fix here:
https://emacs.stackexchange.com/a/46961/10625


Stig