Re: [O] org-crypt broken on Ubuntu 18.04

2018-06-19 Thread Óscar Fuentes
Óscar Fuentes  writes:

> Hello.
>
> Today I noticed that org-crypt is broken on my daily driver.
>
> On a header with the :crypt: tag I invoke org-decrypt-entry, a popup
> dialog asks for the password, I type the password and then the
> minibuffer shows
>
> GPG error: "Decryption failed", ""
>
> The complete error message on *Messages* is
>
> epg--check-error-for-decrypt: GPG error: "Decryption failed", ""
>
> This is a very recent problem. In dpkg.log I see:
>
> 2018-06-12 00:33:00 upgrade gnupg-utils:amd64 2.2.4-1ubuntu1 2.2.4-1ubuntu1.1
>
> 2018-06-12 00:33:05 upgrade gnupg:amd64 2.2.4-1ubuntu1 2.2.4-1ubuntu1.1
>
> I tried the latest org-mode (9.1.13) and Emacs from master branch but
> the problem persists.

Today I upgraded a Debian Testing machine which included gpg 2.2.8 and,
sure enough, now that machine also presents the same problem.

I'll try to debug the issue as soon as I have some spare time.




Re: [O] Bug: org-toggle-tag always marks buffer modified [9.1.13 (9.1.13-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180618/)]

2018-06-19 Thread Bernt Hansen
Hi Nicolas,

Please disregard this bug report.  I can't reproduce it anymore after an
Emacs restart.

Sorry for the noise.

Regards,
Bernt

Bernt Hansen  writes:

> Hi Nicholas,
>
> This fix breaks my capture templates.
>
> commit 593058e4a6270f52fdede2b871a0ee6504944f13
> Author: Nicolas Goaziou 
> Date:   Tue Jun 19 09:40:00 2018 +0200



Re: [O] Agenda search: setting sort-order

2018-06-19 Thread Nicolas Goaziou
Hello,

Nathan Neff  writes:

> I had a look at org-agenda.el, and took a first stab at "coding" :)
> I fixed the sorting problem when using agenda-search-view, and
> I have a DIFF/patch at the bottom of this e-mail [1] that provided the fix.
>
> Would this be of interest to the org-mode project?

IMO, the Org mode project is interested in having its bugs fixed ;)

> This code fixes the
> problem,
> but it is duplicated in the function org-agenda-get-todos, and seems
> redundant,
> therefore a more "long term" fix would probably not resemble the minor patch
> below.  Also, I have no experience with lisp, nor the org-mode
> codebase :-O

A more "long term" fix would be to rewrite the agenda (asynchronous,
more scalable, better API for external use).

> Here's steps I used to find the problem.  Feel free to skip to [1]
> for the DIFF/patch.

Would you mind sending it using `git format-patch'?

Thank you.

Regards,

-- 
Nicolas Goaziou



Re: [O] In org-mode 9 "Scheduled" and "Deadline" are no longer parsed if they are not in the beginning

2018-06-19 Thread Igor Katson
Hi, Ken, Nicolas,

thanks for prompt answers, I used org-lint to find all those cases, and
although it took a while, it totally helped!

On Tue, Jun 19, 2018 at 11:13 AM Ken Mankoff  wrote:

> Org-lint can help find and repair this for you (I think).
>
> Please excuse brevity. Sent from tiny pocket computer with non-haptic
> feedback keyboard.
>
> > On 19 Jun 2018, at 16.37, Igor Katson  wrote:
> >
> > Hi,
> >
> > first of all, thanks for the best productivity tool that I know of!
> >
> > I've been using org-mode for years, and somewhere between version 8 and
> 9, a change happened, which I could not find in the changelogs.
> >
> > Here's how I often used to format TODO items which are scheduled:
> >
> > * TODO Item
> > some-text
> > some-more-text
> >SCHEDULED: <2018-06-19 Tue>
> >
> > In the newer versions of org, the SCHEDULED string is no longer parsed,
> and I don't see it in agenda, unless I reformat it like this:
> >
> > * TODO Item
> > SCHEDULED: <2018-06-19 Tue>
> > some-text
> > some-more-text
> >
> > This broke the habit that I was using for years and also broke my
> existing notes as I'm no longer able to see them in agenda. I wonder if
> this behavior can be changed to work like before.
> >
> > Thanks!
> >
> >
>


Re: [O] point moves and zoom level reverts when refreshing agenda

2018-06-19 Thread Nicolas Goaziou
Hello,

Marco Wahl  writes:

> Hopefully Nicolas and Bastien see it the same way.

Thank you. It looks good. Feel free to apply it.

I have two suggestions however:

1. There is some code duplication, e.g., (dolist ...), could this be
   factored out before applying the patch?

2. Would it make sense to add the variables to preserve in a dedicated
   top-level variable instead of burying them in the code?


Regards,

-- 
Nicolas Goaziou



Re: [O] In org-mode 9 "Scheduled" and "Deadline" are no longer parsed if they are not in the beginning

2018-06-19 Thread Ken Mankoff
Org-lint can help find and repair this for you (I think). 

Please excuse brevity. Sent from tiny pocket computer with non-haptic feedback 
keyboard. 

> On 19 Jun 2018, at 16.37, Igor Katson  wrote:
> 
> Hi,
> 
> first of all, thanks for the best productivity tool that I know of!
> 
> I've been using org-mode for years, and somewhere between version 8 and 9, a 
> change happened, which I could not find in the changelogs.
> 
> Here's how I often used to format TODO items which are scheduled:
> 
> * TODO Item
> some-text
> some-more-text
>SCHEDULED: <2018-06-19 Tue>
> 
> In the newer versions of org, the SCHEDULED string is no longer parsed, and I 
> don't see it in agenda, unless I reformat it like this:
> 
> * TODO Item
> SCHEDULED: <2018-06-19 Tue>
> some-text
> some-more-text
>
> This broke the habit that I was using for years and also broke my existing 
> notes as I'm no longer able to see them in agenda. I wonder if this behavior 
> can be changed to work like before.
> 
> Thanks!
> 
> 



[O] very long table calc expressions ?

2018-06-19 Thread Uwe Brauer



Hi

Take the following example 


#+TBLNAME: data
 | Name | Cual 1 |
 |--+|
 | A| NT |
 | B| NT |
 | C| MH |
 | D| AP |
 | E| MH |
 | F| SS |
 | G| NP |
 | H| NP |
 | I| NP |
 |  | NT |
 |  | AP |
 |  | AP |
 |  | AP |
 |  | AP |
 |  | SB |


#+TBLNAME: stat-final2
|| Frequency |
|+---|
| SS | 1 |
| AP | 5 |
| NT | 3 |
| SB | 1 |
| MH | 2 |
| NP | 3 |
#+TBLFM: @>$2='(length (org-lookup-all "NP" '(remote(data,@2$2..@>I$2)) 
nil))::@>>$2='(length (org-lookup-all "MH" '(remote(data,@2$2..@>I$2)) 
nil))::@>>>$2='(length (org-lookup-all "SB" '(remote(data,@2$2..@>I$2)) 
nil))::@$2='(length (org-lookup-all "NT" '(remote(data,@2$2..@>I$2)) 
nil))::@>$2='(length (org-lookup-all "AP" '(remote(data,@2$2..@>I$2)) 
nil))::@>>$2='(length (org-lookup-all "SS" '(remote(data,@2$2..@>I$2)) nil))


Are there any rules to break this very long expression?

Thanks

Uwe Brauer 




Re: [O] problem with frequency table if it contains strings.

2018-06-19 Thread Uwe Brauer
>>> "Uwe" == Uwe Brauer  writes:


   > || lower bound | upper bound | frequency |
   > |+-+-+---|
   > | SS |   0 | 4.9 | 8 |
   > | AP |   5 | 6.9 | 2 |
   > | NT |   7 | 8.9 | 2 |
   > | SB |   9 |  10 | 1 |

   > #+TBLFM: $4='(length (org-lookup-all '($2 $3) 
'(remote(raw-data,@2$1..@>$1)) nil 'in-interval));N


It is the evil N option, but I don't see how to substitute it.

Any ideas?

Uwe Brauer 


smime.p7s
Description: S/MIME cryptographic signature


Re: [O] Bug: Inconsistent effort handling in clock totals in maint [9.1.13 (release_9.1.13 @ /home/bernt/git/org-mode/lisp/)]

2018-06-19 Thread Bernt Hansen
Nicolas Goaziou  writes:

> Bernt Hansen  writes:
>
>> Nicolas Goaziou  writes:
>
>>> We shot ourselves in the foot when we decided that one part of Org
>>> should consider plain numbers as minutes and the other part as hours.
>>> This is clearly sub-optimal.
>>>
>>> I see no easy way to fix it painlessly. If we change anything, the
>>> easier route to go is having Column View mode consider plain numbers as
>>> minutes, because it only affects ... Column View mode itself.
>>>
>>
>> I'd like to change my vote :)
>> So Cancel the above request about touching the mode line code :)
>
> I applied the change above in "next" branch.

Great!  I will play with it when it gets to master. :)

Regards,
Bernt



[O] Bug: Regression - SPC in agenda does not show drawer details [version 9.1.13 (release_9.1.13-819-geb8743 @ c:/D-Drive/bin/org-mode/lisp/)]

2018-06-19 Thread Bernt Hansen
Hi,

The current master branch has a regression from maint when displaying
task details from the agenda using the SPC key.

I keep my task change details in drawers so when I change a task from
TODO to WAITING I record the details of why it is waiting in the
drawer.  In the maint branch I can hit SPC in the agenda  on a WAITING
task and see the details of what it is waiting for in the maint branch.
This no longer works in master.

ECM follows.

Thanks for org-mode!

Regards,
Bernt

ECM: 

--- test.org ---
#+FILETAGS: TEST
#+STARTUP: content

Regression - SPC in agenda does not show details in drawers

*Keys To Reproduce*

1) Add current file to org-agenda files
   C-c [

2) Show agenda
   C-c a t

3) Move to WAITING task
   C-4 C-n

4) Show task
   SPC

Results in maint branch

#+begin_example
,* WAITING Task two  :WAITING:
  :LOGBOOK:
  - State "WAITING"from "TODO"   [2018-06-19 Tue 10:47] \\
for something
  :END:
,* TODO Task three
#+end_example

Results in master branch

#+begin_example
  ,* WAITING Task two  :WAITING:
:LOGBOOK:...
  ,* TODO Task three

#+end_example

* TODO Task one
* WAITING Task two  :WAITING:
  :LOGBOOK:
  - State "WAITING"from "TODO"   [2018-06-19 Tue 10:47] \\
for something
  :END:
* TODO Task three

--- test.el 
(setq org-log-into-drawer t)

(setq org-todo-keywords
  (quote ((sequence "TODO(t/!)" "NEXT(n/!)" "|" "DONE(d/!)")
  (sequence "WAITING(w@/!)" "HOLD(h@/!)"  "|" "CANCELLED(c@/!)"

(setq org-todo-state-tags-triggers
  (quote (("CANCELLED" ("CANCELLED" . t) ("WAITING") ("HOLD"))
  ("WAITING" ("WAITING" . t))
  ("HOLD" ("WAITING") ("HOLD" . t))
  (done ("WAITING") ("HOLD"))
  ("TODO" ("WAITING") ("CANCELLED") ("HOLD"))
  ("NEXT" ("WAITING") ("CANCELLED") ("HOLD"))
  ("DONE" ("WAITING") ("CANCELLED") ("HOLD")

(setq org-todo-keyword-faces
  (quote (("TODO" :foreground "red" :weight bold)
  ("NEXT" :foreground "blue" :weight bold)
  ("DONE" :foreground "forest green" :weight bold)
  ("WAITING" :foreground "orange" :weight bold)
  ("HOLD" :foreground "magenta" :weight bold)
  ("CANCELLED" :foreground "forest green" :weight bold







Emacs  : GNU Emacs 25.1.1 (x86_64-w64-mingw32) of 2016-09-17
Package: Org mode version 9.1.13 (release_9.1.13-819-geb8743 @ 
c:/D-Drive/bin/org-mode/lisp/)




Re: [O] In org-mode 9 "Scheduled" and "Deadline" are no longer parsed if they are not in the beginning

2018-06-19 Thread Nicolas Goaziou
Hello,

Igor Katson  writes:

> I've been using org-mode for years, and somewhere between version 8 and 9,
> a change happened, which I could not find in the changelogs.
>
> Here's how I often used to format TODO items which are scheduled:
>
> * TODO Item
> some-text
> some-more-text
>SCHEDULED: <2018-06-19 Tue>
>
> In the newer versions of org, the SCHEDULED string is no longer parsed, and
> I don't see it in agenda, unless I reformat it like this:
>
> * TODO Item
> SCHEDULED: <2018-06-19 Tue>
> some-text
> some-more-text
>
> This broke the habit that I was using for years and also broke my existing
> notes as I'm no longer able to see them in agenda. I wonder if this
> behavior can be changed to work like before.

No it cannot. SCHEDULED and DEADLINE must be in the line right below the
heading. M-x org-lint will help you finding problematic lines.

Not this is not really a change: most code in Org expected such lines to
be located right below the heading since day 1. The agenda was a bit
tolerant on that part. This is particularly important to make Org find
information quickly.

Regards,

-- 
Nicolas Goaziou



Re: [O] org-capture: Avoid inserting a new line when the template is empty

2018-06-19 Thread Nicolas Goaziou
Hello,

xristos  writes:

> An example of a capture workflow that I am using all the time
> is the following:
>
> ("bbp" "Preview book" plain
>  (file+function "~/org/books.org.gpg" 
> xristos/org-capture-preview-find-location)
>   "" :immediate-finish t :jump-to-captured t :empty-lines 0)
>
> The idea is that the function I provide is fully responsible for cursor 
> positioning
> and entry manipulation. To that end, I pass an empty template ("") and
> set :immediate-finish to t. This has been working fine with an older Org
> version but since I recently updated to Org 9.1.13, org-capture-fill-template 
> will
> insert a new line every single time which is not what I want to happen.
>
> The relevant code is at org-capture.el, line 1843. I think that having a way
> to tell Org not to change the user-provided template at all and just use
> it verbatim would be useful in the general sense.
>
> For my own needs, I've added an extra property (:verbatim-template) which I
> check for inside org-capture-fill-template:
>
> @@ -1840,7 +1840,8 @@ The template may still contain \"%?\" for cursor 
> positioning."
>(goto-char (point-max))
>(skip-chars-backward " \t\n")
>(delete-region (point) (point-max))
> -  (insert "\n")
> +  (unless (org-capture-get :verbatim-template)
> + (insert "\n"))

IMO, :verbatim-template is not generally useful. In any case, I pushed
a fix in master. Does it fix your issue?

Regards,

-- 
Nicolas Goaziou



[O] In org-mode 9 "Scheduled" and "Deadline" are no longer parsed if they are not in the beginning

2018-06-19 Thread Igor Katson
Hi,

first of all, thanks for the best productivity tool that I know of!

I've been using org-mode for years, and somewhere between version 8 and 9,
a change happened, which I could not find in the changelogs.

Here's how I often used to format TODO items which are scheduled:

* TODO Item
some-text
some-more-text
   SCHEDULED: <2018-06-19 Tue>

In the newer versions of org, the SCHEDULED string is no longer parsed, and
I don't see it in agenda, unless I reformat it like this:

* TODO Item
SCHEDULED: <2018-06-19 Tue>
some-text
some-more-text

This broke the habit that I was using for years and also broke my existing
notes as I'm no longer able to see them in agenda. I wonder if this
behavior can be changed to work like before.

Thanks!


Re: [O] Bug: Inconsistent effort handling in clock totals in maint [9.1.13 (release_9.1.13 @ /home/bernt/git/org-mode/lisp/)]

2018-06-19 Thread Nicolas Goaziou
Hello

Bernt Hansen  writes:

> Nicolas Goaziou  writes:

>> We shot ourselves in the foot when we decided that one part of Org
>> should consider plain numbers as minutes and the other part as hours.
>> This is clearly sub-optimal.
>>
>> I see no easy way to fix it painlessly. If we change anything, the
>> easier route to go is having Column View mode consider plain numbers as
>> minutes, because it only affects ... Column View mode itself.
>>
>
> I'd like to change my vote :)
> So Cancel the above request about touching the mode line code :)

I applied the change above in "next" branch.

Regards,

-- 
Nicolas Goaziou



Re: [O] Bug: org-toggle-tag always marks buffer modified [9.1.13 (9.1.13-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180618/)]

2018-06-19 Thread Bernt Hansen
Nicolas Goaziou  writes:

> Allen Li  writes:
>
>> org-toggle-tag always marks the buffer as modified due to how it is
>> implemented.  It would be better if it did not mark the buffer
>> modified if it does not change anything.  This is annoying for
>> org-depend.el (which is contrib, not officially supported) because the
>> org-blocker-hook set by org-depend.el will mark the buffer modified
>> whenever an agenda view is built/refreshed.
>
> Fixed. Thank you.

Hi Nicholas,

This fix breaks my capture templates.

commit 593058e4a6270f52fdede2b871a0ee6504944f13
Author: Nicolas Goaziou 
Date:   Tue Jun 19 09:40:00 2018 +0200

`org-set-tags' modifies buffer only when necessary

* lisp/org.el (org--align-tags-here):
(org-set-tags): Modify buffer only when necessary.

* testing/lisp/test-org.el (test-org/set-tags): Add tests.

Reported-by: Allen Li 




I have reverted it locally and it works again.

My normal TODO capture template doesn't allow SPC to separate words when
entering the new headline for the task.

The relevant capture template entry is

(setq org-capture-templates
  (quote (("t" "Todo" entry (file "C:/D-Drive/org/refile.org")
 "* TODO %?\n%U\n\n%x\n" :clock-in t :clock-resume t)
...

After opening the capture window and point is moved to the %? position I
type the headline but SPC no longer enters a space.  C-v SPC works but
that is inconvenient.

Thanks,
Bernt



Re: [O] Bug: Archiving creates multiple parent tasks in master [9.1.13 (release_9.1.13-787-g13a09b @ c:/D-Drive/bin/org-mode/lisp/)]

2018-06-19 Thread Bernt Hansen
Nicolas Goaziou  writes:

> Hello,
>
> Bernt Hansen  writes:
>
>> Archiving tasks using the master branch with the below configuration
>> creates duplicate "* Archived Tasks" heading each time you archive in
>> the test.org_archive file.
>
> Fixed. Thank you.
>
> Regards,

Confirmed.  Thanks you very much! :)

Regards,
Bernt



Re: [O] Bug: Archiving creates multiple parent tasks in master [9.1.13 (release_9.1.13-787-g13a09b @ c:/D-Drive/bin/org-mode/lisp/)]

2018-06-19 Thread Nicolas Goaziou
Hello,

Bernt Hansen  writes:

> Archiving tasks using the master branch with the below configuration
> creates duplicate "* Archived Tasks" heading each time you archive in
> the test.org_archive file.
>
> The behaviour in the maint branch is correct and files subsequently
> archived tasks under the single main heading.
>
> Thanks for org-mode!
>
> Regards,
> Bernt
>
> -- test.el -
> (setq org-archive-location "%s_archive::* Archived Tasks")
>
> -- test.org 
>
> #+FILETAGS: TEST
> #+STARTUP: content
>
>
> *Keys To Reproduce*
>
> 1) Move to next heading
>C-c C-n
>
> 2) Move to next heading
>C-c C-n
>
> 3) Archive heading
>C-c C-x C-a
>
> 4) Archive heading
>C-c C-x C-a
>
> Results in test.org_archive:
>
> maint branch produces (correct)
>
> #+BEGIN_EXAMPLE
> * Archived Tasks
> ** TODO do something
> ** TODO foo :BAR:
> #+END_EXAMPLE
>
>
> master branch produces (incorrect)
>
> #+BEGIN_EXAMPLE
> * Archived Tasks
> ** TODO do something
> * Archived Tasks
> ** TODO foo :BAR:
> #+END_EXAMPLE
>
> * TODO Test Parent  :PRODUCTION:MISC:
>   :PROPERTIES:
>   :EFFORT:   15:30
>   :END:
> ** TODO do something
>:PROPERTIES:
>:EFFORT:   15
>:END:
>:LOGBOOK:
>CLOCK: [2018-05-12 Sat 00:26]--[2018-05-12 Sat 00:26] =>  0:00
>CLOCK: [2018-05-12 Sat 00:23]--[2018-05-12 Sat 00:23] =>  0:00
>CLOCK: [2018-05-12 Sat 00:22]--[2018-05-12 Sat 00:22] =>  0:00
>CLOCK: [2018-05-12 Sat 00:22]--[2018-05-12 Sat 00:22] =>  0:00
>CLOCK: [2018-05-12 Sat 00:07]--[2018-05-12 Sat 00:08] =>  0:01
>CLOCK: [2018-05-12 Sat 00:00]--[2018-05-12 Sat 00:04] =>  0:04
>:END:
> ** TODO foo :BAR:
>:PROPERTIES:
>:EFFORT:   00:30
>:END:

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou



Re: [O] Patch adding from-logo commentary ox-koma-letter.el

2018-06-19 Thread Nicolas Goaziou
Hello,

Grant Rettke  writes:

> Although the function document ion mentions the markup to use, it
> doesn't explain that the user needs to provide a logo file in the same
> directory as the letter.

Is it really necessary? Couldn't you use, e.g., \includegraphics{subdir/logo}

regards,

-- 
Nicolas Goaziou



Re: [O] Bug: org-toggle-tag always marks buffer modified [9.1.13 (9.1.13-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180618/)]

2018-06-19 Thread Nicolas Goaziou
Hello,

Allen Li  writes:

> org-toggle-tag always marks the buffer as modified due to how it is
> implemented.  It would be better if it did not mark the buffer
> modified if it does not change anything.  This is annoying for
> org-depend.el (which is contrib, not officially supported) because the
> org-blocker-hook set by org-depend.el will mark the buffer modified
> whenever an agenda view is built/refreshed.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou



Re: [O] archiving in the same file always creates top-level headings

2018-06-19 Thread Nicolas Goaziou
Hello,

Hendrik Tews  writes:

> when I have this file
>
> === cut ===
> * A
> ** B
> ** C
> === cut ===
>
> and set org-archive-location to "::* Archived Tasks", as
> recommended in the documentation of this variable. Then, after
> doing C-c C-x C-a (org-archive-subtree-default) both on B and on
> C, I get
>
> === cut ===
> * A
> * Archived Tasks
>
> ** B...
>
> * Archived Tasks
>
> ** C...
> === cut ===
>
> while I would have expected
>
> === cut ===
> * A
> * Archived Tasks
> ** B...
> ** C...
> === cut ===
>
> (only one Archived Tasks heading).
>
> Is it really intended that org-archive-subtree-default inserts
> the heading, even if it does already exist?

No, it is a bug, already reported here:


Regards,

-- 
Nicolas Goaziou