Re: [BUG] org-clock-sum: Wrong type argument: fixnump, nil [9.7-pre (release_9.6.22-1309-g8507ef @ /home/grfz/src/org-mode/lisp/)]

2024-03-28 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2024-03-27; 12:00 GMT]:
> Gregor Zattler  writes:
>
>>> I'd like to see the problematic timestamp to understand what might be
>>> going on there.
>>
>>
>> thanks for your instructions, I edited it a bit:
>>
>> "- SxII VPN vxx USB S ()
>>  CLOCK: [2012-02-02 Do 14:00]--[2012-02-02 Do 16:00] =>  2:00
>>  - SxII; Rxx kx, n xx
>>  Clock: [2012-02-01 Mi 17:34]--[2012-02-01 Mi 18:24] =>  0:50
>
> The parser had inconsistent handling of case-sensitivity in "CLOCK:"
> keyword. Now, fixed - it should be case-insensitive.

I did not realize this glitch --although I stumbled
upon such one before.

> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3f20e32f8

Thanks so much.  I confirm it works now with my file
(after finding another glitch).

Ciao, gregor



Re: [BUG] org-clock-sum: Wrong type argument: fixnump, nil [9.7-pre (release_9.6.22-1309-g8507ef @ /home/grfz/src/org-mode/lisp/)]

2024-03-26 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2024-03-26; 10:27 GMT]:
> Gregor Zattler  writes:
>
>> In the file.org_archive, with point on a clock line:
>>
>> Debugger entered--Lisp error: (wrong-type-argument fixnump nil)
>>   encode-time((0 nil nil nil nil nil nil -1 nil))
>>   (float-time (encode-time (list 0 (org-element--property :minute-start 
>> timestamp nil nil) (org-element--property :hour-start timestamp nil nil) 
>> (org-element--property :day-start timestamp nil nil) (org-element--property 
>> :month-start timestamp nil nil) (org-element--property :year-start timestamp 
>> nil nil) nil -1 nil)))
>
> This is helpful. You have some very strange timestamp.
> May you, when the backtrace window is active, press
> e (buffer-substring-no-properties (line-beginning-position -2) 
> (line-end-position 3)) 
> It should display text around the problematic timestamp.
>
> I'd like to see the problematic timestamp to understand what might be
> going on there.


thanks for your instructions, I edited it a bit:

"   - SxII VPN vxx USB S ()
CLOCK: [2012-02-02 Do 14:00]--[2012-02-02 Do 16:00] =>  2:00
- SxII; Rxx kx, n xx
Clock: [2012-02-01 Mi 17:34]--[2012-02-01 Mi 18:24] =>  0:50
- Gxxx-... #NV -Fx a
CLOCK: [2012-02-01 Mi 17:04]--[2012-02-01 Mi 17:33] =>  0:29"


>> seems to be somewhat truncated.  Is there a way to get
>> it unabbreviated?
>
> Press "." (M-x backtrace-expand-ellipses)

this way I get:

Debugger entered--Lisp error: (wrong-type-argument fixnump nil)
  encode-time((0 nil nil nil nil nil nil -1 nil))
  (float-time (encode-time (list 0 (org-element--property :minute-start 
timestamp nil nil) (org-element--property :hour-start timestamp nil nil) 
(org-element--property :day-start timestamp nil nil) (org-element--property 
:month-start timestamp nil nil) (org-element--property :year-start timestamp 
nil nil) nil -1 nil)))
  (let* ((timestamp (org-element--property :value element nil nil)) (ts 
(float-time (encode-time (list 0 (org-element--property :minute-start timestamp 
nil nil) (org-element--property :hour-start timestamp nil nil) 
(org-element--property :day-start timestamp nil nil) (org-element--property 
:month-start timestamp nil nil) (org-element--property :year-start timestamp 
nil nil) nil -1 nil (te (float-time (encode-time (list 0 
(org-element--property :minute-end timestamp nil nil) (org-element--property 
:hour-end timestamp nil nil) (org-element--property :day-end timestamp nil nil) 
(org-element--property :month-end timestamp nil nil) (org-element--property 
:year-end timestamp nil nil) nil -1 nil (dt (- (if tend (min te tend) te) 
(if tstart (max ts tstart) ts (if (> dt 0) (progn (setq t1 (+ t1 (floor dt 
60))
  (cond ((and (eq element-type 'clock) (match-end 2)) (let* ((timestamp 
(org-element--property :value element nil nil)) (ts (float-time (encode-time 
(list 0 (org-element--property :minute-start timestamp nil nil) 
(org-element--property :hour-start timestamp nil nil) (org-element--property 
:day-start timestamp nil nil) (org-element--property :month-start timestamp nil 
nil) (org-element--property :year-start timestamp nil nil) nil -1 nil (te 
(float-time (encode-time (list 0 (org-element--property :minute-end timestamp 
nil nil) (org-element--property :hour-end timestamp nil nil) 
(org-element--property :day-end timestamp nil nil) (org-element--property 
:month-end timestamp nil nil) (org-element--property :year-end timestamp nil 
nil) nil -1 nil (dt (- (if tend (min te tend) te) (if tstart (max ts 
tstart) ts (if (> dt 0) (progn (setq t1 (+ t1 (floor dt 60))) 
((match-end 4) (setq t1 (+ t1 (string-to-number (match-string 5)) (* 60 
(string-to-number (match-string 4)) ((memq element-type '(headline 
inlinetask)) (if (and org-clock-report-include-clocking-task (eq 
(org-clocking-buffer) (current-buffer)) (eq (marker-position 
org-clock-hd-marker) (point)) tstart tend (>= (float-time org-clock-start-time) 
tstart) (<= (float-time org-clock-start-time) tend)) (progn (let ((time (floor 
(org-time-convert-to-integer (time-since org-clock-start-time)) 60))) (setq t1 
(+ t1 time) (let* ((headline-forced (get-text-property (point) 
:org-clock-force-headline-inclusion)) (headline-included (or (null 
headline-filter) (save-excursion (let ((saved-match-data (match-data))) 
(unwind-protect (progn (funcall headline-filter)) (set-match-data 
saved-match-data t))) (setq level (- (match-end 1) (match-beginning 1))) 
(if (>= level lmax) (progn (progn (setq ltimes (vconcat ltimes (make-vector 
lmax 0))) (setq lmax (* 2 lmax) (if (or (> t1 0) (> (aref ltimes level) 0)) 
(progn (if (or headline-included headline-forced) (progn (if headline-included 
(let* ((l 0) (--cl-var-- leve

Re: [BUG] org-clock-sum: Wrong type argument: fixnump, nil [9.7-pre (release_9.6.22-1309-g8507ef @ /home/grfz/src/org-mode/lisp/)]

2024-03-25 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2024-03-25; 18:20 GMT]:
> Gregor Zattler  writes:
>
>> I did
>>
>> rm -rf *; git checkout -f; make repro
>>
>> in ~/src/org-mode.  make repro is very quick.
>>
>> Then I tested again with the above mentioned clock
>> table frame and emacs command line invocation: Same
>> result.  No backtrace.
>>
>> Am I missing something?
>
> Looks like some caller is intercepting errors, demoting them to messages.
>
> What happens if you run M-: (org-clock-sum)  directly in the
> problematic buffer?

on the clock table frame?

0 (#o0, #x0, ?\C-@)

I don't know what that means.

In the file.org_archive, with point on a clock line:

Debugger entered--Lisp error: (wrong-type-argument fixnump nil)
  encode-time((0 nil nil nil nil nil nil -1 nil))
  (float-time (encode-time (list 0 (org-element--property :minute-start 
timestamp nil nil) (org-element--property :hour-start timestamp nil nil) 
(org-element--property :day-start timestamp nil nil) (org-element--property 
:month-start timestamp nil nil) (org-element--property :year-start timestamp 
nil nil) nil -1 nil)))
  (let* ((timestamp (org-element--property :value element nil nil)) (ts 
(float-time (encode-time (list 0 (org-element--property :minute-start timestamp 
nil nil) (org-element--property :hour-start timestamp nil nil) 
(org-element--property :day-start timestamp nil nil) (org-element--property 
:month-start timestamp nil nil) (org-element--property :year-start timestamp 
nil nil) nil -1 nil (te (float-time (encode-time (list 0 
(org-element--property :minute-end timestamp nil nil) (org-element--property 
:hour-end timestamp nil nil) (org-element--property :day-end timestamp nil nil) 
(org-element--property :month-end timestamp nil nil) (org-element--property 
:year-end timestamp nil nil) nil -1 nil (dt (- (if tend (min te tend) te) 
(if tstart (max ts tstart) ts (if (> dt 0) (progn (setq t1 (+ t1 (floor dt 
60))
  (cond ((and (eq element-type 'clock) (match-end 2)) (let* ((timestamp 
(org-element--property :value element nil nil)) (ts (float-time (encode-time 
(list 0 ... ... ... ... ... nil -1 nil (te (float-time (encode-time (list 0 
... ... ... ... ... nil -1 nil (dt (- (if tend (min te tend) te) (if tstart 
(max ts tstart) ts (if (> dt 0) (progn (setq t1 (+ t1 (floor dt 60))) 
((match-end 4) (setq t1 (+ t1 (string-to-number (match-string 5)) (* 60 
(string-to-number (match-string 4)) ((memq element-type '(headline 
inlinetask)) (if (and org-clock-report-include-clocking-task (eq 
(org-clocking-buffer) (current-buffer)) (eq (marker-position 
org-clock-hd-marker) (point)) tstart tend (>= (float-time org-clock-start-time) 
tstart) (<= (float-time org-clock-start-time) tend)) (progn (let ((time (floor 
... 60))) (setq t1 (+ t1 time) (let* ((headline-forced (get-text-property 
(point) :org-clock-force-headline-inclusion)) (headline-included (or (null 
headline-filter) (save-excursion (let ... ...) (setq level (- (match-end 1) 
(match-beginning 1))) (if (>= level lmax) (progn (progn (setq ltimes (vconcat 
ltimes ...)) (setq lmax (* 2 lmax) (if (or (> t1 0) (> (aref ltimes level) 
0)) (progn (if (or headline-included headline-forced) (progn (if 
headline-included ...) (setq time ...) (goto-char ...) (put-text-property ... 
... ... time) (if headline-filter ...))) (setq t1 0) (let* ((l level) 
(--cl-var-- ...)) (while (<= l --cl-var--) (aset ltimes l 0) (setq l ...)) 
nil))
  (let* ((element (let ((saved-match-data (match-data))) (unwind-protect (progn 
(org-element-at-point)) (set-match-data saved-match-data t (element-type 
(org-element-type element))) (cond ((and (eq element-type 'clock) (match-end 
2)) (let* ((timestamp (org-element--property :value element nil nil)) (ts 
(float-time (encode-time ...))) (te (float-time (encode-time ...))) (dt (- (if 
tend ... te) (if tstart ... ts (if (> dt 0) (progn (setq t1 (+ t1 ...)) 
((match-end 4) (setq t1 (+ t1 (string-to-number (match-string 5)) (* 60 
(string-to-number (match-string 4)) ((memq element-type '(headline 
inlinetask)) (if (and org-clock-report-include-clocking-task (eq 
(org-clocking-buffer) (current-buffer)) (eq (marker-position 
org-clock-hd-marker) (point)) tstart tend (>= (float-time org-clock-start-time) 
tstart) (<= (float-time org-clock-start-time) tend)) (progn (let ((time ...)) 
(setq t1 (+ t1 time) (let* ((headline-forced (get-text-property (point) 
:org-clock-force-headline-inclusion)) (headline-included (or (null 
headline-filter) (save-excursion ... (setq level (- (match-end 1) 
(match-beginning 1))) (if (>= level lmax) (progn (progn (setq ltimes ...) (setq 
lmax ... (if (or (> t1 0) (> (aref ltimes level) 0)) (progn (if (or 
headline-included headline-forced) (progn ... ... ... ... ...)) (setq t1 0) 
(let* (... ...) (while ... ... ...) nil)))
  (while (

Re: [BUG] org-clock-sum: Wrong type argument: fixnump, nil [9.7-pre (release_9.6.22-1309-g8507ef @ /home/grfz/src/org-mode/lisp/)]

2024-03-25 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2024-03-24; 13:27 GMT]:
> Gregor Zattler  writes:
>
>> with point on the following frame for a clock table:
>>
>> #+BEGIN: clocktable :scope ("/home/absolute/path/file.org_archive")
>> #+END:
>> ...
>> If instead I use a very fresh org-mode from main, specifically
>>
>> Org mode version 9.7-pre (release_9.6.22-1309-g8507ef @ 
>> /home//src/org-mode/lisp/)
>>
>> like so:
>>
>> emacs -L ~/src/org-mode/lisp -L ~/src/org-mode/contrib/lisp -Q
>>
>> org-clock-report
>>
>> with point on said frame of a clock table produces
>>
>> Updating dynamic block ‘clocktable’ at line 13...
>> org-clock-sum: Wrong type argument: fixnump, nil
>
> What if you do the same starting from "make repro" in ~/src/org-mode ?
> The backtrace should then appear rather than just an error line.

I did

rm -rf *; git checkout -f; make repro

in ~/src/org-mode.  make repro is very quick.

Then I tested again with the above mentioned clock
table frame and emacs command line invocation: Same
result.  No backtrace.

Am I missing something?

> I would like to see that backtrace to understand what went wrong.

Do you have further hints how to produce this
backtrace?

Ciao; Gregor



[BUG] org-clock-sum: Wrong type argument: fixnump, nil [9.7-pre (release_9.6.22-1309-g8507ef @ /home/grfz/src/org-mode/lisp/)]

2024-03-23 Thread Gregor Zattler
Dear org-mode developers, Ihor, 

the following is with GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, cairo 
version 1.16.0)
 of 2024-02-27

with point on the following frame for a clock table:

#+BEGIN: clocktable :scope ("/home/absolute/path/file.org_archive")
#+END:

org-clock-report with

emacs -Q

(that is, with Org mode version 9.6.15 (release_9.6.15 @ 
/home//src/emacs-master--32b4f9d21b14190f1ed1611515751abe4b90fa68--2024-02-27T09-36+01-00/lisp/org/)

produces a nice clock report table.

If instead I use a very fresh org-mode from main, specifically

Org mode version 9.7-pre (release_9.6.22-1309-g8507ef @ 
/home//src/org-mode/lisp/)

like so:

emacs -L ~/src/org-mode/lisp -L ~/src/org-mode/contrib/lisp -Q

org-clock-report

with point on said frame of a clock table produces

Updating dynamic block ‘clocktable’ at line 13...
org-clock-sum: Wrong type argument: fixnump, nil


file.org_archive has 2376 clock lines.

The problem does not occur with file.org which has
only 86 clock lines.  I especially archive the nodes
with clock lines, because or performance reasons.


Doing a git bisect produced:

2e901ed23667b04642847701bae2070862b8ee6e is the first bad commit
commit 2e901ed23667b04642847701bae2070862b8ee6e
Author: Ihor Radchenko 
Date:   Fri Feb 3 15:08:18 2023 +0300

org-clock-sum: Optimize performance

* lisp/org-clock.el (org-clock-sum): Do not re-parse the timestamps,
reusing already-parser element.

 lisp/org-clock.el | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)


I cannot disclose said file, because it contains loads
of sensitive data.  I extracted the clock lines only,
but a single node with a LOGBOOK drawer filled with
this clock lines does not trigger the bug.  But I would
be happy to test a patch on my file.org to test it (or
help otherwise).


HTH, Gregor



Re: [BUG] [bug] clocking in suddenly does not work any more [9.7-pre (release_9.6.18-1197-ga250fc @ /home/grfz/src/org-mode/lisp/)]

2024-02-26 Thread Gregor Zattler
Dear org-mode users and developers,
* Gregor Zattler  [2024-02-26; 21:18 +01]:
> I used to clock in (and out) on a certain node several
> times a day.  Also today, but this suddenly does not
> work any more, it inserts only a
>
> CLOCK:
>
> (with preceeding blank) but no following time stamp and

wrong: with succeeding blank, sorry English is not my
first language.

> I get the message: "org-clock-sum-current-item: Wrong
> type argument: fixnump, nil"
>
> This still works with emacs -Q, so is somehow related
> to my configuration, but I get this error even with my
> whole emacs.d replaced by the backup from yesterday and
> ~/.cache/emacs/ ~/.cache/org-persist/ org-clock-save.el
> deleted.

I played a bit around.  If I delete the following part
of the LOGBOOK:

ClOCK: [2024-02-26 Mo 11:35]--[2024-02-26 Mo 11:40] =>  0:05
- Clocking out at [2024-02-26 Mo 11:40]

it works again.  The "l" in "ClOCK" is not
capitalized.  I wonder how I managed to change that
single letters capitalization.

For me the problem is solved, although I do not
understand, why emacs -Q does not stumble over this
while my configured Emacs does


Regards, Gregor

Canceled, I hope this works for woof!



[BUG] [bug] clocking in suddenly does not work any more [9.7-pre (release_9.6.18-1197-ga250fc @ /home/grfz/src/org-mode/lisp/)]

2024-02-26 Thread Gregor Zattler
Dear org-mode users and developers,

I used to clock in (and out) on a certain node several
times a day.  Also today, but this suddenly does not
work any more, it inserts only a

CLOCK:

(with preceeding blank) but no following time stamp and
I get the message: "org-clock-sum-current-item: Wrong
type argument: fixnump, nil"

This still works with emacs -Q, so is somehow related
to my configuration, but I get this error even with my
whole emacs.d replaced by the backup from yesterday and
~/.cache/emacs/ ~/.cache/org-persist/ org-clock-save.el
deleted.

Any ideas how to debug this?

Thanks, Gregor

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0)
 of 2024-02-13
Package: Org mode version 9.7-pre (release_9.6.18-1197-ga250fc @ 
/home/grfz/src/org-mode/lisp/)

current state:
==
(setq
 org-list-use-circular-motion t
 org-link-email-description-format "%c: %.80s"
 org-log-note-headings '((done . "CLOSING NOTE %t") (state . "State %-12s from 
%-12S %t") (note . "Note taken on %t") (reschedule . "Rescheduled from %S on 
%t")
 (delschedule . "Not scheduled, was %S on %t") 
(redeadline . "New deadline from %S on %t") (deldeadline . "Removed deadline, 
was %S on %t")
 (refile . "Refiled on %t") (clock-out . "Clocking out 
at %t "))
 org-link-elisp-confirm-function 'yes-or-no-p
 org-agenda-diary-file "~/org/diary.org"
 org-directory "~/org/"
 org-crypt-key "0x"
 org-bibtex-headline-format-function 'org-bibtex-headline-format-default
 org-agenda-custom-commands '(("p" "export daily/weekly /tmp/my-org-agenda.pdf" 
agenda ""
   ((ps-paper-type 'a4) (ps-number-of-columns '1) 
(ps-landscape-mode nil) (org-agenda-with-colors nil) (ps-font-size '(7 . 8.5)) 
(org-agenda-start-on-weekday 1)
(ps-selected-pages '((1 . 2))) 
(org-agenda-ndays 155))
   ("/tmp/my-org-agenda.pdf"))
  ("1" "Q1" tags "+important+urgent") ("2" "Q2" 
tags "+important-urgent") ("3" "Q3" tags "-important+urgent") ("4" "Q4" tags 
"-important-urgent"))
 org-log-into-drawer t
 org-startup-folded nil
 org-agenda-files '("/home//.xx/x/x.xxx" 
"~/xxx/x.xxx" "~/xxx/.xxx" "~///xxx/xxx.xxx")
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-refile-targets '(("~/org/diary.org" :maxlevel . 3) 
("~///xxx/xxx.org" :maxlevel . 5) ("~/org/.org" 
:maxlevel . 5) (org-agenda-files :maxlevel . 9))
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-tag-alist '((:startgroup) ("@xxx" . 105) ("@xxx" . 109) ("@xxx" . 114) 
(:endgroup) (:startgrouptag) ("@comp") (:grouptags) (:startgroup) ("@len" . 
108) ("@no" . 1) ("@shi" . 115)
 ("@del") ("@pit") (:endgrouptag) (:endgroup) ("@fon" . 102) 
("urgent" . 117) ("important" . 73) ("lizenz" . 76) ("techtipp" . 116) ("soc" . 
115))
 org-agenda-exporter-settings '((ps-print-color-p 'black-white))
 org-refile-use-outline-path 'file
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-log-reschedule 'note
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines 
org-cycle-optimize-window-after-visibility-change 
org-cycle-display-inline-images)
 org-agenda-text-search-extra-files '(agenda-archives)
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-agenda-sticky t
 org-read-date-prefer-future 'time
 org-yank-image-file-name-function 'org-yank-image-autogen-filename
 org-link-from-user-regexp "@xxx\\.xx\\||xx...@xxx.xxx\\|x...@.xx|...@xxx.xx\\|x....@xxx.xx\\|xx@xxx\\.xxx"
 org-attach-use-inheritance nil
 org-odd-levels-only t
 org-mode-hook '(gz-maybe-org-add-file # org-clock-load
 (closure (t) nil (define-key org-mode-map "o" 
'org-ctags-find-tag-interactive)) imenu-add-menubar-index turn-on-wcheck-mode 
turn-on-abbrev-mode rainbow-delimiters-mode
 #[0 "\301\211\207" [imenu-create-index-function 
org-imenu-get-tree] 2] #[0 "\300\301\302\303\304$\207" [add-hook 
change-major-mode-hook org-fold-show-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-eldoc-load)
 org-babel-load-languages '((emacs-lisp . t) (shell . t) (plantuml . t))
 org-footnote-auto-label 'random
 org-archive-subtree-add-inherited-tags t
 org-crypt-tag-matcher "org_crypt"
 org-agenda-span 44
 org-confirm-shell-link-function 'yes-or-no-p
 org-reveal-start-hook '(org-decrypt-entry)
 org-agenda-clock-consistency-checks '(:max-duration "10:00" :min-duration 0 
:max-gap "43:05" :gap-ok-around ("4:00" "12:00") :default-face ((:background 
"DarkRed") 

Re: [BUG] org-open-at-point-global fails on links with multiline descriptions in org-mode buffers [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

2024-01-21 Thread Gregor Zattler
Hi Ihor, Omar, 
* Ihor Radchenko  [2024-01-21; 12:18 GMT]:
> Omar Antolín Camarena  writes:
>
>> If you have an org link with a newline embedded in the description in an 
>> org-mode buffer and put point on it, org-open-at-point correctly follows the 
>> link but org-open-at-point-global does not, it instead reports "No link 
>> found". (I have plenty of org links with newlines in the description, 
>> because org-fill-paragraph tends to reformat links that way.)
>
> Thanks for reporting!
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ac1c72376

that works for me now with both, org-open-at-point in
org-mode buffers and org-open-at-point-global somewhere
else.

But how about this idea of Omar: 

"I would like to suggest that org-open-at-point-global
check to see if it is being run in an Org mode buffer
and if so just call org-open-at-point.  That way users
can bind org-open-at-point-global and use that key
binding everywhere including org-mode buffers without
loss of functionality compared to org-open-at-point."

This sounds reasonable for me!?

Regards, Ggregor



Re: Warning (org-element-cache): org-element--cache: Warning(notmuch-startpage.org): Org parser error in notmuch-startpage.org::8690. Resetting.

2023-11-19 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2023-11-19; 19:21 GMT]:
> Gregor Zattler  writes:
>> Warning (org-element-cache): org-element--cache: 
>> Warning(notmuch-startpage.org): Org parser error in 
>> notmuch-startpage.org::8690. Resetting.
>>  The error was: (wrong-number-of-arguments ((t) (element) "Return type of 
>> ELEMENT.
>>
>> The function returns the type of the element or object provided.
>> It can also return the following special value:
>>   `plain-text'   for a string
>>   `org-data' for a complete document
>>   nilin any other case." (cond ((not (consp element)) (and 
>> (stringp element) 'plain-text)) ((symbolp (car element)) (car element 2)
>
> This does look like mixed installation.
> `org-element-type' got extra optional argument in Org 9.7, but you are
> getting "wrong number of arguments" error that indicates an older
> version of this function.

thanks, so a "reboot" of Emacs helped.

Ciao; Gregor



Re: [BUG] JUSTIFYRIGHT does not justify to the right any more in ASCII export [9.7-pre (release_9.6.11-927-g819cd7 @ /home/grfz/src/org-mode/lisp/)]

2023-11-17 Thread Gregor Zattler
Hi Ihor, org-mode community,
* Ihor Radchenko  [2023-11-17; 08:32 GMT]:
> Gregor Zattler  writes:
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0740e62df

thank you very much, it now again works for me.

Ciao; Gregor



[BUG] JUSTIFYRIGHT does not justify to the right any more in ASCII export [9.7-pre (release_9.6.11-927-g819cd7 @ /home/grfz/src/org-mode/lisp/)]

2023-11-16 Thread Gregor Zattler

Dear org-mode developers,

this:



test-justify-right.org
Description: application/org

gives wrongly:

Table of Contents
─




left or right

with

Package: Org mode version 9.7-pre (release_9.6.11-927-g819cd7 @ 
/home/grfz/src/org-mode/lisp/)
on Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 
1.16.0)
 of 2023-11-02


while correctly this:

Table of Contents
─




   left or right

with
Org mode version 9.6.10 (release_9.6.10 @ 
/home/grfz/src/emacs-master--078cfe807295038fa321c9297e24de5145065622--2023-11-02T00-38+01-00/lisp/org/)
on the very same Emacs.


Git bisecting found
[69383dfc240a3be08cfb57d4f1d8727bbb0df902] org-ascii--current-justification: 
Use `org-element-lineage-map'

but I'm not sure this makes sense since the org-version
numbers went backwards when doing it.

HTH, Gregor


[BUG] Warning (org-element-cache): org-element--cache: Warning(Checkliste-Updates.txt): Org parser error in Checkliste-Updates.txt [9.7-pre (release_9.6.9-790-ge42b7a @ /home/grfz/src/org-mode/lisp/)]

2023-09-26 Thread Gregor Zattler
Dear org mode maintainers, developers, Ihor, I caught the
following warning/backtrace while calling
'my/org-goto-agenda-heading´ which in turn is just
"(org-refile '(4))".

HTH/Ciao; Gregor 

 ■  Warning (org-element-cache): org-element--cache: 
Warning(Checkliste-Updates.txt): Org parser error in 
Checkliste-Updates.txt::94. Resetting.
 The error was: (wrong-type-argument integer-or-marker-p nil)
 Backtrace:
nil
 Please report this to Org mode mailing list (M-x org-submit-bug-report).
Backtrace:
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(comment (:standard-properties [1189 1189 nil nil 1251 0 nil 
nil element t nil nil nil nil # nil nil (section 
(:standard-properties [39 39 39 1251 1251 0 nil section element t nil 39 1251 
nil # nil nil ...]))] :value \"Local Variables:
mode: Org
indent-tabs-mode: nil
End:\"))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(paragraph (:standard-properties [1187 1187 1187 1189 1189 0 
nil nil element t nil nil nil nil # nil nil 
(section (:standard-properties [39 39 39 1251 1251 0 nil section element t nil 
39 1251 nil # nil nil ...]))]))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(paragraph (:standard-properties [920 920 920 1186 1187 1 nil 
nil element t nil nil nil nil # nil nil (section 
(:standard-properties [39 39 39 1251 1251 0 nil section element t nil 39 1251 
nil # nil nil ...]))]))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(plain-list (:standard-properties [39 39 39 917 920 3 nil 
planning element t nil nil nil nil # nil ((39 0 
\"1. \" nil nil nil 917) (64 3 \"* \" nil nil nil 917) (154 5 \"- \" nil nil 
nil 180) (180 5 \"- \" nil nil nil 263) (263 5 \"- \" nil nil nil 917) (357 7 
\"+ \" nil nil nil 711) (397 9 \"- \" nil nil nil 567) (567 9 \"- \" nil nil 
nil 607) (607 9 \"- \" nil nil nil 711) (711 7 \"+ \" nil nil nil 917) (751 9 
\"- \" nil nil nil 917) (852 11 \"+ \" nil nil nil 917)) (section 
(:standard-properties [39 39 39 1251 1251 0 nil section element t nil 39 1251 
nil # nil nil ...]))] :type ordered))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(section (:standard-properties [39 39 39 1251 1251 0 nil 
section element t nil 39 1251 nil # nil nil 
(headline (:standard-properties [1 1 39 1251 1251 0 ... nil nil t ... 41 1249 1 
# nil nil ...] :pre-blank 1 :raw-value 
[org-element-deferred org-element--headline-raw-value ... nil] :title 
[org-element-deferred org-element-property-2 ... nil] :level 1 :priority nil 
:tags nil :todo-keyword nil :todo-type nil :footnote-section-p 
[org-element-deferred org-element--headline-footnote-section-p nil nil] 
:archivedp [org-element-deferred org-element--headline-archivedp nil nil] 
:commentedp nil))]))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(headline (:standard-properties [1 1 39 1251 1251 0 (:title) 
nil nil t (143 . 1) 41 1249 1 # nil nil 
(org-data (:standard-properties [1 1 1 1251 1251 0 nil org-data nil t nil 3 
1251 nil # nil nil nil] :path 
\"/ssh:root@fs2:/data///WWW_DD_E/Dokumentation 
/How-to-restore-from-proxmox-backup.txt\" :CATEGORY 
\"How-to-restore-from-proxmox-backup\"))] :pre-blank 1 :raw-value 
[org-element-deferred org-element--headline-raw-value (2 36) nil] :title 
[org-element-deferred org-element-property-2 (:raw-value) nil] :level 1 
:priority nil :tags nil :todo-keyword nil :todo-type nil :footnote-section-p 
[org-element-deferred org-element--headline-footnote-section-p nil nil] 
:archivedp [org-element-deferred org-element--headline-archivedp nil nil] 
:commentedp nil))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Recovering persistent 
cached element: "(org-data (:standard-properties [1 1 1 1251 1251 0 nil 
org-data nil t nil 3 1251 nil # nil nil nil] 
:path 
\"/ssh:root@fs2:/data///WWW_DD_E/Dokumentation/How-to-restore-from-proxmox-backup.txt\"
 :CATEGORY \"How-to-restore-from-proxmox-backup\"))"
  org-element-cache diagnostics(Checkliste-Updates.txt): Loading persistent 
cache for 
/ssh:root@fs2:/data///WWW_DD_E/Dokumentation/Checkliste-Updates.txt





Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0)
 of 2023-09-19
Package: Org mode version 9.7-pre (release_9.6.9-790-ge42b7a @ 
/home//src/org-mode/lisp/)

current state:
==
(setq
 org-list-use-circular-motion t
 org-link-email-description-format "%c: %.80s"
 org-log-note-headings '((done . "CLOSING NOTE %t") (state . "State %-12s from 
%-12S %t")
 (note . "Note taken on %t")
 (reschedule . "Rescheduled from %S on %t")
 (delschedule . "Not scheduled, was %S on %t")
 (redeadline . "New deadline 

Warning(diary.org_archive): Got element without parent (cache active?: t)

2023-08-27 Thread Gregor Zattler
Hi org-mode developers, Ihor,

I got these warnings when I followed an id: link
(org-open-at-point) within diary.org

I have no idea why diary.org_archive was opened at that
time.  The following is the complete contents of the
*Warnings* buffer at the moment:

 ■  Warning (org-element-cache): org-element--cache: 
Warning(diary.org_archive): Got element without parent (cache active?: t). 
Please report it to Org mode mailing list (M-x org-submit-bug-report).
(headline (:standard-properties [3412566 3412987 3412644 3412987 0 3412566 
(:title) t nil 3412716 3412985 nil element 3 # nil 
nil nil] :pre-blank 0 :raw-value [org-element-deferred 
org-element--headline-raw-value (9 72) nil] :title [org-element-deferred 
org-element-property-2 (:raw-value) nil] :level 2 :priority nil :tags ("@no") 
:todo-keyword "DONE" :todo-type done :footnote-section-p [org-element-deferred 
org-element--headline-footnote-section-p nil nil] :archivedp 
[org-element-deferred org-element--headline-archivedp nil nil] :commentedp nil 
:ID [org-element-deferred org-element--substring (104 140) nil]))
Backtrace:
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(keyword (:standard-properties [128 128 nil nil 155 1 nil nil element nil 
nil nil nil nil # nil nil nil] :key \"STARTUP\" 
:value \"showeverything\"))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(keyword (:standard-properties [108 108 nil nil 128 0 nil nil element nil 
nil nil nil nil # nil nil nil] :key \"STARTUP\" 
:value \"overview\"))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(keyword (:standard-properties [93 93 nil nil 108 0 nil nil element nil 
nil nil nil nil # nil nil nil] :key \"STARTUP\" 
:value \"odd\"))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(keyword (:standard-properties [72 72 nil nil 93 0 nil nil element nil 
nil nil nil nil # nil nil nil] :key \"STARTUP\" 
:value \"showstars\"))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(keyword (:standard-properties [64 64 nil nil 72 0 nil nil element nil 
nil nil nil nil # nil nil nil] :key \"TAGS\" :value 
\"\"))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(paragraph (:standard-properties [1 1 1 64 64 0 nil top-comment element 
nil nil nil nil nil # nil nil nil]))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(section (:standard-properties [1 1 1 155 155 0 nil first-section element 
nil nil 1 155 nil # nil nil nil]))"
  org-element-cache diagnostics(diary.org_archive): Added new element with nil 
key: "(org-data (:standard-properties [1 1 1 3583853 3583853 0 nil org-data nil 
nil nil 3 3583853 nil # [org-element-deferred 
org-element--get-global-node-properties nil t] nil nil] :path 
\"/home/grfz/org/diary.org_archive\"))"
  org-element-cache diagnostics(diary.org_archive): Nothing in cache. Adding 
org-data: "(org-data (:standard-properties [1 1 1 3583853 3583853 0 nil 
org-data nil nil nil 3 3583853 nil # 
[org-element-deferred org-element--get-global-node-properties nil t] nil nil] 
:path \"/home/grfz/org/diary.org_archive\"))"
 ■  Warning (org-element-cache): org-element--cache: (org-open-at-point) Cached 
element is incorrect in diary.org_archive. (Cache tic up to date: "yes") 
Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The element is: "(headline (:standard-properties [3412566 3412987 3412644 
3412987 0 3412566 (:title) t nil 3412716 3412985 nil element 3 # nil nil nil] :pre-blank 0 :raw-value [org-element-deferred 
org-element--headline-raw-value (9 72) nil] :title [org-element-deferred 
org-element-property-2 (:raw-value) nil] :level 2 :priority nil :tags (\"@no\") 
:todo-keyword \"DONE\" :todo-type done :footnote-section-p 
[org-element-deferred org-element--headline-footnote-section-p nil nil] 
:archivedp [org-element-deferred org-element--headline-archivedp nil nil] 
:commentedp nil :ID [org-element-deferred org-element--substring (104 140) 
nil]))"
 The real element is: "(headline (:standard-properties [3412566 3412566 3412644 
3412987 3412987 0 (:title) nil nil nil nil 3412646 3412987 3 # [org-element-deferred org-element--headline-deferred nil t] 
nil [org-element-deferred org-element--headline-parent-deferred nil t]] 
:pre-blank 0 :raw-value [org-element-deferred org-element--headline-parse-title 
(t) nil] :title [org-element-deferred org-element--headline-parse-title (t) 
nil] :level [org-element-deferred org-element--headline-parse-title (t) nil] 
:priority [org-element-deferred org-element--headline-parse-title (t) nil] 
:tags [org-element-deferred org-element--headline-parse-title (t) nil] 
:todo-keyword [org-element-deferred org-element--headline-parse-title (t) nil] 
:todo-type [org-element-deferred 

Re: org-element--cache: Warning(izt.org): Got element without parent (cache active?: t)

2023-08-23 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2023-08-23; 10:53 GMT]:
> Gregor Zattler  writes:
>>  ■  Warning (org-element-cache): org-element--cache: Warning(izt.org): Got 
>> element without parent (cache active?: t). Please report it to Org mode 
>> mailing list (M-x org-submit-bug-report).
>> (node-property (:standard-properties [326858 326875 nil nil 0 326858 nil t 
>> nil nil nil node-property element nil # nil nil nil] :key 
>> "VISIBILITY" :value "all"))
>> Backtrace:
>>   org-element-cache diagnostics(izt.org): Added new element with nil key: 
>> "(keyword
>> ...
> May you try to reproduce the problem starting from emacs -Q, reducing
> your Org file to some small file that can be shared?

that happened when org-mode generated my agenda, there
are four rather big org-mode files involved.  Is it
sufficent to try to reproduce with izt.org only, which
is mentioned in the warning?

I tried just now, but there was no warning and since
the warning I changed the file.  Especially I did
org-link and resolved all problems...

Next time I will save the file immediately for
inspection.

Ciao; Gregor 



org-element--cache: Warning(izt.org): Got element without parent (cache active?: t)

2023-08-23 Thread Gregor Zattler
Dear Ihow, I caught another org-element-cache warning.
I started Emacs (after having problems with a botched
configuration, which in turn uses babel...) and called
the agenda like so:

  (defun gz/org-agenda-list ()
"Show Org Agenda starting yesterday."
(interactive)
(org-agenda-list 0 "-1d")
(beginning-of-buffer)
(org-agenda-goto-today))

and then I got this (see below).  This is with

GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0) of 
2023-08-22
Org mode version 9.7-pre (release_9.6.7-721-g53c9d9 @ 
/home/grfz/src/org-mode/lisp/)

Thanks for speeding up org-mode, Gregor


 ■  Warning (org-element-cache): org-element--cache: Warning(izt.org): Got 
element without parent (cache active?: t). Please report it to Org mode mailing 
list (M-x org-submit-bug-report).
(node-property (:standard-properties [326858 326875 nil nil 0 326858 nil t nil 
nil nil node-property element nil # nil nil nil] :key 
"VISIBILITY" :value "all"))
Backtrace:
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(keyword (:standard-properties [328278 328278 nil nil 328301 1 nil nil element 
nil nil nil nil nil # nil nil nil] :key \"FILETAGS\" :value 
\":izt:job:\"))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(keyword (:standard-properties [328148 328148 nil nil 328278 0 nil nil element 
nil nil nil nil nil # nil nil nil] :key \"SEQ_TODO\" :value 
\"TODO(t) INPROGRESS(i@/@) WAITING(w@/@) VERIFY(v@/@) | DONE(d@/@) 
DELEGATED(D@/@) CANCELLED(c@/@) PUTOFF(p@/@) IDEA(I)\"))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(keyword (:standard-properties [328117 328117 nil nil 328148 0 nil nil element 
nil nil nil nil nil # nil nil nil] :key \"COLUMNS\" :value 
\"%45ITEM %18DEADLINE\"))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(paragraph (:standard-properties [328101 328101 328101 328117 328117 0 nil nil 
element nil nil nil nil nil # nil nil nil]))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(keyword (:standard-properties [328073 328073 nil nil 328101 0 nil nil element 
nil nil nil nil nil # nil nil nil] :key \"STARTUP\" :value 
\"lognoteclock-out\"))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(keyword (:standard-properties [328048 328048 nil nil 328073 0 nil nil element 
nil nil nil nil nil # nil nil nil] :key \"STARTUP\" :value 
\"lognoterepeat\"))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(keyword (:standard-properties [328025 328025 nil nil 328048 0 nil nil element 
nil nil nil nil nil # nil nil nil] :key \"STARTUP\" :value 
\"lognotedone\"))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(paragraph (:standard-properties [327998 327998 327998 328025 328025 0 nil nil 
element nil nil nil nil nil # nil nil nil]))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(keyword (:standard-properties [327975 327975 nil nil 327998 0 nil nil element 
nil nil nil nil nil # nil nil nil] :key \"STARTUP\" :value 
\"show3levels\"))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(paragraph (:standard-properties [327954 327954 327954 327975 327975 0 nil nil 
element nil nil nil nil nil # nil nil nil]))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(keyword (:standard-properties [327939 327939 nil nil 327954 0 nil nil element 
nil nil nil nil nil # nil nil nil] :key \"STARTUP\" :value 
\"odd\"))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(keyword (:standard-properties [327918 327918 nil nil 327939 0 nil nil element 
nil nil nil nil nil # nil nil nil] :key \"STARTUP\" :value 
\"hidestars\"))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(example-block (:standard-properties [327025 327025 nil nil 327918 3 nil nil 
element nil nil nil nil nil # nil nil nil] :value 
[org-element-deferred org-element--unescape-substring (16 876) nil] :switches 
nil :number-lines nil :preserve-indent nil :retain-labels t :use-labels t 
:label-fmt nil))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(drawer (:standard-properties [326881 326881 326891 327017 327025 0 nil nil 
element nil nil nil nil nil # nil nil nil] :drawer-name 
\"LOGBOOK\"))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(property-drawer (:standard-properties [326797 326797 326810 326875 326881 0 
nil planning element nil nil nil nil nil # nil nil nil]))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(section (:standard-properties [326797 326797 326797 328914 328914 0 nil 
section element nil nil 326797 328914 nil # nil nil nil]))"
  org-element-cache diagnostics(izt.org): Added new element with nil key: 
"(headline (:standard-properties [326755 326755 326797 328914 328914 0 

org-element-cache-warning

2023-08-21 Thread Gregor Zattler
Dear org-mode developers, Ihor, I cought an
org-element-cache warning with a rather up-to-date
emacs and org-mode while calling via a key binding this
simple function:

  (defun my/org-goto-agenda-heading ()
(interactive)
(org-refile '(4)))

GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0) of 
2023-08-20
Org mode version 9.7-pre (release_9.6.7-709-gdd2f05 @ 
/home/grfz/src/org-mode/lisp/)

I hope this helps somehow.

Ciao; Gregor



 ■  Warning (org-element-cache): org-element--cache: Warning(grfz.org): 
(my/org-goto-agenda-heading) Cached element is incorrect in grfz.org. (Cache 
tic up to date: "yes") Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The element is: "(headline (:standard-properties [159509 160713 159557 160712 1 
159509 (:title) t nil 159559 160710 nil element 3 (headline 
(:standard-properties [2550 183136 2561 183133 3 2550 ... t nil 2669 183131 nil 
element 1 ... nil nil #] :pre-blank 0 :raw-value 
[org-element-deferred org-element--headline-raw-value ... nil] :title 
[org-element-deferred org-element-property-2 ... nil] :level 1 :priority nil 
:tags nil :todo-keyword nil :todo-type nil :footnote-section-p 
[org-element-deferred org-element--headline-footnote-section-p nil nil] 
:archivedp [org-element-deferred org-element--headline-archivedp nil nil] 
:commentedp nil :ARCHIVE [org-element-deferred org-element--substring ... nil] 
:ID [org-element-deferred org-element--substring ... nil])) nil nil #] :pre-blank 0 :raw-value [org-element-deferred 
org-element--headline-raw-value (4 47) nil] :title [org-element-deferred 
org-element-property-2 (:raw-value) nil] :level 2 :priority nil :tags nil 
:todo-keyword nil :todo-type nil :footnote-section-p [org-element-deferred 
org-element--headline-footnote-section-p nil nil] :archivedp 
[org-element-deferred org-element--headline-archivedp nil nil] :commentedp 
nil))"
 The real element is: "(headline (:standard-properties [159509 160713 159557 
160713 0 159509 (:title) nil nil 159559 160713 nil nil 3 [org-element-deferred 
org-element--headline-parent-deferred nil t] [org-element-deferred 
org-element--headline-deferred nil t] nil #] :pre-blank 0 
:raw-value [org-element-deferred org-element--headline-parse-title (t) nil] 
:title [org-element-deferred org-element--headline-parse-title (t) nil] :level 
[org-element-deferred org-element--headline-parse-title (t) nil] :priority 
[org-element-deferred org-element--headline-parse-title (t) nil] :tags 
[org-element-deferred org-element--headline-parse-title (t) nil] :todo-keyword 
[org-element-deferred org-element--headline-parse-title (t) nil] :todo-type 
[org-element-deferred org-element--headline-parse-title (t) nil] 
:footnote-section-p [org-element-deferred org-element--headline-parse-title (t) 
nil] :archivedp [org-element-deferred org-element--headline-parse-title (t) 
nil] :commentedp [org-element-deferred org-element--headline-parse-title (t) 
nil]))"
 Cache around :begin:
"(headline (:standard-properties [158019 159509 158064 159509 0 158019 (:title) 
t nil 158066 159507 nil element 3 (headline (:standard-properties [2550 183136 
2561 183133 3 2550 ... t nil 2669 183131 nil element 1 ... nil nil #] :pre-blank 0 :raw-value [org-element-deferred 
org-element--headline-raw-value ... nil] :title [org-element-deferred 
org-element-property-2 ... nil] :level 1 :priority nil :tags nil :todo-keyword 
nil :todo-type nil :footnote-section-p [org-element-deferred 
org-element--headline-footnote-section-p nil nil] :archivedp 
[org-element-deferred org-element--headline-archivedp nil nil] :commentedp nil 
:ARCHIVE [org-element-deferred org-element--substring ... nil] :ID 
[org-element-deferred org-element--substring ... nil])) nil nil #] :pre-blank 0 :raw-value [org-element-deferred 
org-element--headline-raw-value (4 44) nil] :title [org-element-deferred 
org-element-property-2 (:raw-value) nil] :level 2 :priority nil :tags nil 
:todo-keyword nil :todo-type nil :footnote-section-p [org-element-deferred 
org-element--headline-footnote-section-p nil nil] :archivedp 
[org-element-deferred org-element--headline-archivedp nil nil] :commentedp 
nil))"
"(headline (:standard-properties [159509 160713 159557 160712 1 159509 (:title) 
t nil 159559 160710 nil element 3 (headline (:standard-properties [2550 183136 
2561 183133 3 2550 ... t nil 2669 183131 nil element 1 ... nil nil #] :pre-blank 0 :raw-value [org-element-deferred 
org-element--headline-raw-value ... nil] :title [org-element-deferred 
org-element-property-2 ... nil] :level 1 :priority nil :tags nil :todo-keyword 
nil :todo-type nil :footnote-section-p [org-element-deferred 
org-element--headline-footnote-section-p nil nil] :archivedp 
[org-element-deferred org-element--headline-archivedp nil nil] :commentedp nil 
:ARCHIVE [org-element-deferred org-element--substring ... nil] :ID 
[org-element-deferred org-element--substring ... nil])) 

Re: BUG: org-cycle does not unfold some subtrees

2023-05-14 Thread Gregor Zattler
Hi Michael, Ihor, ...
* Michael Dauer  [2023-05-14; 12:56 +02]:
> I think I found a way to consistently reproduce the issue:

> * h1
> a
> * h2
> b
> * h3
> b
> * h4
> c
> <<<
> Collapse all. All is fine at this time.
> At pos-min call (query-replace) bbb -> zzz: Already when asking whether to
> replace it cannot expand. h2 and h3 are expansion is broken.

I confirm this recipe.  For me and with my
configuration, as with emacs -Q, I then cannot unfold
h2.

> (org-fold-core--clear-isearch-overlays) repairs it.

This is also the case with my configuration, as with
emacs -Q.

Then I can unfold all headings and see that the
replacement bbb --> zzz worked.


GNU Emacs 29.0.90 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0) of 
2023-05-04
Org mode version 9.7-pre (release_9.6.5-357-g080710 @ 
/home/grfz/src/org-mode/lisp/)


Ciao; Gregor



Re: bug#59882: Multiple versions of Org in load-path problem

2023-02-14 Thread Gregor Zattler
Hi Tim, org-mode and emacs developers,
* Tim Cross  [2023-02-04; 07:01 +11]:
> Ihor Radchenko  writes:
>> Max Nikulin  writes:
>>> On 27/12/2022 16:47, Ihor Radchenko wrote:
 Can you then try to test using Emacs 28?
 The main question if whether this has been fixed in newer Emacs releases
 or it is also something to do with OS environment.
>>> I see quite the same issue with Emacs-28.2 in Debian testing. Compile
>>> buffer displays a bit more warnings and usual `org-assert-version'
>>> warnings and errors are present as well. It might have another level of
>>> complexity due to .eln files. I am unsure what happens with calls to
>>> undefined macros.
>>
>> I asked people around to test using Debian, and we do have a
>> confirmation that Debian + Emacs 27 and Debian + Emacs 28 do trigger the
>> error.
>>
>> I also installed Debian 11.6.0 on virtual machine, and I was also able to
>> trigger the error, following the provided steps, using the Emacs 27
>> installed via apt-get.
>>
>> The problem seems to be real and appears to be some combination of
>> Debian/Ubuntu + Emacs.
>>
>> Considering the popularity of Debian-based distros, may someone take a
>> closer look on what may be going on? Since the latest Emacs release also
>> suffers from the problem, I am afraid that the issue will be present in
>> the coming Emacs 29 as well (I recall no related fixes in recent Emacs).
>
> I don't run Debian or Ubuntu anymore. However, I do recall that debian
> does use a modified Emacs startup which is not part of the standard
> Emacs distribution. They do this to enable the ability to have multiple
> versions of Emacs installed at the same time.

that would be /usr/share/emacs/site-lisp/debian-startup.el


Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-



Re: [RFC] If you use Org 9.6, please share the output of M-x org-element-cache-hash-show-statistics

2023-02-10 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2023-02-09; 11:51 GMT]:
> If you are ok with sharing the statistics, and you are running Emacs
> session for at least few hours (using Org mode, obviously), please reply
> sharing the output of
>  M-x org-element-cache-hash-show-statistics 
4.77% of cache searches hashed, 2.52% non-hashable.

Wouldn't absolute number not be more interesting?

>  M-x emacs-uptime 

6 hours, 59 minutes, 41 seconds



GNU Emacs 29.0.60 (build 3, x86_64-pc-linux-gnu, cairo version 1.16.0) of 
2023-01-25

Org mode version 9.6.1 (release_9.6.1-208-g0c0059 @ 
/home/grfz/src/org-mode/lisp/)


Thanks for all your efforts, Gregor



Re: [BUG] Warning (org-element-cache): org-element--cache: Warning(XXX.org): (gz/org-agenda-list) Cached element is incorrect in XXX.org. (Cache tic up to date: "yes") [9.6.1 (release_9.6.1-208-g0c0

2023-02-07 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2023-02-07; 10:59 GMT]:
> Gregor Zattler  writes:
>> * Ihor Radchenko  [2023-02-06; 10:28 GMT]:
>>> Gregor Zattler  writes:
>>> Unfortunately, the provided log is incomplete. I cannot deduce anything
>>> useful from it.
>>
>> that's strange, I realized it was shorter than others, but
>> it's all emacs had in it's *Warnings* buffer then.
>
> This is strange. Did the buffer in question happened to be an indirect buffer?

I do not use indirect buffers intentionally.  If an agenda
is an indirect buffer than it may be -- I do not remember
the exact situation, it was happening at the very first
minutes I used emacs after it's startup.

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-



Re: [BUG] Warning (org-element-cache): org-element--cache: Warning(XXX.org): (gz/org-agenda-list) Cached element is incorrect in XXX.org. (Cache tic up to date: "yes") [9.6.1 (release_9.6.1-208-g0c0

2023-02-07 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2023-02-06; 10:28 GMT]:
> Gregor Zattler  writes:
> Unfortunately, the provided log is incomplete. I cannot deduce anything
> useful from it.

that's strange, I realized it was shorter than others, but
it's all emacs had in it's *Warnings* buffer then.

> Please provide the full log if you encounter the warning again.

Sure.

Thanks for looking into it; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-



[BUG] Warning (org-element-cache): org-element--cache: Warning(XXX.org): (gz/org-agenda-list) Cached element is incorrect in XXX.org. (Cache tic up to date: "yes") [9.6.1 (release_9.6.1-208-g0c0059

2023-02-06 Thread Gregor Zattler
Dear Ihor, org-mode developers, I caught another cache
warning, see below.

Emacs  : GNU Emacs 29.0.60 (build 3, x86_64-pc-linux-gnu, cairo version 1.16.0)
 of 2023-01-25
Package: Org mode version 9.6.1 (release_9.6.1-208-g0c0059 @ 
/home//src/org-mode/lisp/)


 ■  Warning (org-element-cache): org-element--cache: Warning(XXX.org): 
(gz/org-agenda-list) Cached element is incorrect in XXX.org. (Cache tic up to 
date: "yes") Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The element is: "(headline (:raw-value \"xxx\" 
:begin 218742 :end 239398 :pre-blank 0 :contents-begin 218820 :contents-end 
239398 :robust-begin 218880 :robust-end 239396 :level 2 :priority nil :tags 
(#(\"@no\" 0 3 (fontified t face ... mouse-face highlight keymap ...))) 
:todo-keyword #(\"INPROGRESS\" 0 10 (face (org-todo org-level-2) fontified t)) 
:todo-type todo :post-blank 0 :footnote-section-p nil :archivedp nil 
:commentedp nil :post-affiliated 218742 :ID 
\"e1d8cff0-9449-4f52-b822-08d8c0bd9196\" :title 
(#(\"xxx\" 0 31 (:parent ...))) :parent (headline 
(:raw-value \"xx\" :begin 1 :end 282522 :pre-blank 0 :contents-begin 14 
:contents-end 282522 :robust-begin 210 :robust-end 282520 :level 1 :priority 
nil :tags nil :todo-keyword nil :todo-type nil :post-blank 0 
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 1 :ID 
\"1dd10cbf-3e6b-4616-a633-d75324053d3d\" :ATTACH_DIR 
\"/home//projekte/XXX/\" :ATTACH_DIR_INHERIT \"t\" :ARCHIVE 
\"%s_archive::*** IT-Support\" :ORDERED \"\" :title \xxx\" :mode 
first-section ...)) :cached t :org-element--cache-sync-key nil))"
 The real element is: "(headline (:raw-value 
\"xxx\" :begin 218742 :end 239116 :pre-blank 0 
:contents-begin 218820 :contents-end 239116 :robust-begin 218880 :robust-end 
239114 :level 2 :priority nil :tags (#(\"@no\" 0 3 (fontified nil))) 
:todo-keyword #(\"INPROGRESS\" 0 10 (fontified nil)) :todo-type todo 
:post-blank 0 :footnote-section-p nil :archivedp nil :commentedp nil 
:post-affiliated 218742 :ID \"e1d8cff0-9449-4f52-b822-08d8c0bd9196\" :title 
\"xxx\" :mode nil :granularity element :parent 
nil))"
 Cache around :begin:
"(property-drawer (:begin 218413 :end 218482 :contents-begin 218428 
:contents-end 218472 :post-blank 2 :post-affiliated 218413 :mode planning 
:granularity element :cached t :parent (section (:begin 218413 :end 218742 
:contents-begin 218413 :contents-end 218742 :robust-begin 218413 :robust-end 
218740 :post-blank 0 :post-affiliated 218413 :mode section :granularity element 
:cached t :parent (headline ...)"
"(headline (:raw-value \"xxx\" :begin 218742 :end 
239398 :pre-blank 0 :contents-begin 218820 :contents-end 239398 :robust-begin 
218880 :robust-end 239396 :level 2 :priority nil :tags (#(\"@no\" 0 3 
(fontified t face ... mouse-face highlight keymap ...))) :todo-keyword 
#(\"INPROGRESS\" 0 10 (face (org-todo org-level-2) fontified t)) :todo-type 
todo :post-blank 0 :footnote-section-p nil :archivedp nil :commentedp nil 
:post-affiliated 218742 :ID \"e1d8cff0-9449-4f52-b822-08d8c0bd9196\" :title 
(#(\"xxx\" 0 31 (:parent ...))) :parent (headline 
(:raw-value \"xx\" :begin 1 :end 282522 :pre-blank 0 :contents-begin 14 
:contents-end 282522 :robust-begin 210 :robust-end 282520 :level 1 :priority 
nil :tags nil :todo-keyword nil :todo-type nil :post-blank 0 
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 1 :ID 
\"1dd10cbf-3e6b-4616-a633-d75324053d3d\" :ATTACH_DIR 
\"/home//projekte/XXX/\" :ATTACH_DIR_INHERIT \"t\" :ARCHIVE 
\"%s_archive::*** IT-Support\" :ORDERED \"\" :title \"xx\" :mode 
first-section ...)) :cached t :org-element--cache-sync-key nil))"
"(section (:begin 218820 :end 239398 :contents-begin 218820 :contents-end 
239398 :robust-begin 218820 :robust-end 239396 :post-blank 0 :post-affiliated 
218820 :mode section :granularity element :cached t :parent (headline 
(:raw-value \"xxx\" :begin 218742 :end 239398 
:pre-blank 0 :contents-begin 218820 :contents-end 239398 :robust-begin 218880 
:robust-end 239396 :level 2 :priority nil :tags (#(\"@no\" 0 3 ...)) 
:todo-keyword #(\"INPROGRESS\" 0 10 ...) :todo-type todo :post-blank 0 
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 218742 
:ID \"e1d8cff0-9449-4f52-b822-08d8c0bd9196\" :title 
(#(\"xxx\" 0 31 ...)) :parent (headline ...) 
:cached t :org-element--cache-sync-key nil)) :org-element--cache-sync-key nil))"
Backtrace:
  org-element-cache diagnostics(XXX.org): Added new element with nil key: 
"(property-drawer (:begin 284038 :end 284154 :contents-begin 284054 
:contents-end 284145 :post-blank 0 :post-affiliated 284038 :mode planning 
:granularity element))"
  

[OT] email opens (was: Link from orgmode file to E-Mail (using kmail or notmuch))

2023-01-28 Thread Gregor Zattler
Hi Jean, org-mode developers,
* Jean Louis  [2023-01-24; 22:01 +03]:
> To understand what is widely used e-mail file format, one has to see
> what are widely used e-mail clients.
>
> Maybe this picture may help:
> https://d27jswm5an3efw.cloudfront.net/app/uploads/2021/04/most-popular-email-clients-graph.jpeg
>
> or this one:
>
> https://www.oberlo.com/media/1673256706-most-used-email-clients-worldwide.png?fit=max=webp=1800

The data used in the second link actually comes from
litmus.com, they do such statistics on a regular basis.  For
the first link I cannot tell, but the numbers are very
similar to the litmus blog post on April 2021.

> Those are by majority all web software clients.

Yes, because what they are measuring is "email opens" via
web pixels and such tracking technologies.  That's might be
a reason why Thunderbird does not show up there.

So while this data somehow shows the sad state of affairs,
it is not relevant to the question of linking to emails.
Obviously Emacs caters to a tiny niche, yes.  But how does
it do or should do?

Ciao; Gregor



[BUG] org-element-cache warning while capturing [9.6 (release_9.6-204-g2f7052.dirty @ /home/grfz/src/org-mode/lisp/)]

2023-01-10 Thread Gregor Zattler
Dear org-mode developers, I caught this org-element--cache:
Warning(*Capture*) with `max-lisp-eval-depth` set to 32000.
With a value of 16000 I got
org-capture: Capture abort: Lisp nesting exceeds ‘max-lisp-eval-depth’: 16001
With a value of 16 I got a segfault and the backtrace
was so huge it took too long to generate it.



So this is with 

Emacs  : GNU Emacs 30.0.50 (build 3, x86_64-pc-linux-gnu, cairo version 1.16.0)
 of 2023-01-04
Package: Org mode version 9.6 (release_9.6-204-g2f7052.dirty @ 
/home/grfz/src/org-mode/lisp/)

and max-lisp-eval-depth set to 32000:


 ■  Warning (org-element-cache): org-element--cache: Warning(*Capture*): (nil) 
Cached element is incorrect in *Capture*. (Cache tic up to date: "yes") 
Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The element is: "(headline (:raw-value \"7f8d26507d7a6f4104411c314ed8adcf\" 
:begin 1 :end 267 :pre-blank 0 :contents-begin 17 :contents-end 267 
:robust-begin 60 :robust-end 265 :level 1 :priority nil :tags nil :todo-keyword 
\"TODO\" :todo-type todo :post-blank 0 :footnote-section-p nil :archivedp nil 
:commentedp nil :post-affiliated 1 :ID \"%(org-id-new)\" :title 
\"7f8d26507d7a6f4104411c314ed8adcf\" :mode first-section :granularity element 
:cached t :parent (org-data (:begin 1 :contents-begin 1 :contents-end 267 :end 
267 :robust-begin 3 :robust-end 265 :post-blank 0 :post-affiliated 1 :path nil 
:mode org-data :CATEGORY nil :cached t)) :org-element--cache-sync-key (1 . 1)))"
 The real element is: "(headline (:raw-value 
\"7f8d26507d7a6f4104411c314ed8adcf\" :begin 1 :end 265 :pre-blank 0 
:contents-begin 17 :contents-end 265 :robust-begin 60 :robust-end 263 :level 1 
:priority nil :tags nil :todo-keyword #(\"TODO\" 0 4 (face (org-todo 
org-level-1) fontified t)) :todo-type todo :post-blank 0 :footnote-section-p 
nil :archivedp nil :commentedp nil :post-affiliated 1 :ID \"%(org-id-new)\" 
:title \"7f8d26507d7a6f4104411c314ed8adcf\" :mode first-section :granularity 
element :parent (org-data (:begin 1 :contents-begin 1 :contents-end 265 :end 
265 :robust-begin 3 :robust-end 263 :post-blank 0 :post-affiliated 1 :path nil 
:mode org-data :CATEGORY nil"
 Cache around :begin:
nil
(headline (:raw-value "%? %^{}G" :begin 1 :end 267 :pre-blank 0 :contents-begin 
17 :contents-end 267 :robust-begin 60 :robust-end 265 :level 1 :priority nil 
:tags nil :todo-keyword "TODO" :todo-type todo :post-blank 0 
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 1 :ID 
"%(org-id-new)" :title "%? %^{}G" :mode first-section :granularity element 
:cached t :parent (org-data (:begin 1 :contents-begin 1 :contents-end 267 :end 
267 :robust-begin 3 :robust-end 265 :post-blank 0 :post-affiliated 1 :path nil 
:mode org-data :CATEGORY nil :cached t)) :org-element--cache-sync-key (1 . 1)))
nil
Backtrace:
  org-element-cache diagnostics(*Capture*): org-element-cache: Finished 
process. The cache size is 2. The remaining sync requests: "([16 17 107 160 ... 
0])"
  org-element-cache diagnostics(*Capture*): Phase 0 deleted all elements in 
cache after 16!
  org-element-cache diagnostics(*Capture*): Decreasing cache size to 2
  org-element-cache diagnostics(*Capture*): removing (1 . 16)::"(section 
(:begin 17 :end 107 :contents-begin 17 :contents-end 107 :robust-begin 17 
:robust-end 105 :post-blank 0 :post-affiliated 17 :mode section :granularity 
element :cached t :parent (headline (:raw-value \"%? %^{}G\" :begin 1 :end 267 
:pre-blank 0 :contents-begin 17 :contents-end 267 :robust-begin 60 :robust-end 
265 :level 1 :priority nil :tags nil :todo-keyword \"TODO\" :todo-type todo 
:post-blank 0 :footnote-section-p nil :archivedp nil :commentedp nil 
:post-affiliated 1 :ID \"%(org-id-new)\" :title \"%? %^{}G\" :mode 
first-section :granularity element :cached t :parent (org-data ...) 
:org-element--cache-sync-key (1 . 1))) :org-element--cache-sync-key (1 . 16)))"
  org-element-cache diagnostics(*Capture*): Phase 0
  org-element-cache diagnostics(*Capture*): org-element-cache: Processing 
request [16 17 107 160 (headline (:raw-value "%? %^{}G" :begin 1 :end 267 
:pre-blank 0 :contents-begin 17 ...)) 0] up to 85-267, next: nil
  org-element-cache diagnostics(*Capture*): Syncing down to 85-267
  org-element-cache diagnostics(*Capture*): Adding new phase 0 request
  org-element-cache diagnostics(*Capture*): Submitting new synchronization 
request for [85..267]흙-2
  org-element-cache diagnostics(*Capture*): org-capture is about to modify 
text: warning nil
  org-element-cache diagnostics(*Capture*): After change
  org-element-cache diagnostics(*Capture*): org-capture is about to modify 
text: warning nil
  org-element-cache diagnostics(*Capture*): Extending to non-robust element 
"(section (:begin 17 :end 107 :contents-begin 17 :contents-end 107 
:robust-begin 17 :robust-end 105 :post-blank 0 :post-affiliated 17 :mode 
section :granularity element :cached t :parent 

[BUG] hyperbole action key on path name results in org-element-cache warning [9.6-pre (release_9.5.5-997-ge58bd0 @ /home/grfz/src/org-mode/lisp/)]

2022-10-21 Thread Gregor Zattler


Dear org-mode and hyperbole developers, hitting hyperbole's
action-key with point in "~/src/org-mode/contrilb/lisp" in a
*Pp Eval Output* buffer holding my complete load-path
resulted in this org-element--cache warning:

 ■  Warning (org-element-cache): org-element--cache: Org parser error in *Pp 
Eval Output*::5288. Resetting.
 The error was: (error "rx ‘**’ range error")
 Backtrace:
"  backtrace-to-string(nil)
  org-element-at-point()
  org-element-context()
  hsys-org-link-at-p()
  ibtypes::org-link-outside-org-mode()
  ibut:at-p()
  hbut:at-p()
  eval((hbut:at-p))
  hkey-execute(nil)
  action-key-internal()
  action-key()
  funcall-interactively(action-key)
  call-interactively(action-key nil nil)
  command-execute(action-key)
"
 Please report this to Org mode mailing list (M-x org-submit-bug-report).

I wanted to know if this directory exists (it doesn't) and
thought it was easiest to use action-key in order to visit
it.


I assume hyperbole wrongly assumed that this was an org-mode
buffer and did something wrong with org-element, but I'm
only guessing, since this is way above my elisp foo.

I hope this somehow helps.

Emacs  : GNU Emacs 29.0.50 (build 2, x86_64-pc-linux-gnu, cairo version 1.16.0)
 of 2022-10-19
Package: Org mode version 9.6-pre (release_9.5.5-997-ge58bd0 @ 
/home/grfz/src/org-mode/lisp/)

and hyperbole 8.0.0.

Ciao,
-- 
Gregor



Re: [PATCH] org-manual: Remove mention of print edition

2022-10-16 Thread Gregor Zattler
Hi Bastien,
* Bastien  [2022-10-16; 07:48 +02]:
> I think it is good to remember that Network Theory Ltd. was the
> original publisher of the printed manual, as people may find others
> options online now.

Yes, one can still buy the book used online.  But then
again: Version 7.3 was released 12 years how useful is this
manual now?

But I'm OK both ways.

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-



[PATCH] org-manual: Remove mention of print edition

2022-10-15 Thread Gregor Zattler
Dear org-mode developers, the manual still links to
network-theory.co.uk for the printed version of the manual.

But there is no service under this address any more (or
ATM).  Even if this was only a temporary hiccup version 7.3
of the manual is quite outdated now.  Therefore I propose to
remove the respective paragraph, see attached patch.

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-
>From cdbe7bfd26aaff292156caf6391cd0acfba6d446 Mon Sep 17 00:00:00 2001
From: Gregor Zattler 
Date: Sat, 15 Oct 2022 13:15:51 +0200
Subject: [PATCH] org-manual: Remove mention of print edition

* doc/org-manual.org (Summary): Remove mention of print edition since
network-theory.co.uk is no more.
---
 doc/org-manual.org | 4 
 1 file changed, 4 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index a278eb222..d95a9ef6e 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -73,10 +73,6 @@ of Org, as well as additional information, frequently asked questions
 (FAQ), links to tutorials, etc.  This page is located at
 [[https://orgmode.org]].

-#+cindex: print edition
-An earlier version (7.3) of this manual is available as a [[http://www.network-theory.co.uk/org/manual/][paperback
-book from Network Theory Ltd.]].
-
 ** Installation
 :PROPERTIES:
 :DESCRIPTION: Installing Org.
--
2.38.0.15.gbbe21b64a0



Re: [BUG, confirmed] org-clock-in calling org-clock-sum fails leaving incomplete CLOCK line when encountering existing malformed CLOCK lines

2022-10-14 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2022-10-13; 14:15 +08]:
> Ihor Radchenko  writes:
>>> Please see the attached test.org and call Emacs like so:
>>> /usr/local/bin/emacs-29.0.50 -Q -L ~/src/org-mode/lisp /tmp/test.org --eval 
>>> '(switch-to-buffer "test.org")' -f org-clock-in
>> Confirmed using the described steps.
>
> Fixed on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3790bf8ea1d070055a989f0b9587948e07877977

thanks, I now get an iformational message in such cases.
This allows for searching for the culprit.

Ciao,
--
Gregor



Re: [External] : Re: org-mode compile issue this morning - how to report this?

2022-08-25 Thread Gregor Zattler
Hi Daniel,
* Daniel Ortmann  [2022-08-25; 09:36 -05]:
> FYI,
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57394
>
> Lars at gnu says it is fixed in emacs 29
> The bug's web page says, more specifically, "bug marked as fixed in
> version 29.1"
>
> ... I can't find emacs 29.1; my 'git pull' still says 29.0 and I don't
> see any 29.1 branches available.
> I have not been able to test and verify the fix.

it's this commit on the emacs master branch:

commit b28b2cefaea0d7846ab9a45dc92f68ad00e92085
Author: Lars Ingebrigtsen 
Date:   Thu Aug 25 14:54:49 2022 +0200

Fix warning about obsoleted generalized variables

* lisp/emacs-lisp/bytecomp.el (byte-compile-warn-obsolete):
Autoload so that the call here from gv.el (about obsolete
generalized variables) doesn't bug out (bug#57394).

Do a git fetch --all; git pull on the emacs master branch
and you are able to test the fix.  I cannot tell since my
machine is slow and still in the early stadium of building
emacs.



Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-



[BUG] Warning (org-element-cache): org-element--cache: Org parser error in notmuch-show.el::10751. Resetting. [9.5.4 (release_9.5.4-702-g5a49cc @ /home/grfz/src/org-mode/lisp/)]

2022-08-12 Thread Gregor Zattler
Dear org-mode developers, Ihor,

I just got this warning:

Warning (org-element-cache): org-element--cache: Org parser error in 
notmuch-show.el::10751. Resetting.
 The error was: (error "rx ‘**’ range error")
 Backtrace:
"  backtrace-to-string(nil)
  org-element-at-point()
  org-element-context()
  hsys-org-link-at-p()
  ibtypes::org-link-outside-org-mode()
  ibut:at-p()
  hbut:at-p()
  hkey-execute(nil)
  action-key-internal()
  action-key()
  funcall-interactively(action-key)
  command-execute(action-key)
"
 Please report this to Org mode mailing list (M-x org-submit-bug-report).


I don't know what triggered it, especially not in an elisp
buffer.

Just an hour ago, or some such, I lowered
org-element--cache-self-verify-frequency from 1.0 to 0.1.
Now I set it to 1.0 again.


I deleted the "current state" part of this template due to
privacy concerns.  If you need specific variable values,
please tell me and I will provide them.[1]



Emacs  : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.16.0)
 of 2022-08-02
Package: Org mode version 9.5.4 (release_9.5.4-702-g5a49cc @ 
/home/grfz/src/org-mode/lisp/)




-- 
Gregor

[1] For me:  [[file:~/tmp/2022-08-12-org-element-cache---current-state::current 
state:]]



Re: Warning (org-element-cache): org-element--cache: Warning( *helm-org-rifle-fontify*): Unregistered buffer modifications detected. Resetting.

2022-07-08 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2022-07-08; 12:25]:
> Thanks for reporting! The backtrace is very helpful.
>
> Can you please try the attached patch and let me know if it helps?

thanks for the patch.  I first tried to provoke again the
warnings but did not succeed, although I use the same emacs
and org-mode builds.  But my org-mode files are a bit
different now.  Anyway:  No warnings.

I then updated org-mode, applied your patch: No warning
either.  I then purged ~/.cache/org/persist and restarted
emacs: No warnings.

So while there are no downsides regarding my small test with
your patch, I cannot verify that it addresses the problem,
because I was not able to reproduce it :-(  Sorry about that.

Thanks for your attention, Gregor



Warning (org-element-cache): org-element--cache: Warning( *helm-org-rifle-fontify*): Unregistered buffer modifications detected. Resetting.

2022-07-07 Thread Gregor Zattler
Dear org-mode developers, Ihor, I got these warnings
immediately after I purged ~/.cache/org-persist, started
emacs/org-mode and tried to find some node via org-rifle.

Actually I did the purge and restart, because I got very
similar warnings before.

I don't know if this is useful, please tell me if there is
anything I can do to help investigate.


-- Ciao; Gregor
--
-... --- .-. . -.. ..--.. ...-.-

Warning (org-element-cache): org-element--cache: Warning( 
*helm-org-rifle-fontify*): Unregistered buffer modifications detected. 
Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The buffer is:  *helm-org-rifle-fontify*
 Current command: nil
 Backtrace:
"  backtrace-to-string(nil)
  org-element--cache-sync(#)
  apply(org-element--cache-sync #)
  timer-event-handler([t 0 0 522546 nil org-element--cache-sync (#) idle 725999 nil])
  helm-read-from-minibuffer(nil nil nil nil nil nil nil)
  helm-internalname . \"diary.org\") (buffer . #) 
(candidates . #) 
(keymap keymap ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 
... ... ... ... ... ... ... ... ...) (action . helm-org-rifle-actions) 
(multiline . t) (requires-pattern . 0) (filtered-candidate-transformer 
helm-fuzzy-highlight-matches) (volatile . t) (match helm-mm-exact-match 
helm-mm-match identity) (redisplay . identity) (header-line . ...) (multimatch 
. t) (after-init-hook helm-org-rifle-set-input-idle-delay) (group . helm)) 
((name . \"izt.org\") (buffer . #) (candidates . #) (keymap keymap ... ... 
... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 
... ... ...) (action . helm-org-rifle-actions) (multiline . t) 
(requires-pattern . 0) (filtered-candidate-transformer 
helm-fuzzy-highlight-matches) (volatile . t) (match helm-mm-exact-match 
helm-mm-match identity) (redisplay . identity) (header-line . ...) (multimatch 
. t) (after-init-hook helm-org-rifle-set-input-idle-delay) (group . helm)) 
((name . \"notmuch-startpage.org\") (buffer . #) 
(candidates . #) 
(keymap keymap ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 
... ... ... ... ... ... ... ... ...) (action . helm-org-rifle-actions) 
(multiline . t) (requires-pattern . 0) (filtered-candidate-transformer 
helm-fuzzy-highlight-matches) (volatile . t) (match helm-mm-exact-match 
helm-mm-match identity) (redisplay . identity) (header-line . ...) (multimatch 
. t) (after-init-hook helm-org-rifle-set-input-idle-delay) (group . helm)) 
((name . \"grfz.org\") (buffer . #) (candidates . #) (keymap keymap ... ... 
... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 
... ... ...) (action . helm-org-rifle-actions) (multiline . t) 
(requires-pattern . 0) (filtered-candidate-transformer 
helm-fuzzy-highlight-matches) (volatile . t) (match helm-mm-exact-match 
helm-mm-match identity) (redisplay . identity) (header-line . ...) (multimatch 
. t) (after-init-hook helm-org-rifle-set-input-idle-delay) (group . helm)) 
((name . \"configuration.org\") (buffer . #) 
(candidates . #) 
(keymap keymap ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 
... ... ... ... ... ... ... ... ...) (action . helm-org-rifle-actions) 
(multiline . t) (requires-pattern . 0) (filtered-candidate-transformer 
helm-fuzzy-highlight-matches) (volatile . t) (match helm-mm-exact-match 
helm-mm-match identity) (redisplay . identity) (header-line . ...) (multimatch 
. t) (after-init-hook helm-org-rifle-set-input-idle-delay) (group . helm))) nil 
nil nil nil nil nil nil nil)
  helmname . \"diary.org\") (buffer . #) (candidates . 
#) (keymap keymap 
... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 
... ... ... ... ...) (action . helm-org-rifle-actions) (multiline . t) 
(requires-pattern . 0) (filtered-candidate-transformer 
helm-fuzzy-highlight-matches) (volatile . t) (match helm-mm-exact-match 
helm-mm-match identity) (redisplay . identity) (header-line . ...) (multimatch 
. t) (after-init-hook helm-org-rifle-set-input-idle-delay) (group . helm)) 
((name . \"izt.org\") (buffer . #) (candidates . #) (keymap keymap ... ... 
... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 
... ... ...) (action . helm-org-rifle-actions) (multiline . t) 
(requires-pattern . 0) (filtered-candidate-transformer 
helm-fuzzy-highlight-matches) (volatile . t) (match helm-mm-exact-match 
helm-mm-match identity) (redisplay . identity) (header-line . ...) (multimatch 
. t) (after-init-hook helm-org-rifle-set-input-idle-delay) (group . helm)) 
((name . \"notmuch-startpage.org\") (buffer . #) 
(candidates . #) 
(keymap keymap ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 
... ... ... ... ... ... ... ... ...) (action . helm-org-rifle-actions) 
(multiline . t) (requires-pattern . 0) (filtered-candidate-transformer 
helm-fuzzy-highlight-matches) (volatile . t) (match helm-mm-exact-match 
helm-mm-match 

Re: Got an org-element warning: How to report?

2022-06-27 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2022-06-27; 19:38]:
> Gregor Zattler  writes:
>>> Are you seeing the same warning? ("Invalid search bound ...")
>>
>> no, it's
>>
>> Cached element is incorrect in xxx.org. (Cache tic up to date: "yes") 
>> Resetting.
>>
>> The element is: "(headline (:raw-value
>>  The real element is: "(fixed-width (:begin...
>>  Cache around :begin:
>> (headline (:raw-value...
>>
>>
>> And there is no backtrace, I'm still working in this Emacs
>> session at the moment.
>
> This one is tricky. I can only try to do something if you observe the
> warning frequently.
>
> If you do, you can add
> (setq org-element--cache-self-verify 'backtrace)
> (setq org-element--cache-self-verify-frequency 1.0)
>
> to your config

ok, did so.

> and later share (possibly privately) the backtrace.

ok, will do if this happens.


Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-



Re: Got an org-element warning: How to report?

2022-06-27 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2022-06-27; 18:20]:
> Gregor Zattler  writes:
>
>> Hello org-mode devs, Ihor,
>>
>> today, when opening several org files for my agenda, I got a
>>
>> Warning (org-element-cache): ...
>
> Thanks for reporting!
> This is probably similar to
> https://list.orgmode.org/87a69ypk1m.fsf@localhost/T/#t
>
> Are you seeing the same warning? ("Invalid search bound ...")

no, it's

Cached element is incorrect in xxx.org. (Cache tic up to date: "yes") Resetting.

The element is: "(headline (:raw-value
 The real element is: "(fixed-width (:begin...
 Cache around :begin:
(headline (:raw-value...


And there is no backtrace, I'm still working in this Emacs
session at the moment.

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-



Got an org-element warning: How to report?

2022-06-27 Thread Gregor Zattler
Hello org-mode devs, Ihor,

today, when opening several org files for my agenda, I got a

Warning (org-element-cache): ...

which is 7100 characters long and contains private data
(filenames headlines, ...)

Is this interesting for debugging, if so, does it still make
sense if I first anonymize the sensitive data with xx?

This is with a newly build emacs and org-mode main from
yesterday.

I will store the warnings buffer for a few days in case it's
interesting.


Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-



Re: [BUG] org-element-warnings when accidentially inserting "z" into timestamp [9.5.3 (release_9.5.3-471-gebbef7.dirty @ /home/grfz/src/org-mode/lisp/)]

2022-06-01 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2022-05-31; 13:01]:
> Gregor Zattler  writes:
>
>> Now I realized, that even after quitting and restarting
>> Emacs, I cannot insert a timestamp, I get the following
>> error message:
>>
>> org-parse-time-string: Not an Org time string: [20zznn22-05-30 Mo 11:34]
>>
>> And then there is a dangling
>>
>> CLOCK:
>>
>> line without timestamps at the expected line in my org file.
>>
>> It took a while till I realized that there was a corrupted
>> timestamp in my org file a few clock lines below.
>>
>> It would be helpful, if the message contained the file name
>> and probably even the line number.
>
> Could you please create an example file and detail the steps how you got
> the error?

Please see the attached test.org and call Emacs like so:


/usr/local/bin/emacs-29.0.50 -Q -L ~/src/org-mode/lisp /tmp/test.org --eval 
'(switch-to-buffer "test.org")' -f org-clock-in




test.org
Description: application/org


Thanks for looking into this.

Ciao; Gregor


Re: [BUG] org-element-warnings when accidentially inserting "z" into timestamp [9.5.3 (release_9.5.3-471-gebbef7.dirty @ /home/grfz/src/org-mode/lisp/)]

2022-05-30 Thread Gregor Zattler
Hi Ihor,
* Ihor Radchenko  [2022-05-30; 19:51]:
> Gregor Zattler  writes:
>
>> I accidentally inserted a "z" into a closing timestamp in a
>> clockline like so: 20zznn22-05-30
>>
>> This happened because I use key chors and didn't enter the
>> chord fast enough.
>>
>>
>> This produced a *Warnings* buffer of 2,3 MB size.
>
> Possibly a duplicate of
> https://list.orgmode.org/orgmode/87tuh88kjv.fsf@localhost/
>
> I just pushed a fix upstream. Can you please check again with the latest
> Org?

this seems to have solved the warnings -Problem.  No warning
any more (I saved the org-persistent cache and tested with
the cache which was involved in the bug reprot and with a
fresh one).

Now I realized, that even after quitting and restarting
Emacs, I cannot insert a timestamp, I get the following
error message:

org-parse-time-string: Not an Org time string: [20zznn22-05-30 Mo 11:34]

And then there is a dangling

CLOCK:

line without timestamps at the expected line in my org file.

It took a while till I realized that there was a corrupted
timestamp in my org file a few clock lines below.

It would be helpful, if the message contained the file name
and probably even the line number.


Thanks for fixing this so quick.


Ciao,
--
Gregor



[BUG] org-element-warnings when accidentially inserting "z" into timestamp [9.5.3 (release_9.5.3-471-gebbef7.dirty @ /home/grfz/src/org-mode/lisp/)]

2022-05-30 Thread Gregor Zattler
Ciao,

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Dear org mode developers, Ihor,

I accidentally inserted a "z" into a closing timestamp in a
clockline like so: 20zznn22-05-30

This happened because I use key chors and didn't enter the
chord fast enough.


This produced a *Warnings* buffer of 2,3 MB size.

Next time I provoced this it was only 66 KB *Warnings*

I use org mode as build a few weeks ago, dunno if this still
of interest.

Since the backtrace contains private information I would
rather not send it to the list, but to an individual maybe!?


If this backtraces are of interest, whom should I send them
to?


Ciao; Gregor

Emacs  : GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.16.0)
 of 2022-05-15
Package: Org mode version 9.5.3 (release_9.5.3-471-gebbef7.dirty @ 
/home/grfz/src/org-mode/lisp/)
--
Gregor



Re: what would cause failure in template for org capture?

2021-07-27 Thread Gregor Zattler
Hi No, Eric,

* No Wayman  [2021-07-23; 23:03]:
>> from an earlier thread, I recall you mentioned you were using
>> native
>> compilation? This is almost certainly the cause of your problem.
>
> This does smell like a byte-compilation problem.
> Seems to be a failure with any interactive, single-character
> %-escaped patterns in a template string (e.g. %^g, %^C, %^t).
> I've narrowed it down to a call to pcase in
> `org-capture-fill-template'.
> As Eric mentions, the problem disappears if the function is
> re-evaluated/instrumented.
> I have disabled native compilation and the problem persists with
> just a freshly byte-compiled elc of org-capture.
> Tested this with the following recipe:
>
> 1. eval the following:
> (org-capture-fill-template "%^t") ;fails with `unrecognized
> template placeholder: %^t`
> 2. eval org-capture-fill-template's definition, and then re-eval
> the above. Works properly. User is prompted for a time.
> 3. byte compile org-capture-fill-template: (byte-compile
> #'org-capture-fill-template)
> 4. eval (org-capture-fill-template "%^t") ; error is back
>
>
> Running Emacs 28.0.50
> Repository revision: 903ecd7bea7d8f99a7dc84150728219283d79bf0
> Repository branch: master

this is now emacs bug 49746
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49746

Because of No's email I did a git bisect and found a commit
which changes the byte compiler.

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-




Re: Getting Org-Crypt to work (doc bug?)

2020-09-14 Thread Gregor Zattler
Hi David,
* David Masterson  [2020-09-13; 17:11]:
> Yes, gpg-agent is installed and appears to have been started in
> background.  My O/S is Debian on a Chromebook.
>
> I start Emacs via 'xterm -e emacs' and just noticed (thanks to you) that
> I'm getting a textual popup on the xterm asking for the
> passphrase. Given that, everything works.
>
> So, you're saying that the textual popup is the correct mechanism for
> getting the passphrase?

That's one possible way.  If you want to have a graphical
dialog box, check which pinentry packages are installed:

$ dpkg -l '*pinentry*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion  Architecture Description
+++-===---==
un  pinentry  (no description available)
ii  pinentry-curses 1.1.0-2  amd64curses-based PIN or pass-phrase 
entry dialog for GnuPG
ii  pinentry-doc1.1.0-2  all  documentation for pinentry 
packages
un  pinentry-gnome3   (no description available)
un  pinentry-gtk2 (no description available)
ii  pinentry-qt 1.1.0-2  amd64Qt-based PIN or pass-phrase entry 
dialog for GnuPG
un  pinentry-qt4  (no description available)
un  pinentry-x11  (no description available)

as you see, at my system, there are two pinentry packages
installed (besides the docs): pinentry-curses for terminal
while pinentry-qt provides a graphical dialog box.  I choose
pinentry-qt, because it had fewer dependencies and was
smaller than the other options.

If your system lacks a graphical pinentry, install one.




Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-




Re: Getting Org-Crypt to work (doc bug?)

2020-09-13 Thread Gregor Zattler
Hi David,
* David Masterson  [2020-09-12; 19:09]:
> I'm trying to get org-crypt to work, but I'm missing something.
> Following the Org-Crypt Info page, I've set it up for symmetric
> encryption and added a :crypt: tag to a header.  When I try to save the
> file, it reports that no key was specified, so it will do symmetric
> encryption.  And then it freezes.  C-g will unfreeze, but the buffer is
> slightly messed up like it started working on something, but waited for
> an external command? GPG is installed.  What am I missing?

I assume it waits for a passphrase.  Do you have gpg-agent
installed?  What is your operating system?


Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-




Re: [bug] error on RET in read-only buffer with org-return-follows-link set to t

2020-05-15 Thread Gregor Zattler
Hi Nicolas, Kévin,

thanks to both of you: It works again for me.

Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-
* Nicolas Goaziou  [2020-05-15; 00:49]:
> Kévin Le Gouguec  writes:
>
>> Shouldn't the call to org-return be wrapped in (call-interactively …)
>> though?
>
> Indeed. Done. Thank you.




[bug] error on RET in read-only buffer with org-return-follows-link set to t

2020-05-14 Thread Gregor Zattler
Dear Kévin, org-mode developers, 

with `org-return-follows-link` set to `t` in a read-only
buffer I now get a `Buffer is read-only: #` error when pressing ENTER/RETURN
with point on an org-mode link.

This used to work (opening the org-mode link) till

d3e6b58004997c5a9eeea82f96723c0f74480ab8 is the first bad commit
commit d3e6b58004997c5a9eeea82f96723c0f74480ab8
Author: Kévin Le Gouguec 
Date:   Tue May 5 19:01:07 2020 +0200

Make RET and C-j obey `electric-indent-mode'

* lisp/org-compat.el (org-return-indent): Deprecate this command.
* lisp/org-keys.el (org-mode-map): Rebind C-j to a command emulating
`electric-newline-and-maybe-indent'.
* lisp/org.el (org-cdlatex-environment-indent): Stop using the now
obsolete function.
(org--newline): New helper function.
(org-return): Use it to transparently handle `electric-indent-mode'.
(org-return-and-maybe-indent): New command to emulate
`electric-newline-and-maybe-indent' while taking care of Org special
cases (tables, links, timestamps).
* testing/lisp/test-org.el (test-org/with-electric-indent,
test-org/without-electric-indent): New tests.
* testing/org-test.el (org-test-with-minor-mode): New helper to set a
minor mode to a specific state, and reset it afterward.

:04 04 85f261b701133d4be047c1a2e8872b25f3e0c7e7 
21fe88d69e48ac3d24d233cbf07fe0084cde853e M  etc
:04 04 a677d2134361d2b023f252c188aebdeef9826896 
4bdbb34abe7eaad343932d33a03c823b2cae0e24 M  lisp
:04 04 9ecba96d2748f0e7ff5430ec0fcf8c175875621f 
f6e7b54445ac19d1b7c59d4d54bd9b4a19126245 M  testing


I use this dozens of times a day and it would be convenient
if it was possible to resurrect the old behaviour.


Thanks for your attention and for developing org-mode,
Gregor 
-- 
 -... --- .-. . -.. ..--.. ...-.-




[PATCH] org-screen.el: replace obsolete function

2019-12-15 Thread Gregor Zattler
* contrib/lisp/org-screen.el (org-screen): replace obsolete function
`insert-string' with `insert'.
---
 contrib/lisp/org-screen.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/lisp/org-screen.el b/contrib/lisp/org-screen.el
index 6b870f229..948e93adf 100644
--- a/contrib/lisp/org-screen.el
+++ b/contrib/lisp/org-screen.el
@@ -64,7 +64,7 @@
   (interactive "MScreen name: ")
   (save-excursion
 (org-screen-helper name "-S"))
-  (insert-string (concat "[[screen:" name "]]")))
+  (insert (concat "[[screen:" name "]]")))

 (defun org-screen-buffer-name (name)
   "Returns the buffer name corresponding to the screen name given."
--
2.11.0




Re: [O] Compile failure

2019-06-25 Thread Gregor Zattler
Hi Eric, Klaushal,
* "Fraga, Eric"  [2019-06-24; 18:04]:
> On Monday, 24 Jun 2019 at 11:48, Kaushal Modi wrote:
>> That issue on Emacs master is fixed now for me.
>
> If it happens not to be, for Bill: just go to your emacs and
>
>  git checkout 63b29f81075a3fdca70348f023d3ebb37a4f2a63

I assume you both know this will pin your git repo to this very
commit.

If one wants to use the emacs development version it's better to
do

git pull
git co -f master

an you will use cutting edge of emacs development.



>  make clean
>  make && make install
>
> and things should work.  They do for me.
Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-




[O] [PATCH] * doc/org-manual.org (External Links): Fix URL

2019-06-01 Thread Gregor Zattler


---
 doc/org-manual.org | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 469e16402..583840a74 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -3081,7 +3081,7 @@ External links are URL-like locators.  They start with a 
short
 identifying string followed by a colon.  There can be no space after
 the colon.  The following list shows examples for each link type.

-| =http://www.astro.uva.nl/=dominik=| on the web |
+| =https://staff.science.uva.nl/c.dominik/= | on the web |
 | =doi:10.1000/182= | DOI for an electronic resource |
 | =file:/home/dominik/images/jupiter.jpg=   | file, absolute path|
 | =/home/dominik/images/jupiter.jpg=| same as above  |
--
2.11.0




Re: [O] [RFC] org-style

2019-05-10 Thread Gregor Zattler
Hi Marco, org-mode developers and users,
* Marco Wahl  [2019-05-10; 13:55]:

> What do you think about this?  Is this worth to merge into org mode?

This is nice, I played with it and see it's merit, but I think
this should not be enabled by default.

Even if the user had to enable it first via customization, this
version of the code has another drawback: if it actually touches
the buffer in order to change the number of blank lines it at the
same time removes the indentation of the first non blank line.
This might not be what the user wishes and should either not be
the case or also disabled per default:

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] Logging :LOGBOOK: entries to a heading in org-mode without TODO state changes

2019-04-09 Thread Gregor Zattler
Hi Daryl,
* Daryl Manning  [2019-04-08; 22:46]:
> I have org-mode set up at the moment to log changes in my TODO states (at
> the moment, TODO, CHASE, GAVE, KILL, DONE) as well as deadline changes and

would you please elaborate on the semantics of these (esp. chase,
gave)?

> reschedules into a logbook drawer. That's working great.
>
> However, I have begun using org-contacts as an ersatz CRM for myself and
> keeping track of mails, meets, and other administrivia tracking people I'm
> interacting with.
>
> I'd love to have a way to as easily use something CTRL-C-T and then have
> the ability to log an item into a Logbook drawer under each
> heading name.

There's org-add-note, bound by default to C-c C-z, which does
exactly that.  It even works from the agenda.

> Is there a way to do this easily without hacking TODO states? Or are there
> other ways people are doing this to achieve the same goal (I'm also hoping
> to set PING deadlines on people so that I am making sure to recontact them
> at various intervals over time, but still trying to puzzle that out... =]
> ).

I tried to use org-habit for this, but it gets clumsy, if you
want to contact somebody round about every 60 days or so.


Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-




[O] orgalist-mode: wrong indentation in message mode after recent change in emacs

2019-04-01 Thread Gregor Zattler
Dear org-mode developers, hello Nicolas,
 I use orgalist-mode while writing emails in
 notmuch-message-mode.  Today I updated emacs (from git), and
 since then, the second line of a paragraph get's indented
 (and succeeding lines too).

As demonstrated with this email.  While I write this email with
   my configurations, I checked with emacs -Q as follows: visited
   one org file (in order for org-mode to load), visited
   orgalist.el, eval'ed this buffer and started writing an email:
   bang! indented succeeding lines.



I bisected emacs like so:

make ; src/emacs -Q --eval '(org-mode)' -l 
~/.emacs.d/elpa-27.0/orgalist-1.9/orgalist.el -f compose-mail --eval 
'(orgalist-mode)' -f end-of-buffer


and this is the relevant commit:

2e3deb09bd42d22a9b354937ce63b151fb493d8a is the first bad commit
commit 2e3deb09bd42d22a9b354937ce63b151fb493d8a
Author: Basil L. Contovounesios 
Date:   Sun Mar 31 19:39:54 2019 +0100

Do not set indent-line-function in text-mode

For discussion, see thread starting at:
https://lists.gnu.org/archive/html/emacs-devel/2019-03/msg01012.html
* lisp/textmodes/text-mode.el (text-mode): Do not reset
indent-line-function to its global default value of indent-relative.
* doc/lispref/modes.texi (Example Major Modes):
* etc/NEWS: Document change accordingly.

:04 04 88d3790ae5446f2ef84b66733c2b9e9bd27676a8 
53a988cc46c8505b5751120b6f0813c5f252b171 M  doc
:04 04 0f12bd57efcc2a481b468ecefb0369ef3b3996c9 
055f07d1469cee692acc35ba9ce5ec2611a6f7db M  etc
:04 04 0c34b9e6e31c833a7c3c4e464e0ccbf597156850 
d330f001af22700ec84b0d1596571fa4548eafa8 M  lisp


I do not know what to do with this.


   Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] Multiple Indices

2019-03-02 Thread Gregor Zattler
Hi Robert,
* Robert Love  [2019-03-02; 16:29]:
> I don’t understand this advice.   I went looking for the source
> for the Org manual and found it IS written in Texinfo. This
> is version 8.2.10.   Is there a native Org mode manual written
> in Org?

Yes since version 9 I think.  It will be part of emacs when a
newer version is bundled with a released version of emacs. 

> If so, please provide the source location.

In the mean time:
https://code.orgmode.org/bzg/org-mode/raw/master/doc/org-manual.org

Ciao; Gregor 




Re: [O] Multiple Indices

2019-03-01 Thread Gregor Zattler
Hi Robert,
* Robert Love  [2019-02-28; 23:52]:
> I’m using Org mode to document some software.  When I see
> Texinfo used for this, I see that you can have a subject index
> and a variable index.  How do I achieve the same thing in Org
> mode?  Can someone point to examples of this?

I don't know anything about texinfo, but the Org-mode manual has
three indices.  You may have a look at doc/org-manual.org.

Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] [bug/regression]: org-babel-load-file gives error: wrong-type-argument listp "/home/grfz/.emacs.d/configuration.org"

2019-01-14 Thread Gregor Zattler
Hi Kyle, org-mode developers,
* Kyle Meyer  [2019-01-14; 17:10]:
> Kyle Meyer  writes:
>> Gregor Zattler  writes:
> [...]
>
>>> I did a git bisect on the org repo and got this:
>>> ba321d0e44b34840466dd386223f702615ff8562 is the first bad commit
>>
>> Sorry, that certainly looks to be my fault (specifically, my conflict
>> resolution merging maint's d64c9a996).  I'll have a look.
>
> Fixed by baa98a4a6fe93dd99fb624ad218fb3e1868cfde3.

Thank you very much for the quick fix.  It works again.

Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




[O] [bug/regression]: org-babel-load-file gives error: wrong-type-argument listp "/home/grfz/.emacs.d/configuration.org"

2019-01-14 Thread Gregor Zattler
Dear org-mode developers, I did a git pull half an hour ago, now I
cannot org-babel-load-file my configuration.org any more.  Normally I
use emacs as of git master but the (slightly different) error also
occours with emacs 25.1.1 (as of currents debian stable) (see below).

I did a git bisect on the org repo and got this:
ba321d0e44b34840466dd386223f702615ff8562 is the first bad commit


Thanks for your attention and your work on org-mode, Gregor


emacs 251.1:
File Edit Options Buffers Tools Debugger Help   

   
Debugger entered--Lisp error: (wrong-type-argument listp 
"/home/grfz/.emacs.d/configuration.org")

  
  nth(5 "/home/grfz/.emacs.d/configuration.org")

   
  file-attribute-modification-time("/home/grfz/.emacs.d/configuration.org") 

   
  (org-file-newer-than-p tangled-file (file-attribute-modification-time file))  

   
  (if (org-file-newer-than-p tangled-file (file-attribute-modification-time 
file)) nil (org-babel-tangle-file file tangled-file "emacs-lisp"))  

   
  (let* ((tangled-file (concat (file-name-sans-extension file) ".el"))) (if 
(org-file-newer-than-p tangled-file (file-attribute-modification-time file)) 
nil (org-babel-tangle-file file tangled-file "emacs-lisp")) (if compile (progn 
(byte-$
  org-babel-load-file("/home/grfz/.emacs.d/configuration.org")  

   
  mapc(org-babel-load-file ("/home/grfz/.emacs.d/configuration.org"))   

   
  eval-buffer(# nil "/home/grfz/.emacs.d/init.el" nil t)  ; 
Reading at buffer position 7565 

   
  load-with-code-conversion("/home/grfz/.emacs.d/init.el" 
"/home/grfz/.emacs.d/init.el" t t)  

 
  load("/home/grfz/.emacs.d/init" t t)  

   
  #[0 "^H\205\266^@ \306=\203^Q^@\307^H\310Q\202?^@ 
\311=\204^^^@\307^H\312Q\202?^@\313\307\314\315#\203*^@\316\202?^@\313\307\314\317#\203>^@\320\321\322!D\nB^R\323\202?^@\316\324^S\325^A\324\211#\210^K\324=\203e^@\326\327\330\307^H\$
  command-line()

   
  normal-top-level()


emacs 27:
Debugger entered--Lisp error: (wrong-type-argument listp 
"/home/grfz/.emacs.d/configuration.org")

  
  file-attribute-modification-time("/home/grfz/.emacs.d/configuration.org") 

   
  (org-file-newer-than-p tangled-file (file-attribute-modification-time file))  

   
  (if (org-file-newer-than-p tangled-file (file-attribute-modification-time 
file)) nil (org-babel-tangle-file file tangled-file "emacs-lisp"))  

   
  (let* ((tangled-file (concat (file-name-sans-extension file) ".el"))) (if 
(org-file-newer-than-p tangled-file 

Re: [O] Tasks performed on a certain day

2018-11-09 Thread Gregor Zattler
Hi Nicolas, org mode users and developers,
* Nicolas Goaziou  [2018-11-08; 18:34]:
> However, I think some users need to have multiple so-called events in
> the same headline, e.g., for irregularly repeating tasks.

Yes, I do this all the time.  For instance there is a heading for
visits at the dentist in my org file which contains plain
timestamps for every day I went there.  This is quite handy as
I'm able to tell when I was there with a glance at this list of
plain stamps.  This may be helpful when dealing with the
insurance company.

If a heading could only hold one event timestamp I would need
much more headings which look somewhat heavy because of the
markup, the way they are shown and most probably would also
feature a drawer each .  OTHT I could then archive all old visits
at the dentist, have a smaller org file but it would be more
difficult to reconstruct past dates with my dentist.  Because
then they would be scattered among other headings in the archive
file and the only way of finding out would be to generate an
agenda from the archive file.


Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




[O] Bug: manual still mentions orgstruct minor mode [9.1.14 (release_9.1.14-968-gfdb36d @ /home/grfz/src/org-mode/lisp/)]

2018-10-06 Thread Gregor Zattler
Dear org mode developers,

orgstruct minor mode is still mentioned as an usage example for
in-place conversion in org manuals chapter "12.18 Export in
Foreign Buffers".

I know and use package "orgalist" but I'm not sure if it makes
sense to mention a package at this point of the org manual.
Furthermore I do not use in-place conversions, therefore I cannot
propose another example/wordoing.


Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] need help with repeated tasks (won't reapeat)

2018-08-19 Thread Gregor Zattler
Hi Marco, org mode users,
* Marco Wahl  [2018-08-19; 13:46]:
> Gregor Zattler  writes:
>
>> Dear org mode users, I have problems with a repeated task.  I
>> want to clean something round about every 60 days.  I set up this
>> task in order to monitor my cleaning:
>>
>>
>> *** TODO Clean it
>> DEADLINE:<2018-08-12 So +.60d -9d>
>
> How about toggling the plus and the dot like so?
>
> DEADLINE:<2018-10-18 .+60d -9d>

You are spot on, this was the mistake I made and did not realize
although I reread the relevant manual section...

Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-





[O] need help with repeated tasks (won't reapeat)

2018-08-19 Thread Gregor Zattler
Dear org mode users, I have problems with a repeated task.  I
want to clean something round about every 60 days.  I set up this
task in order to monitor my cleaning:


*** TODO Clean it
DEADLINE:<2018-08-12 So +.60d -9d>
:PROPERTIES:
:LAST_REPEAT: [2018-05-30 Mi 16:01]
:REPEAT_TO_STATE: TODO
:END:
:LOGBOOK:
- State "DONE"   from "TODO"   [2018-05-30 Mi 16:01]
- State "DONE"   from "TODO"   [2018-03-26 Mo 16:47]
:END:


But when I do a C-c C-t (org-agenda-todo) with point on the
heading or on the corresponding line in the agenda, the task
switches simply to DONE and that's it.  It doesn't switch back to
TODO, the deadline is not shifted:

*** DONE Clean it
DEADLINE:<2018-08-12 So +.60d -9d>
:PROPERTIES:
:LAST_REPEAT: [2018-05-30 Mi 16:01]
:REPEAT_TO_STATE: TODO
:END:
:LOGBOOK:
- State "DONE"   from "TODO"   [2018-05-30 Mi 16:01]
- State "DONE"   from "TODO"   [2018-03-26 Mo 16:47]
:END:


I would expect the TODO State to shift back to TODO and the
deadline base date to be shifted by 60 days from today.


My problems persist if I test this with emacs -Q with these two
versions of emacs and org-mode

GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 2017-09-15, 
modified by Debian
Org-mode version 8.2.10 (release_8.2.10 @ /usr/share/emacs/25.1/lisp/org/)

GNU Emacs 27.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 
2018-08-17
Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @ 
/usr/local/stow/emacs-snapshot/share/emacs/27.0.50/lisp/org/)


and with this newer org mode version but with my configurations
loaded:

GNU Emacs 27.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 
2018-08-17
Org mode version 9.1.13 (release_9.1.13-898-gab1f77 @ 
/home/grfz/src/org-mode/lisp/)



Since this is really basic usage I assume no bug but some error
on my side.  What am I doing wrong?



Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




[O] do not ignore mdc errors on a permanent basis (was: org-crypt broken on Ubuntu 18.04)

2018-07-26 Thread Gregor Zattler
Hi Óscar,
* Óscar Fuentes  [2018-07-26; 13:57]:
> For the record: executing gpg2 from the command line is revealing:
>
> gpg: WARNING: message was not integrity protected
> gpg: Hint: If this message was created before the year 2003 it is
>  likely that this message is legitimate.  This is because back
>  then integrity protection was not widely used.
> gpg: Use the option '--ignore-mdc-error' to decrypt anyway.
> gpg: decryption forced to fail!
>
> The solution is to add `ignore-mdc-error' to ~/.gnupg/gpg.conf.

I hope you'll do this only as a temporary meassure.  Your could
decrypt and re-encrypt the org-crypt parts in question iff you
are sure, they were encrypted years ago and their contents is ok.

But having this option in  ~/.gnupg/gpg.conf  otherwise weakens
the security of GnuPG usage considerably.

>From the gpg man page:

 --ignore-mdc-error
  This option changes a  MDC integrity protection failure
  into a  warning.  This  can be useful  if a  message is
  partially corrupt, but  it is necessary to  get as much
  data as possible out  of the corrupt message.  However,
  be aware  that a MDC  protection failure may  also mean
  that the message was  tampered with intentionally by an
  attacker.

The usage scenario described in the first sentence is clearly a
one time thing.  Putting this option in gpg.conf ignores these
kind of errors for all future usage, for risks and side effects
see the second sentence.

Ciao; Gregor 




Re: [O] Tag completion does not work well with org-complete-tags-always-offer-all-agenda-tags

2018-05-12 Thread Gregor Zattler
Hi Alain,
* alain.coch...@unistra.fr [2018-05-12; 08:32]:
> I got:
>
> Emacs : GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version
> 3.18.9) of 2016-04-11 on buildvm-25.phx2.fedoraproject.org Package:
> Org mode version 9.1.13 (release_9.1.13-744-g13fb6a @
> /home/cochard/Org/Coch-git/org-mode/lisp/)
>
> Is that the master branch?

Seems so.

> Did you mean 'emacs -Q' with some git branch?  If so, I don't know how
> to do it...

emacs -Q -L /home/cochard/Org/Coch-git/org-mode/lisp/ 

which ads git Org to the load-path 

perhaps even

emacs -Q -L /home/cochard/Org/Coch-git/org-mode/lisp/ -l 
/home/cochard/Org/Coch-git/org-mode/lisp/org.el 

which even loads Org mode.

You could write a small file with the necessary settings and load
it also 

emacs -Q -L /home/cochard/Org/Coch-git/org-mode/lisp/ -l 
/home/cochard/Org/Coch-git/org-mode/lisp/org.el -l /tmp/minimal-exaple.el

Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] [RFC] Dog food, anyone?

2018-05-09 Thread Gregor Zattler
Hi Nicolas, Org mode developers,
* Nicolas Goaziou <m...@nicolasgoaziou.fr> [2018-05-09; 02:30]:
> Bastien <b...@gnu.org> writes:
>
>> it would be nice to make the switch to org-manual.org for Org 9.2,
>> and to delete org.texi entirely from the master branch.
>
> Done.
>
>> I guess we need to add some Makefile rules so that "make pdf" first
>> exports .org => .texi then exports .texi to .pdf... is that so?
>
> Done (or so I think).

Hurray!

I found that org-float instead of diary-float is documented in
org-manual.org although ORG-NEWS says to use diary-float instead:

~/src/org-mode$ rgrep  org-float
etc/ORG-NEWS:** =org-float= is now obsolete, use =diary-float= instead
Binary file lisp/org-compat.elc matches
lisp/org-compat.el:(define-obsolete-function-alias 'org-float-time 'float-time 
"Org 9.0")
testing/lisp/test-org.el:   (org-test-with-temp-text "<%%(org-float t 4 2)>"
testing/lisp/test-org.el:   (equal "<%%(org-float t 4 2)>"
testing/lisp/test-org.el: (org-test-with-temp-text "<%%(org-float t 4 
2)>"
doc/org.texi:  <%%(org-float t 4 2)>
doc/org.texi:<%%(org-float t 42)>
doc/org-manual.org:   <%%(org-float t 4 2)>
doc/org-manual.org:: <%%(org-float t 42)>
doc/org:<%%(org-float t 4 2)>
doc/org: <%%(org-float t 42)>
doc/org.html:  %%(org-float t 4 2)
doc/org.html:%%(org-float t 42)


~/src/org-mode$ rgrep  diary-float
etc/ORG-NEWS:** =org-float= is now obsolete, use =diary-float= instead
testing/lisp/test-org-element.el:  (should (equal (org-test-parse-and-interpret 
"<%%diary-float t 4 2>")
testing/lisp/test-org-element.el:"<%%diary-float t 4 2>\n"))
doc/orgguide.texi:  <%%(diary-float t 4 2)>

org-guide.texi is already up to date with respect to
diary-float.

I made a very simple patch for org-manual.org but none for
test-org.el or test-org-element.el since I do not understand
them.  When reading about documentation standards I found that
Org manuals filename and directory wasn't up to date, so I fixed
this.  I assume that the parts of doc/Documentation_Standards.org
which deal with texinfo formatting are also out of date but do
not know how to rewrite them.

>From b45739a23b093e1ee54ae09be8172720fa611628 Mon Sep 17 00:00:00 2001
From: Gregor Zattler <telegr...@gmx.net>
Date: Wed, 9 May 2018 19:51:51 +0200
Subject: [PATCH] ; Tiny doc fixes

* doc/org-manual.org (Dates and Times) (Timestamps, Deadlines and
  Scheduling): Document "diary-float" instead of obsolete "org-float".
* doc/Documentation_Standards.org (org-manual.org specific
  conventions): Fix file name and directory of Org manual.

Copyright-paperwork-exempt: yes
TINYCHANGE
---
 doc/Documentation_Standards.org | 4 ++--
 doc/org-manual.org  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/Documentation_Standards.org b/doc/Documentation_Standards.org
index 9d8f19fe6..c4dd862db 100644
--- a/doc/Documentation_Standards.org
+++ b/doc/Documentation_Standards.org
@@ -94,10 +94,10 @@ I have made them up of course).
 - Entries in the concept index are normally all lower case unless some
   other rule dictates otherwise.
 
-* orgmanual.org specific conventions
+* org-manual.org specific conventions
 
 Org git repository comes with an .org version of the manual in the
-=contrib/= directory.  Here are indications that are specific to this
+=doc/= directory.  Here are indications that are specific to this
 version of the manual.
 
 - Five of the standard Texinfo indexes are used in the Org manual:
diff --git a/doc/org-manual.org b/doc/org-manual.org
index eb6c96fb2..d9e95b1ee 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -5779,7 +5779,7 @@ the agenda (see [[*Weekly/daily agenda]]).  We distinguish:
 
  #+begin_example
  ,* 22:00-23:00 The nerd meeting on every 2nd Thursday of the month
-   <%%(org-float t 4 2)>
+   <%%(diary-float t 4 2)>
  #+end_example
 
 - Time/Date range ::
@@ -6158,7 +6158,7 @@ entries.  Org mode issues early and late warnings based on the
 assumption that the timestamp represents the /nearest instance/ of the
 repeater.  However, the use of diary S-exp entries like
 
-: <%%(org-float t 42)>
+: <%%(diary-float t 42)>
 
 #+texinfo: @noindent
 in scheduling and deadline timestamps is limited.  Org mode does not
-- 
2.11.0


I'm not sure if "org-float" is the right way to quote this kind
of symbol in a commit message.  Please fix if not.

HTH a tiny bit, Gregor



Re: [O] Orgalist notes

2018-05-08 Thread Gregor Zattler
Hi Nicolas,
* Nicolas Goaziou <m...@nicolasgoaziou.fr> [2018-05-07; 22:29]:
> Gregor Zattler <telegr...@gmx.net> writes:
>
>> Yes, I used the customization interface and choose "2)".  [This
>> produces 41 as value of this variable.  I did so, because
>> sometimes a sentence ends in a number and a period but these
>> happen to be after a auto-fill line break and org would assume
>> it's a list, indenting the following lines.
>
[...]
> This shouldn't happen. Org has guards against this kind of auto
> filling.

OK.  Back then, when I customized this I used fill-adapt-mode, perhaps this
was the culpruit.  I do not use it anymore so after this test I
will switch it to t and see what happens.   Thanks for this hint.

>> And I now see, orgalist does not recognize
>>
>> 1) as a list.  Neither does it indent succeeding lines after the
>> first one, nor begin a new numbered item after M-RET
>>
>> If it's not possible to use "2)", then perhaps this should be
>> documented?
>
> This is documented. In `orgalist-mode' docstring:
>
>   When Orgalist mode is enabled, any line beginning with "-", "+", "1."
>   or "a." followed by a space starts a list.
>
> However, setting `org-plain-list-ordered-item-terminator' for Org mode
> should not affect Orgalist minor mode. IOW, activating Orgalist should
> set the variable to ?. unconditionally.
>
> So... here comes Orgalist 1.7.

1. zhfsiu zhuihg uidzhrg idzhg uidhr ihgi udhrg kuidh giudrhui
   tgui ui h iM-RET
2. hae foihfje ohfe oirh gesellschaftlich


Works now without a glitch!

Thanks a bundle for your fast help.

Ciao; Gregor 




Re: [O] Orgalist notes

2018-05-07 Thread Gregor Zattler
Hi Nicolas,
* Nicolas Goaziou <m...@nicolasgoaziou.fr> [2018-05-07; 19:32]:
> Gregor Zattler <telegr...@gmx.net> writes:
>
>> Sure:
>>
>> 1. hdf ds gjdfg dzg vizdgvzu uid vjudgfvkjui dkjui uiv dfu du
>>sjuds gdhfj dhfg vhjf df dfkjh vkjM-RET
>
> Do you have `org-plain-list-ordered-item-terminator' set to ?\) ?

Yes, I used the customization interface and choose "2)".  This
produces 41 as value of this variable.  I did so, because
sometimes a sentence ends in a number and a period but these
happen to be after a auto-fill line break and org would assume
it's a list, indenting the following lines.

And I now see, orgalist does not recognize

1) as a list.  Neither does it indent succeeding lines after the
first one, nor begin a new numbered item after M-RET

If it's not possible to use "2)", then perhaps this should be
documented?

Thanks for your help, Gregor




Re: [O] Orgalist notes

2018-05-07 Thread Gregor Zattler
Hi Nicolas,
* Nicolas Goaziou  [2018-05-07; 14:37]:
> I cannot reproduce the issue. It seems to be with "org-list.el".
>
> Could you do it again, this time after loading Org uncompiled? I need
> the backtrace to step into `org-list-insert-item'.

Sure:

1. hdf ds gjdfg dzg vizdgvzu uid vjudgfvkjui dkjui uiv dfu du
   sjuds gdhfj dhfg vhjf df dfkjh vkjM-RET


Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
  goto-char(nil)
  (progn (goto-char pos) (goto-char (org-list-get-item-begin)))
  (let* ((item (progn (goto-char pos) (goto-char (org-list-get-item-begin 
(item-end (org-list-get-item-end item struct)) (item-end-no-blank 
(org-list-get-item-end-before-blank item struct)) (beforep (progn (looking-at 
org-list-full-item-re) (<= pos (cond ((not (match-beginning 4)) (match-end 0)) 
((let ((save-match-data-internal (match-data))) (unwind-protect (progn 
(string-match "[.)]" (match-string 1))) (set-match-data 
save-match-data-internal 'evaporate))) (match-beginning 4)) (t (save-excursion 
(goto-char (match-end 4)) (skip-chars-forward " \11") (point))) 
(split-line-p (org-get-alist-option org-M-RET-may-split-line 'item)) (blank-nb 
(org-list-separating-blank-lines-number pos struct prevs)) (ind 
(org-list-get-ind item struct)) (ind-size (if indent-tabs-mode (+ (/ ind 
tab-width) (mod ind tab-width)) ind)) (bullet (org-list-bullet-string 
(org-list-get-bullet item struct))) (box (if checkbox (progn "[ ]"))) (text-cut 
(and (not beforep) split-line-p (progn (goto-char pos) (if (< item-end pos) 
(progn (delete-region (1- item-end) (point-at-eol (skip-chars-backward " 
\15\11\n") (setq pos (point)) (delete-and-extract-region pos 
item-end-no-blank (body (concat bullet (if box (progn (concat box " "))) 
after-bullet (and text-cut (if (string-match "\\`[ \11]+" text-cut) 
(replace-match "" t t text-cut) text-cut (item-sep (make-string (1+ 
blank-nb) 10)) (item-size (+ ind-size (length body) (length item-sep))) 
(size-offset (- item-size (length text-cut (goto-char item) 
(indent-to-column ind) (insert body item-sep) (mapc (function (lambda (e) (let 
((p (car e)) (end (nth 6 e))) (cond ((< p item) (if (> end item) (progn (setcar 
(nthcdr 6 e) (+ end size-offset) ((or beforep (not split-line-p)) (setcar e 
(+ p item-size)) (setcar (nthcdr 6 e) (+ end item-size))) ((< p pos) (setcar e 
(+ p item-size)) (if (< end pos) (setcar (nthcdr 6 e) (+ end item-size)) 
(setcar (nthcdr 6 e) (+ end size-offset ((< p item-end) (setcar e (+ p 
size-offset (- item pos (length item-sep (if (= end item-end) (setcar 
(nthcdr 6 e) (+ item item-size)) (setcar (nthcdr 6 e) (+ end size-offset (- 
item pos (length item-sep)) (t (setcar e (+ p size-offset)) (setcar (nthcdr 
6 e) (+ end size-offset))) struct) (setq struct (cons (list item ind bullet 
nil box nil (+ item item-size)) struct)) (setq struct (sort struct (function 
(lambda (e1 e2) (< (car e1) (car e2)) (if beforep (goto-char item) (setq 
struct (org-list-swap-items item (+ item item-size) struct)) (goto-char 
(org-list-get-next-item item struct (org-list-prevs-alist struct struct)
  (let ((case-fold-search t)) (let* ((item (progn (goto-char pos) (goto-char 
(org-list-get-item-begin (item-end (org-list-get-item-end item struct)) 
(item-end-no-blank (org-list-get-item-end-before-blank item struct)) (beforep 
(progn (looking-at org-list-full-item-re) (<= pos (cond ((not (match-beginning 
4)) (match-end 0)) ((let ((save-match-data-internal (match-data))) 
(unwind-protect (progn (string-match "[.)]" (match-string 1))) (set-match-data 
save-match-data-internal 'evaporate))) (match-beginning 4)) (t (save-excursion 
(goto-char (match-end 4)) (skip-chars-forward " \11") (point))) 
(split-line-p (org-get-alist-option org-M-RET-may-split-line 'item)) (blank-nb 
(org-list-separating-blank-lines-number pos struct prevs)) (ind 
(org-list-get-ind item struct)) (ind-size (if indent-tabs-mode (+ (/ ind 
tab-width) (mod ind tab-width)) ind)) (bullet (org-list-bullet-string 
(org-list-get-bullet item struct))) (box (if checkbox (progn "[ ]"))) (text-cut 
(and (not beforep) split-line-p (progn (goto-char pos) (if (< item-end pos) 
(progn (delete-region (1- item-end) (point-at-eol (skip-chars-backward " 
\15\11\n") (setq pos (point)) (delete-and-extract-region pos 
item-end-no-blank (body (concat bullet (if box (progn (concat box " "))) 
after-bullet (and text-cut (if (string-match "\\`[ \11]+" text-cut) 
(replace-match "" t t text-cut) text-cut (item-sep (make-string (1+ 
blank-nb) 10)) (item-size (+ ind-size (length body) (length item-sep))) 
(size-offset (- item-size (length text-cut (goto-char item) 
(indent-to-column ind) (insert body item-sep) (mapc (function (lambda (e) (let 
((p (car e)) (end (nth 6 e))) (cond ((< p item) (if (> end item) (progn (setcar 
(nthcdr 6 e) (+ end size-offset) ((or beforep (not split-line-p)) (setcar e 
(+ p item-size)) (setcar (nthcdr 6 

Re: [O] Orgalist notes

2018-05-07 Thread Gregor Zattler
Hi Nicolas,
* Nicolas Goaziou <m...@nicolasgoaziou.fr> [2018-05-06; 13:32]:
> Gregor Zattler <telegr...@gmx.net> writes:
>
>> With org-mode in the load-path, the line breaks happen for all
>> lines not only the first one.  But one has to (require 'org) in
>> order for M-RET to work.  This is no problem for me, since I work
>> with org-mode all the time, but is this intended?
>
> No, it is not intended. Orgalist 1.6 (to be released tomorrow) will
> require Org right from the start.

This works now with bullet and numbered lists when called in a
non-configured emacs session.  Thanks.


>> In my highly customized emacs I get line breaks but M-RET gives
>>
>> 1. jesdgf oigjovgjis uh urh udrhfesgh ourhes ouh ouhroe uhos ho
>>hg uirehui shgourheoug hhsou hogush oguhuishughsoieghoudrhes
>>uhguhdsh ghourhg
>>
>> orgalist-insert-item: Wrong type argument: integer-or-marker-p, nil
[...]
>> Could you give me a hint on how to debug this?
>
> Please use M-x toggle-debug-on-error and report the backtrace here.
> Loading an un-compiled Orgalist is better.

1. rzhe juhgdhjvhj vghfjs y rvgfhjxd bvjxdbv mh vxnbxgbfvghg drgh
   djhxcjhbnjdfjhvgjhf jhfhjghfj hfjM-RET


gives:

Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
  org-list-insert-item(1504 ((1397 0 "1. " nil nil nil 1505)) ((1397)) nil nil)
  (setq struct (org-list-insert-item (point) struct prevs checkbox desc))
  (let* ((struct (save-excursion (goto-char item\?) (orgalist--struct))) (prevs 
(org-list-prevs-alist struct)) (desc (and (eq 'descriptive 
(org-list-get-list-type item\? struct prevs)) " :: "))) (setq struct 
(org-list-insert-item (point) struct prevs checkbox desc)) 
(org-list-write-struct struct (org-list-parents-alist struct)) (looking-at 
orgalist--item-re) (goto-char (if (and (match-beginning 4) (let 
((save-match-data-internal (match-data))) (unwind-protect (progn (string-match 
"\\." (match-string 1))) (set-match-data save-match-data-internal 
'evaporate (match-beginning 4) (match-end 0))) (if desc (progn 
(backward-char 1
  (let ((item\? (orgalist--in-item-p))) (if item\? nil (user-error "Not in a 
list")) (let* ((struct (save-excursion (goto-char item\?) (orgalist--struct))) 
(prevs (org-list-prevs-alist struct)) (desc (and (eq 'descriptive 
(org-list-get-list-type item\? struct prevs)) " :: "))) (setq struct 
(org-list-insert-item (point) struct prevs checkbox desc)) 
(org-list-write-struct struct (org-list-parents-alist struct)) (looking-at 
orgalist--item-re) (goto-char (if (and (match-beginning 4) (let 
((save-match-data-internal (match-data))) (unwind-protect (progn (string-match 
"\\." (match-string 1))) (set-match-data save-match-data-internal 
'evaporate (match-beginning 4) (match-end 0))) (if desc (progn 
(backward-char 1)
  orgalist-insert-item(nil)
  funcall-interactively(orgalist-insert-item nil)
  call-interactively(orgalist-insert-item nil nil)
  command-execute(orgalist-insert-item)


I have no clue how to read this.


Thanks for looking into this, Gregor




Re: [O] Orgalist notes

2018-05-06 Thread Gregor Zattler
Hi Eric, Nicolas,
* Eric Abrahamsen  [2018-05-05; 16:55]:
> - And before I get tired of the experiment, here's the same thing with
>  a numbered list.
> - Oh damn, I hit M-RET, and the numbered list turned into an unnumbered
>   list.

with this:
emacs-snapshot -Q  --debug-init  -l 
/home/grfz/.emacs.d/elpa-27.0/orgalist-1.5/orgalist.el   -f compose-mail  
--eval "(progn (orgalist-mode t) (end-of-buffer) (newline) (newline))"


I get


1. ha fkj hdhf kjh kdjfh kdjsh gjhdlkj ghkjdsgh dj ljgh kjdh kjhvgfkj
   hdgkjhkjh djhg kjdhf kjhdkjghf kdhödgkhödkj hödj öh ödfkj hökhdgfsjh kjgh dh 
hdgöf h h ö ökhkjhgdöhg jdhf kj ök ökdfj ödfj dfjkj kjg kj kjdökgh ödh öhg   g  
g   

   - no autofill after the second line
   - M-RET gives: setq: Symbol’s function definition is void:
 org-in-regexp



With org-mode in the load-path, the line breaks happen for all
lines not only the first one.  But one has to (require 'org) in
order for M-RET to work.  This is no problem for me, since I work
with org-mode all the time, but is this intended?


In my highly customized emacs I get line breaks but M-RET gives

1. jesdgf oigjovgjis uh urh udrhfesgh ourhes ouh ouhroe uhos ho
   hg uirehui shgourheoug hhsou hogush oguhuishughsoieghoudrhes
   uhguhdsh ghourhg

orgalist-insert-item: Wrong type argument: integer-or-marker-p, nil

This is not the case with bullet lists:

- o ushurgh dusrh gdrhf oudrhesurgh urhrh oughou hortus houtgsh
  ou houhort rtgshM-RET
- 


Could you give me a hint on how to debug this?


Thanks, Gregor




Re: [O] Orgalist notes

2018-05-05 Thread Gregor Zattler
Hi Eric, orgalist users,
* Eric Abrahamsen  [2018-05-03; 23:45]:
> Huh! I tried the exact same typing as you've done above, and the third
>  item wraps into a fourth item. I expect it will be some interaction
>  with other minor modes. I've got:

I have the very same problems with unstoppable indentation in
  orgalist and I don't think it is an interaction with other
  minor modes, because it hits even with no configuration.  Do:

emacs25 -Q  --debug-init  -l 
/home/grfz/.emacs.d/elpa-27.0/orgalist-1.3/orgalist.el   -f compose-mail --eval 
"(progn (orgalist-mode t) (end-of-buffer) (newline) (newline))"

(you'll have to adjust the path to your orglist.el)

and hit RETURN in the newly created emacs frame and this last new
line will be indented.


I also tested with a freshly build emacs from the master branch
  and it showed the same behaviour.


Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] how to use org-crypt with different key per file or node?

2018-04-27 Thread Gregor Zattler
Hi Nicolas, org-mode users,
* Nicolas Goaziou <m...@nicolasgoaziou.fr> [2018-04-27; 15:13]:
> Gregor Zattler <telegr...@gmx.net> writes:
>> +It's possible to use different keys for different headings by
>> +specifying the respective key as property CRYPTKEY, e.g.:
>
> I used =CRYPTKEY= instead of CRYPTKEY, as it is meant to be written in
> an Org document.

sorry

>> +#+begin_src emacs-lisp
>> +  * totally secret :crypt:
>
> There was a missing comma in front of the headline.

Indentation is not enough!?  Is there a document describing how
to contribute to org-manual.org?


Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] how to use org-crypt with different key per file or node?

2018-04-27 Thread Gregor Zattler
Hi org-mode users and developers,

Marco Wahl helped me with this: As always the solution is
already there in org-mode.  Attached you find a patch in
order to document this feature.

>From be08948c331118e2c66b858dc3133d3e44bfff69 Mon Sep 17 00:00:00 2001
From: Gregor Zattler <telegr...@gmx.net>
Date: Fri, 27 Apr 2018 14:17:05 +0200
Subject: [PATCH] doc/org-manual.org: Document CRYPTKEY property

TINYCHANGE
---
 doc/org-manual.org | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index e670c387f..76f061709 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -19180,6 +19180,16 @@ Here is a suggestion for Org Crypt settings in Emacs init file:
 ;; # -*- buffer-auto-save-file-name: nil; -*-
 #+end_src
 
+It's possible to use different keys for different headings by
+specifying the respective key as property CRYPTKEY, e.g.:
+
+#+begin_src emacs-lisp
+  * totally secret :crypt:
+:PROPERTIES:
+:CRYPTKEY: 0x0123456789012345678901234567890123456789
+:END:
+#+end_src
+
 Excluding the =crypt= tag from inheritance prevents already encrypted
 text from being encrypted again.
 
-- 
2.11.0



* Gregor Zattler <telegr...@gmx.net> [2018-04-26; 16:09]:
> I use org-crypt for different org files.  Till now I follow the
> documentation and specify the one and only key to use via
> (setq org-crypt-key "0xdeadbeef") for all org files and their
> headings.
>
> Is it possible to specify different keys for different files or
> even better for different headings?

Ciao; Gregor

-- 
 -... --- .-. . -.. ..--.. ...-.-


[O] how to use org-crypt with different key per file or node?

2018-04-26 Thread Gregor Zattler
Dear org-mode users and developers,

I use org-crypt for different org files.  Till now I follow the
documentation and specify the one and only key to use via
(setq org-crypt-key "0xdeadbeef") for all org files and their
headings.

Is it possible to specify different keys for different files or
even better for different headings?


Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] Bug: master: "Capture abort: (error Format specifier

2018-04-08 Thread Gregor Zattler
Hi Nicolas,
* Gregor Zattler <telegr...@gmx.net> [2018-04-07; 22:30]:
> * Nicolas Goaziou <m...@nicolasgoaziou.fr> [2018-04-03; 22:05]:
>> There is no such thing as a "%I" placeholder. Do you mean "%I"?
>
> Yes, I mean %i, the capital %I in this quote is --as I realize
> now, while typing this email-- an abbrev artefact.[1]  I assume I
> pasted from the X11 selection and the abbrev capitalized it.
>
> In my customizations file all templates have %I.  Sorry for this

arrgs: In my customizations file all templates have %i
 ^
> very special noise: this capital I
in my email
> does not explain the capture
> errors I experience with recent git master, since they are not
> part of my templates.

OK, it was a typo in emails, not in the configuration.



I investigated further.  Long story short: My
org-structure-template-alist interfered with capturing.  I
deleted this customisation and capturing works again with org
from git master.




With this minimal .emacs:
(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(org-capture-templates
   (quote
(("t" "test" entry
  (file+olp "~/.notes.org" "test")
  "* %? %^{}G
%i
%^{wann fällig?}T
%a:  notiert am/um: %U")
(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 )

I was *not* able to trigger the error with org-mode as of git
master.  Therefore the problem has to do with other parts of my
customization. 

Then I turned on debug-on-error and produced a backtrace (see
below).  This is way above my elisp skills, but I realize
something about org-tempo on top of the backtrace.  I have this
module enabled in my customization.  Therefore I disabled it in
org-modules and tested again.  Tada! disabling org-tempo "fixes"
the error.

I the enhanced my minimal .emacs and enabled org-tempo:

(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(org-capture-templates
   (quote
(("t" "test" entry
  (file+olp "~/.notes.org" "test")
  "* %? %^{}G
%i
%^{wann fällig?}T
%a:  notiert am/um: %U"
 '(org-modules
   (quote
(org-bbdb org-bibtex org-docview org-gnus org-info org-irc org-mhe 
org-rmail org-tempo org-w3m
(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 )


But I was not able to produce the error with org-tempo enabled.

Digging further I discovered org-structure-template-alist which
was configured:

 '(org-structure-template-alist
   (quote
(("s" "#+BEGIN_SRC ?

#+END_SRC")
 ("E" "#+begin_src emacs-lisp ?

#+end_src")
 ("e" "#+BEGIN_EXAMPLE
?
#+END_EXAMPLE")
 ("q" "#+BEGIN_QUOTE
?
#+END_QUOTE")
 ("v" "#+BEGIN_VERSE
?
#+END_VERSE")
 ("V" "#+BEGIN_VERBATIM
?
#+END_VERBATIM")
 ("c" "#+BEGIN_CENTER
?
#+END_CENTER")
 ("l" "#+BEGIN_EXPORT latex
?
#+END_EXPORT")
 ("L" "#+LaTeX: ")
 ("h" "#+BEGIN_EXPORT html
?
#+END_EXPORT")
 ("H" "#+HTML: ")
 ("a" "#+BEGIN_EXPORT ascii
?
#+END_EXPORT")
 ("A" "#+ASCII: ")
 ("i" "#+INDEX: ?")
 ("I" "#+INCLUDE: %file ?")
 ("u" "(use-package ?
;; :ensure nil
;; :commands
;; :bind
;; :init
;; :config
)"

I erased this customization and bingo: capturing works again.
Somehow tempo templates interfere with org capture.

Some day I will customize org-structure-template-alist again,
since templates for use-package and emacs lisp src blocks come in
handy.

Have a nice day, Gregor

Debugger entered--Lisp error: (error "Format specifier doesn’t match argument 
type")
  format("<%c" "s")
  (closure (t) (pair) (format "<%c" (car pair)))(("s" "#+BEGIN_SRC 
?\n\n#+END_SRC"))
  mapcar((closure (t) (pair) (format "<%c" (car pair))) (("s" "#+BEGIN_SRC 
?\n\n#+END_SRC"

Re: [O] Bug: master: "Capture abort: (error Format specifier doesn’t match argument type)"

2018-04-07 Thread Gregor Zattler
Hi Nicolas,
* Nicolas Goaziou <m...@nicolasgoaziou.fr> [2018-04-03; 22:05]:
> Gregor Zattler <telegr...@gmx.net> writes:
>
>> Yes, sure.  Sorry, for my laziness.  None of my templates work any more
>> with git master.  This is a (for privacy reasons) shortend version of
>> my customizations, done with the customize system:
>>
>> ...
>>  '(org-capture-templates
>>(quote
>> (("c" "Computer" entry
>>   (file+olp "~/org/grfz.org" "Computer")
>>   "* TODO %? %^{}G
>>   %I
>
> There is no such thing as a "%I" placeholder. Do you mean "%I"?

Yes, I mean %i, the capital %I in this quote is --as I realize
now, while typing this email-- an abbrev artefact.[1]  I assume I
pasted from the X11 selection and the abbrev capitalized it.

In my customizations file all templates have %I.  Sorry for this
very special noise: this capital I does not explain the capture
errors I experience with recent git master, since they are not
part of my templates.

Ciao; Gregor

[1] English is a foreign language to me, I always type the
personal pronoun "I" with a small letter and once thought it
would be a good idea to automatically correct this.  Later I
forgot about this.




Re: [O] Bug: master: "Capture abort: (error Format specifier doesn’t match argument type)"

2018-04-05 Thread Gregor Zattler
Hi Nicolas, org-mode devs,
* Gregor Zattler <telegr...@gmx.net> [2018-04-02; 14:33]:
[...]
> I get
>
> "Capture abort: (error Format specifier doesn’t match argument
> type)"
>
> after hitting the template key in order to capture something.
[...]
> I tried to bisect this with
> make autoloads ; emacs-snapshot -nw --debug-init --eval '(org-capture 4 "t")'
> as a test, but did not find the culprit.

This is, because the bisecting does not find the first bad commit,
but perhaps this helps somehow:

0 (master=) grfz@len:~/src/org-mode$ git bisect start
0 (master|BISECTING=) grfz@len:~/src/org-mode$ cd ~/src/org-mode; rm -rf * ; 
git co -f ; make autoloads > /dev/null 2> /dev/null; emacs-snapshot  --eval 
'(org-capture 4  "t")'
Your branch is up-to-date with 'origin/master'.
0 (master|BISECTING=) grfz@len:~/src/org-mode$ git bisect bad
0 (master|BISECTING=) grfz@len:~/src/org-mode$ git co -f 
2348d1834351b57d5ff9bbdb2c74c3e69ed60cfb
Note: checking out '2348d1834351b57d5ff9bbdb2c74c3e69ed60cfb'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
  
  git checkout -b 

HEAD is now at 2348d1834... Merge branch 'maint'
0 ((2348d1834...)|BISECTING) grfz@len:~/src/org-mode$ cd ~/src/org-mode; rm -rf 
* ; git co -f ; make autoloads > /dev/null 2> /dev/null; emacs-snapshot  --eval 
'(org-capture 4  "t")'
0 ((2348d1834...)|BISECTING) grfz@len:~/src/org-mode$ git bisect good
Bisecting: 843 revisions left to test after this (roughly 10 steps)
[b6c5a174da7523864d82f6d91cce272d38c1dc95] org-agenda: Refactor 
org-agenda-overriding-header code
0 ((b6c5a174d...)|BISECTING) grfz@len:~/src/org-mode$ cd ~/src/org-mode; rm -rf 
* ; git co -f ; make autoloads > /dev/null 2> /dev/null; emacs-snapshot  --eval 
'(org-capture 4  "t")'
0 ((b6c5a174d...)|BISECTING) grfz@len:~/src/org-mode$ git bisect good
Bisecting: 421 revisions left to test after this (roughly 9 steps)
[ef2485e7ce6e5ef4e47c42898d9bb1b956142df5] manual: Sync with org.texi
0 ((ef2485e7c...)|BISECTING) grfz@len:~/src/org-mode$ cd ~/src/org-mode; rm -rf 
* ; git co -f ; make autoloads > /dev/null 2> /dev/null; emacs-snapshot  --eval 
'(org-capture 4  "t")'
0 ((ef2485e7c...)|BISECTING) grfz@len:~/src/org-mode$ git bisect bad
Bisecting: 210 revisions left to test after this (roughly 8 steps)
[36578fda469b1f5cc48f05c5e07e4aba8c5ae7cb] Merge branch 'maint'
0 ((36578fda4...)|BISECTING) grfz@len:~/src/org-mode$ cd ~/src/org-mode; rm -rf 
* ; git co -f ; make autoloads > /dev/null 2> /dev/null; emacs-snapshot  --eval 
'(org-capture 4  "t")'
0 ((36578fda4...)|BISECTING) grfz@len:~/src/org-mode$ git bisect good
Bisecting: 104 revisions left to test after this (roughly 7 steps)
[a0e3f1d5050ffd0d03c68b35b2b5300fb89da1f0] Merge branch 'maint'
0 ((a0e3f1d50...)|BISECTING) grfz@len:~/src/org-mode$ cd ~/src/org-mode; rm -rf 
* ; git co -f ; make autoloads > /dev/null 2> /dev/null; emacs-snapshot  --eval 
'(org-capture 4  "t")'
0 ((a0e3f1d50...)|BISECTING) grfz@len:~/src/org-mode$ git bisect good
Bisecting: 52 revisions left to test after this (roughly 6 steps)
[9bbee7d3c883efac7c738c6ef66b476d2696fc9a] Add some `:safe' keywords
0 ((9bbee7d3c...)|BISECTING) grfz@len:~/src/org-mode$ cd ~/src/org-mode; rm -rf 
* ; git co -f ; make autoloads > /dev/null 2> /dev/null; emacs-snapshot  --eval 
'(org-capture 4  "t")'
0 ((9bbee7d3c...)|BISECTING) grfz@len:~/src/org-mode$ git bisect bad
Bisecting: 25 revisions left to test after this (roughly 5 steps)
[f8849e92e58fefc9fbea72f650cef50a5607f305] org-archive: Add a test
0 ((f8849e92e...)|BISECTING) grfz@len:~/src/org-mode$ cd ~/src/org-mode; rm -rf 
* ; git co -f ; make autoloads > /dev/null 2> /dev/null; emacs-snapshot  --eval 
'(org-capture 4  "t")'
0 ((f8849e92e...)|BISECTING) grfz@len:~/src/org-mode$ git bisect bad
Bisecting: 12 revisions left to test after this (roughly 4 steps)
[d435c75f543cce08b578a399c531a28c37a48b39] Merge branch 'maint'
0 ((d435c75f5...)|BISECTING) grfz@len:~/src/org-mode$ cd ~/src/org-mode; rm -rf 
* ; git co -f ; make autoloads > /dev/null 2> /dev/null; emacs-snapshot  --eval 
'(org-capture 4  "t")'
0 ((d435c75f5...)|BISECTING) grfz@len:~/src/org-mode$ git bisect good
Bisecting: 6 revisions left to test after this (roughly 3 steps)
[6f89177ee6f7fb5f52f10a54ae10846c803366c5] Move `org-unlogged-message' to 
"org-macs.el"
0 ((6f89177ee...)|BISECTING) grfz@len:~/src/org-mode$ cd ~/src/org-mode; rm -rf 
* ; git co -f ; make autoloads > /dev/null 2> /dev/null; emacs-snapshot  --eval 
'(org-capture 4  &quo

Re: [O] Bug: master: "Capture abort: (error Format specifier doesn’t match argument type)"

2018-04-03 Thread Gregor Zattler
Hi Nicolas,
* Nicolas Goaziou <m...@nicolasgoaziou.fr> [2018-04-03; 10:26]:
> Gregor Zattler <telegr...@gmx.net> writes:
>> GNU Emacs 26.0.91 (build 2, x86_64-pc-linux-gnu, GTK+ Version
>> 3.22.11) of 2018-04-02
>> and 
>> Org mode version 9.1.9 (release_9.1.9-560-gf93aa7 @
>> /home/grfz/src/org-mode/lisp/)
>>
>>
>> I get
>>
>> "Capture abort: (error Format specifier doesn’t match argument
>> type)"
>>
>> after hitting the template key in order to capture something.
>
> I cannot reproduce it with default template. Do you use a special one?

Yes, sure.  Sorry, for my laziness.  None of my templates work any more
with git master.  This is a (for privacy reasons) shortend version of
my customizations, done with the customize system:

...
 '(org-capture-templates
   (quote
(("c" "Computer" entry
  (file+olp "~/org/grfz.org" "Computer")
  "* TODO %? %^{}G
  %I
  %^{wann fällig?}T
  %a:  notiert am/um: %U")
 ("e" "Emacs" entry
  (file+olp "~/org/grfz.org" "Computer" "Emacs")
  "* TODO %? %^{}G
  %I
  %^{wann fällig?}T
  %a:  notiert am/um: %U")
 ("o" "Emacs org-mode" entry
  (file+olp "~/org/grfz.org" "Computer" "Emacs" "org-mode")
  "* TODO %? %^{}G
  %I
  %^{wann fällig?}T
  %a:  notiert am/um: %U")
 ("d" "diary the org-mode way" entry
  (file+headline "~/org/diary.org" "aktuell")
  "*** %? %^g
%I
%^{wann fällig?}T
%a:  notiert am/um: %U")
 ("j" "Journal Entry" entry
  (file+olp+datetree "~/org/grfz.org")
  "* %? %^{}G
  %I
  %^{wann fällig?}T
  %a:  notiert am/um: %U")
 ("t" "Todo Entry" entry
  (file+olp "~/org/grfz.org" "Sonstiges")
  "* %? %^{}G
  %I
  %^{wann fällig?}T
  %a:  notiert am/um: %U"
...

Thanks for looking into this, Gregor





[O] Bug: master: "Capture abort: (error Format specifier doesn’t match argument type)"

2018-04-02 Thread Gregor Zattler
Hi org-mode developers,

with

GNU Emacs 26.0.91 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.22.11) of 2018-04-02

and 

Org mode version 9.1.9 (release_9.1.9-560-gf93aa7 @
/home/grfz/src/org-mode/lisp/)


I get

"Capture abort: (error Format specifier doesn’t match argument
type)"

after hitting the template key in order to capture something.

This is not the case in

Org mode version 9.1.9 (release_9.1.9-3-gb1a639 @
/home/grfz/src/org-mode/lisp/)
from maint as of b1a6395dfeadd9adc5ce7633f341dfbbb30bd39e.


I tried to bisect this with
make autoloads ; emacs-snapshot -nw --debug-init --eval '(org-capture 4 "t")'
as a test, but did not find the culprit.

As a workaround I switched to main.

Thanks for your attention, Gregor




[O] wish: facility to wash org link descriptions

2018-03-02 Thread Gregor Zattler
Hi org-mode developers,

it would be nice if there was a facility to wash (= shorten) org
link descriptions.  From the users perspective this could be a
list of regular expressions with corresponding short forms.

Use case:

I want to automatically shorten org link descriptions,
especially if linking to emails.  Some of this emails are from a
request tracker and have extraordinary long From: and Subject:
suffixes which add up to 49 characters in the link description.
I would like to radically shorten this boilerplate.

Even with "normal" To: and Subject:, the default formatting of
such links prefixes the correspondents name with "from " or "to ".
While it's fine with me to distinguish emails from me from
emails to emails to me, I would not need the "from ").


Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




[O] wish: global C-u org-agenda-refile

2017-11-13 Thread Gregor Zattler
Dear org-mode users and developers, I frequently use C-u C-c C-w
in order to jump to a heading in one of my org agenda files
(using helm as a selection framework).

Alas this only works when invoked from org-mode buffers or from
the agenda if point is on an org agenda item (as opposed e.g. to
a line containing the date, or empty time grid lines).

I wish for C-u org-refile functionality (call it org-jump or
whatever) which would not depend on context, in order for me
being able to bind it to a key in the global key map.

Is this already doable?  Otherwise I wish for this
functionality. 

(org-jump works only within an org-mode buffer;
helm-org-agenda-files-headings is an external package and it's
slower than C-u org-refile from cache).


Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] org-meta-return not on M-RET

2017-09-16 Thread Gregor Zattler
Hi Nicolas, Allen,
* Nicolas Goaziou  [2017-09-16; 17:20]:
> Allen Li  writes:
>
>> When I could not get org-meta-return to work in terminal Emacs, I
>> realized that org-meta-return is only bound to M-return and not M-RET.
>> Is there any particular reason for this?
>
> No idea. Fixed. Thank you.

Thanks to both of you: It used to work, then it didn't, only a
few days ago I realised there was a difference between M-RETURN
and M-RET but thought of this as a configuration error and now it
simply works again!

Regards, Gregor




Re: [O] is there an easier way to insert an internal link?

2017-08-24 Thread Gregor Zattler
Hi John, org-moders,
* John Kitchin  [2017-08-24; 06:41]:
> I don't think this is in org-mode, but something like
> helm-org-in-buffer-headings has an action for doing something like that.

Yupp, it's on "C-c l" and asks for the description.

Thanks a lot, Gregor




[O] is there an easier way to insert an internal link?

2017-08-24 Thread Gregor Zattler
Der org-mode users,

I'm in a big org-mode file and want to insert a link to a
specific heading.

Till now I go to that heading, do org-store-link,
go back to the insert location and do org-insert-link.

Isnt' there a way to say insert-internal-link-here,
get a list of headings like refile targets, select one
(optionally change link text) and be done?

I do not want to move point in order to insert an
internal link.


I'm sure such facility already exists and I'm blind...

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] Git repository error

2017-05-26 Thread Gregor Zattler
Hi org-mode developers,
* claude fuhrer  [2017-05-26; 09:39]:
> On 26/05/17 01:10, Vicente Vera wrote:
>> Hi. For a while i've been getting this error upon running 'make up0'
>> from my local Org repository:
>>
>> fatal: read error: Connection reset by peer
> I have the same error for every pull, fetch or clone operation. I don't 
> think that it is a problem with my network connection since I can easily 
> sync other project on github.What have I done wrong ?

me too, while at the sane time I see several commits every day
via http://orgmode.org/cgit.cgi/org-mode.git/log/

My org-mode.git/config seems ok to me:

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://orgmode.org/org-mode.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "maint"]
remote = origin
merge = refs/heads/maint



Ciao; Gregor 




[O] location of clocking out notes (was: Re: Release 9.0.5)

2017-02-26 Thread Gregor Zattler
Hi Jorge, Bastien, org-mode developers,
* Jorge Morais Neto  [10. Feb. 2017]:
> On 10 February 2017 at 11:53, Bastien  wrote:
>> Org 9.0.5, a minor bugfix release, is out.
> In Org 9.0.5, clock out notes are again stored below the corresponding
> clock line, restoring the behavior of an earlier release.  There were
> interim releases, up to 9.0.4, that stored the clock out notes /above/
> the clock line.

Is there a consensus now where the clocking out notes should go,
even in future versions?  I am affected from this too and before
I start changing the position of all the clocking out notes I
would like to know where to move them.

> Users should be warned to fix clock out notes taken by
> affected Org releases.  Existing important data following the interim
> convention need to be fixed, transposing each affected clock out note
> with the clock line.  If both conventions are mixed, then, to identify
> which clock line corresponds to each clock out note, either the user
> will need to remember the time period when they used an affected
> release, or remember directly which clock out line corresponds to each
> ambiguous note, or analise the version history of their Org files.  So
> the longer the user takes to address the problem, the greater the
> chance of data loss.  I think this issue is important.
> 
> Could we provide an Elisp function to fix this semi-automatically?

This would be great.

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] Parser cache is disabled by default

2017-01-21 Thread Gregor Zattler
Hi Nicolas,
* Nicolas Goaziou  [21. Jan. 2017]:
> I decided to disable cache by default for the time being. IOW,
> `org-element-use-cache' is nil.
> 
> Please consider turning it on if you want to help debugging the issue.

Is there an easy to follow receipt what to do in order to help
you debugging?  When Emacs hangs I do pkill -USR2 emacs but then
there is no debug info!?


Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




[O] [PATCH] ; * doc/org.texi (Key bindings and useful functions): Beautify table.

2017-01-08 Thread Gregor Zattler
Correctly render table of org-babel key bindings even in info
mode. [tiny change]

Copyright-paperwork-exempt: yes
---
 in
 
http://orgmode.org/manual/Key-bindings-and-useful-functions.html#Key-bindings-and-useful-functions
 there is a table with two key bindings on every line where as in 
 (info "Key bindings an useful functions")) these lines are split
 up so that part of the second key binding is on a separate line:
 
 #+BEGIN_EXAMPLE
Active key bindings in Org mode buffer:
 
 ‘C-c C-v p’   or   ‘C-c C-v  ‘org-babel-previous-src-block’
 C-p’
 ‘C-c C-v n’   or   ‘C-c C-v  ‘org-babel-next-src-block’
 C-n’
 #+END_EXAMPLE
 
 This is how I would expect this lines to look:
 
 #+BEGIN_EXAMPLE
Active key bindings in Org mode buffer:
 
 ‘C-c C-v p’   or   ‘C-c C-v C-p’ ‘org-babel-previous-src-block’
 
 ‘C-c C-v n’   or   ‘C-c C-v C-n’ ‘org-babel-next-src-block’
 #+END_EXAMPLE
 
 
 I consider this to be a bug.  This trivial patch fixes this.

 doc/org.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/org.texi b/doc/org.texi
index 2d153ac25..7772d8b84 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -16716,7 +16716,7 @@ Active key bindings in code blocks:
 
 Active key bindings in Org mode buffer:
 
-@multitable @columnfractions 0.45 0.55
+@multitable @columnfractions 0.5 0.5
 @kindex C-c C-v p
 @kindex C-c C-v C-p
 @item @kbd{C-c C-v p} @ @ @r{or} @ @ @kbd{C-c C-v C-p} @tab 
@code{org-babel-previous-src-block}
-- 
2.11.0




Re: [O] Change visibility for bracket links

2016-10-13 Thread Gregor Zattler
Hi Nicolas, org-mode users and developers,
* Nicolas Goaziou  [13. Okt. 2016]:
> Aaron Ecay  writes:
>> My understanding of the problem is that when link fontification is
>> turned on, it is impossible to tell between the two marked positions
>> when point is in in a link like:
>>
>>  [[http://google.com][Search]]
>> ^  ^
>>
>> My suggestion is that we solve the problem in a different way: by
>> changing the color of the cursor when the text is inside the link.
>> So, the cursor would be the default grey color at the first ^ above,
>> and red at the second ^?  (Of course, the color we use for the cursor
>> in links could be changed by customization).  It looks like such an
>> effect is achievable by combining the cursor-sensor-functions text
>> property with set-cursor-color.
>>
>> WDYT?
> 
> That would only partly solve the problem. Cursor's color would tell you
> where you are, but the dance (e.g., C-a or backward-forward) is still
> needed to effectively move to the other side.

But this is a cursor movment problem then.  How about
org-beginning-of-link, org-end-of-link (this already works with
org-next-link as some kind of a substitute of org-beginning-of-link)?


Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] Bug: org-add-note closes log book drawer

2016-07-30 Thread Gregor Zattler
Hi Nicolas,
* Nicolas Goaziou  [31. Jul. 2016]:
> Hello,
> 
> nljlistb...@gmail.com (N. Jackson) writes:
> 
> > When org-log-into-drawer is t and the log book drawer is open, using
> > org-add-note closes the log book drawer.
> >
> > I think it would be better if org-add-note left the state (open or
> > closed) of the log book drawer alone.
> >
> > In comparison org-clock-in and org-clock-out do leave the state of the
> > log book drawer alone, which is much more satisfactory.
> 
> I understand the discrepancy problem. 
> 
> However, drawers are meant to remove stuff from view, i.e., their
> contents are, more often than not, hidden. So, `org-clock-in' and
> `org-clock-out' may be wrong in this case.

For me the reasoning is the other way around: "Since drawers are meant
to remove stuff from view, i.e., their contents are, more often than
not, hidden", I'd say if the drawer is open prior to org-add-note
there might be a reason why so and it would ne nice not to interfere
with the users choice.

I open my org files in show-everything view for performance reasons.
I have turned on note taking for many funtions like changing TODO
states an cklockin out, therefore the really big drawer collapses all
the time although I want it to stay open.

Just my 2, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




[O] how to rebuild org agenda while emacs is idle?

2016-02-13 Thread Gregor Zattler
Hi org-mode users and developers,

org-agenda is great but slow, sticky agenda solves this but gets
stale really fast.  I try to refresh my org-agenda while Emacs is
idle like so:

(defun gz/refresh-agenda-when-idle ()
  "Refresh Agenda while idle."
(org-agenda-redo 'all))

(setq gz/idle-agenda-timer (run-with-idle-timer 3 t 
'gz/refresh-agenda-when-idle))

This should refresh my agenda after 3 seconds of idle time.  But
when I change one of my agenda files (and save it), the change
does not occur in the agenda after 9 seconds of idle time
although the echo area shows "Rebuilding agenda buffer...done"

What's wrong with this settings?


If you want to play with this, use this test.org:

(defun gz/refresh-agenda-when-idle ()
  "Refresh Agenda while idle."
(org-agenda-redo 'all))

(setq gz/idle-agenda-timer (run-with-idle-timer 3 t 
'gz/refresh-agenda-when-idle))


; in order to cancel the timer ans start afresh:
(cancel-timer gz/idle-agenda-timer)


* Change this heading and watch the agenda buffer: changing?
<2016-02-13 Sa>--<2036-02-13 Mi>


nd visit it like so:
emacs24 -Q -nw /tmp/nuff.org  --eval '(org-agenda-file-to-front)' --eval 
'(org-agenda "a")'

The problem is the same with emacs25 and org-mode from git as of
today (but with emacs25 you'll have to arrange the windows
yourself).


Ciao, Gregor




Re: [O] Bug: [bisected] note from clocking out is above :LOGBOOK: drawer [8.3.3 (release_8.3.3-469-g2e7716 @ /home/grfz/src/org-mode/lisp/)]

2016-01-20 Thread Gregor Zattler
Hi Nicolas,
* Nicolas Goaziou <m...@nicolasgoaziou.fr> [20. Jan. 2016]:
> Gregor Zattler <telegr...@gmx.net> writes:
>> It would be great when notes taken when clocking out would come
>> next to their respective clock lines.
> 
> This is already possible: just make sure notes and clocks are stored at
> the same location (e.g., set `org-log-into-drawer' to t in your ECM).

Actually this keeps all notes in the :LOGBOOK: drawer but notes
taken while clocking out appear above instead of below the clock
line.  I would have to shuffle all existing clock-out-notes above
their respective clock line in order to have consistent
documents.  This is doable.

This way notes taken while clocked in are mixed with the ones
taken when clocking out and are even nearer to the clock line.  But...

> However, by default, they aren't.
>
> I see no reason to force notes taken upon clocking out to be always
> located next to the clock line, as long as you can get that behaviour
> somehow. Thus, I think the documentation could be improved as it sort of
> implies clock notes are always next to the closed clock.
> 
> IIUC, you are suggesting to implement two types of notes, but that never
> was the case in Org, AFAICT. You could, however, use a hook (e.g.,
> `org-clock-out-hook') in order to put data relative to clocks in
> a specific drawer and keep general notes in LOGBOOK at the same time.

... I guess this hook will be run before actually clocking out?
Thus I would change the notes drawer to the clock line drawer,
clock out and set it back again?


Thanks for your help, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] Bug: [bisected] note from clocking out is above :LOGBOOK: drawer [8.3.3 (release_8.3.3-469-g2e7716 @ /home/grfz/src/org-mode/lisp/)]

2016-01-20 Thread Gregor Zattler
Hi Nicolas,
* Nicolas Goaziou <m...@nicolasgoaziou.fr> [20. Jan. 2016]:
> Gregor Zattler <telegr...@gmx.net> writes:
>> Notes produced when clocking out with org-log-note-clock-out set
>> will be placed above the clock line instead below the clock line.
>> In my heavily customized sessions the notes show up on the
>> previos line respective to the clock line.  Without
>> customizations (see below) they end up above the :LOGBOOK:
>> drawer.
>>
>> ECM:
>> emacs24 -Q -nw -L /home/grfz/src/org-mode/lisp/ --eval "(require 'org)"  
>> --eval '(setq org-log-note-clock-out t)' /tmp/test.org
>>
>> now add a heading, clock in, clock out, write something as a note,
>> do C-c C-c to finish note taking.  Result:
>>
>> * heading
>>   - note
>>   :LOGBOOK:
>>   CLOCK: [2016-01-19 Di 16:22]--[2016-01-19 Di 16:22] =>  0:00
>>   :END:
> 
> I can reproduce it. However, I don't think it is a bug. It looks like
> the expected default behaviour.
> 
> By default, clocks and notes are not stored at the same location. See
> `org-log-into-drawer' and `org-clock-into-drawer'. So, there's no reason
> to put them together here. 
> 
> Moreover, I cannot see anything in the code that would make "clock
> notes" special in any way. This is basically the same as calling
> `org-add-note' right after clocking out, and, as this function's
> docstring points out:
> 
>   This is done in the same way as adding a state change note.
> 
> OTOH, the manual says
> 
>   See the variable ‘org-log-note-clock-out’ for the possibility to
>   record an additional note together with the clock-out timestamp.
> 
> In particular, the term "together" is ambiguous, as it can indeed be
> understood as "at the same place". However, I doubt the intent is to
> create a new type of note that would purposely ignore global logging
> settings. So I lean towards a documentation bug here.
> 
> WDYT?

Thanks for your explanation.  To me this is not a documentation
bug.  What the documentation describes allows for a helpful
distinction of notes in different contexts which IMHO should not
be conflated: 

I understand that to you all notes are created equal: They
somehow belong to a node.

I think the note taken when clocking out belongs specifically to
its clock line and explains it.  Clocking is for reasons of
measurement of time often in context of accounting.  Such notes
answer to the question ""Why took it so long".  This is different
to notes which are there to remember specific aspects of a tasks.

This was default behaviour when users decided to be asked for a
note taken after clocking out.

 I for instance document my working hours this way and have
 2072 such notes sitting below their corresponding clock
 line.
 
 I have the task of maintaining some complex spreadsheets for
 the accounting department.  My employer want's to know how
 much time I spend on this task.  So I clock this working
 hours.  I want to be able to anser to the question why it
 took so long.
 
 OTHT there are notes regarding the work with these complex
 spreadsheets, e.g. "conditional colouring of cells may lead
 to performance problem when thousands of conditionally
 coloured cells are in use".  This is a note which belongs to
 the Spreadsheets and is not only true for the time interval
 indicated by a clock line.
 
It would be great when notes taken when clocking out would come
next to their respective clock lines.


Thanks for your attention, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




[O] Bug: [bisected] note from clocking out is above :LOGBOOK: drawer [8.3.3 (release_8.3.3-469-g2e7716 @ /home/grfz/src/org-mode/lisp/)]

2016-01-19 Thread Gregor Zattler

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


Notes produced when clocking out with org-log-note-clock-out set
will be placed above the clock line instead below the clock line.
In my heavily customized sessions the notes show up on the
previos line respective to the clock line.  Without
customizations (see below) they end up above the :LOGBOOK:
drawer.

ECM:
emacs24 -Q -nw -L /home/grfz/src/org-mode/lisp/ --eval "(require 'org)"  --eval 
'(setq org-log-note-clock-out t)' /tmp/test.org

now add a heading, clock in, clock out, write something as a note,
do C-c C-c to finish note taking.  Result:

* heading
  - note
  :LOGBOOK:
  CLOCK: [2016-01-19 Di 16:22]--[2016-01-19 Di 16:22] =>  0:00
  :END:



This is with
Package: Org-mode version 8.3.3 (release_8.3.3-469-g2e7716 @ 
/home/grfz/src/org-mode/lisp/)

Emacs version doesn't matter (tested with
- GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 
2015-10-24 on trouble, modified by Debian
and
- Emacs  : GNU Emacs 25.0.50.15 (x86_64-pc-linux-gnu, GTK+ Version 3.18.6) of 
2016-01-19


I git bisected this:

8ddc7314b801b48dff5c246c0954c67021b145f9 is the first bad commit
commit 8ddc7314b801b48dff5c246c0954c67021b145f9
Author: Nicolas Goaziou 
Date:   Tue Jan 12 21:28:32 2016 +0100

Store notes outside drawers at a correct location

* lisp/org.el (org-log-beginning): Move to an appropriate location even
when `org-log-state-notes-insert-after-drawers' is nil and notes are
not stored within a drawer.

Reported-by: swfl...@flintfam.org (Samuel W. Flint)


:04 04 82c4d500315fa5ea5e4e1968e633bfac078f2e6a 
a4fee4c6e2e140cbba8b3fb16513b269b1f9cfe0 M  lisp


Thanks for your attention, Gregor



Re: [O] org-lint complains about incorrect contents for PROPERTIES drawer in inline task (was: Re: how to use org-lint)

2015-10-16 Thread Gregor Zattler
Hi Nicolas, org-mode developers,

I fixed another org-mode file and there is another strange
behaviour of org-lint:

org-lint complains:
  9846 high  Incorrect contents for PROPERTIES drawer

because of this:

* watermelon watermelon watermelon
  :PROPERTIES:
  :CREATED: <2013-07-10 Mi 16:40>
  :END:
  <2013-07-11 Do>
* END

In order to fix it I recreated this inline task (C-c C-x t) and
its PROPERTIES drawer (C-u M-x org-insert-drawer) and the
specified property (C-c C-x p).  Org-lint complains nonetheless.

What to do?

Ciao; Gregor 


* Gregor Zattler <telegr...@gmx.net> [16. Oct. 2015]:
> org-lint cpmlains:
>  10702 low   Misplaced planning info line
> 
> because of this:
> 
> * DONE  xxx X x X
>   DEADLINE: <2011-11-25 Fr>   CLOSED: [2011-12-17 Sa 21:42]  
>   <2011-11-22 Di>
>   :LOGBOOK:
>   - State "DONE"   from "TODO"   [2011-12-17 Sa 21:42] \\
> erledigt
>   :END:
> * END
> 
> is it right to do so?  I thought planning info lines go right
> below the headline?
> 
> Ciao; Gregor
> 
> P.S.: Regarding the problem described below: org-lint worked with
> Emacs-snapshot -Q, so I bisected my init.el.  Now it works while
> nothing relvant changed with respect to the init.el!?  Strange.
> 
> * Nicolas Goaziou <m...@nicolasgoaziou.fr> [15. Oct. 2015]:
>> Gregor Zattler <telegr...@gmx.net> writes:
>> 
>>> When I do this, nothing happens, there is no buffer *Org lint*.
>> 
>> You may want to debug `org-lint', or probably
>> `org-lint--display-reports' then.
>> 
>>> When I do M-: (org-int) it takes a second or two but there is no
>>> *Org-lint* buffer and only this info in *Messages* (I XXXed personal
>>> info):
>> 
>> In non-interactive mode, `org-lint' spits out reports for further
>> processing, or nil when all lights are green. IOW, this is to be
>> expected.
>> 
>> Regards,
>> 
>> 
> 
> Ciao, Gregor
> -- 
>  -... --- .-. . -.. ..--.. ...-.-
> 
> 

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




[O] org-lint complains about planning info line in inline task (was: Re: how to use org-lint)

2015-10-16 Thread Gregor Zattler
Hi Nicolas, org-mode developers,

org-lint cpmlains:
 10702 low   Misplaced planning info line

because of this:

* DONE  xxx X x X
  DEADLINE: <2011-11-25 Fr>   CLOSED: [2011-12-17 Sa 21:42]  
  <2011-11-22 Di>
  :LOGBOOK:
  - State "DONE"   from "TODO"   [2011-12-17 Sa 21:42] \\
erledigt
  :END:
* END

is it right to do so?  I thought planning info lines go right
below the headline?

Ciao; Gregor

P.S.: Regarding the problem described below: org-lint worked with
Emacs-snapshot -Q, so I bisected my init.el.  Now it works while
nothing relvant changed with respect to the init.el!?  Strange.

* Nicolas Goaziou <m...@nicolasgoaziou.fr> [15. Oct. 2015]:
> Gregor Zattler <telegr...@gmx.net> writes:
> 
>> When I do this, nothing happens, there is no buffer *Org lint*.
> 
> You may want to debug `org-lint', or probably
> `org-lint--display-reports' then.
> 
>> When I do M-: (org-int) it takes a second or two but there is no
>> *Org-lint* buffer and only this info in *Messages* (I XXXed personal
>> info):
> 
> In non-interactive mode, `org-lint' spits out reports for further
> processing, or nil when all lights are green. IOW, this is to be
> expected.
> 
> Regards,
> 
> 

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




[O] fix confirmed (was: Re: org-lint complains about incorrect contents for PROPERTIES drawer in inline task)

2015-10-16 Thread Gregor Zattler
Hi Nicolas,

thanks, confirmed for both problems.

Thank you for your fast fix.

Empty *org-lint* buffers give a feeling of security :-)

Ciao; Gregor 

* Nicolas Goaziou <m...@nicolasgoaziou.fr> [16. Oct. 2015]:
> Gregor Zattler <telegr...@gmx.net> writes:
> 
>> I fixed another org-mode file and there is another strange
>> behaviour of org-lint:
>>
>> org-lint complains:
>>   9846 high  Incorrect contents for PROPERTIES drawer
>>
>> because of this:
>>
>> * watermelon watermelon watermelon
>>   :PROPERTIES:
>>   :CREATED: <2013-07-10 Mi 16:40>
>>   :END:
>>   <2013-07-11 Do>
>> * END
>>
>> In order to fix it I recreated this inline task (C-c C-x t) and
>> its PROPERTIES drawer (C-u M-x org-insert-drawer) and the
>> specified property (C-c C-x p).  Org-lint complains nonetheless.
> 
> It should also be fixed along with the previous bug. Thank you.
> 
> Regards,
> 
> -- 
> Nicolas Goaziou
> 
> 

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




[O] how to use org-lint

2015-10-14 Thread Gregor Zattler
Dear org-mode users and developers,

when I do M-x org-lint while the active cpoint is in a org-mode
buffer nothing happens.

When I do M-: (org-lint) I get for instance;

((1 ["118" "high" "Incorrect location for PROPERTIES drawer" 
[cl-struct-org-lint-checker obsolete-properties-drawer "Report obsolete syntax 
for properties drawers" ... high]]) (2 ["922" "high" "Duplicate footnote 
definition \"1\"" [cl-struct-org-lint-checker duplicate-footnote-definition 
"Report duplicate footnote definitions" ... high]]) (3 ["1018" "high" 
"Incorrect location for PROPERTIES drawer" [cl-struct-org-lint-checker 
obsolete-properties-drawer "Report obsolete syntax for properties drawers" ... 
high]]) (4 ["1144" "low" "Misplaced planning info line" 
[cl-struct-org-lint-checker misplaced-planning-info "Report misplaced planning 
info line" ... low]]) (5 ["1257" "high" "Missing definition for footnote 
[fn:BMG]" [cl-struct-org-lint-checker undefined-footnote-reference "Report 
missing definition for footnote references" ... high]]) (6 ["1257" "high" 
"Missing definition for footnote [fn:AGHF]" [cl-struct-org-lint-checker 
undefined-footnote-reference "Report missing definition for footnote 
references" ... high]]) (7 ["1257" "high" "Missing definition for footnote 
[fn:AGHF]" [cl-struct-org-lint-checker undefined-footnote-reference "Report 
missing definition for footnote references" ... high]]) (8 ["1257" "high" 
"Missing definition for footnote [fn:AGHF]" [cl-struct-org-lint-checker 
undefined-footnote-reference "Report missing definition for footnote 
references" ... high]]) (9 ["1264" "high" "Missing definition for footnote 
[fn:BMG]" [cl-struct-org-lint-checker undefined-footnote-reference "Report 
missing definition for footnote references" ... high]]) (10 ["1268" "high" 
"Missing definition for footnote [fn:AGHF]" [cl-struct-org-lint-checker 
undefined-footnote-reference "Report missing definition for footnote 
references" ... high]]) (11 ["5201" "high" "Incorrect location for PROPERTIES 
drawer" [cl-struct-org-lint-checker obsolete-properties-drawer "Report obsolete 
syntax for properties drawers" ... high]]) (12 ["5220" "high" "Incorrect 
location for PROPERTIES drawer" [cl-struct-org-lint-checker 
obsolete-properties-drawer "Report obsolete syntax for properties drawers" ... 
high]]) ...)

in the *Message*  Buffer.

How do I interpret this message?  I would like to fix my org-mode
files but do not know how to with this messages.

I remember vaguely that thee used to be a nicely formatted
results buffer?  

This is on
GNU Emacs 25.0.50.2 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2015-10-14
Org-mode version 8.3.2 (release_8.3.2-175-gfa61cb 
@/home/grfz/src/org-mode/lisp/)

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




Re: [O] how to use org-lint

2015-10-14 Thread Gregor Zattler
Hi Nicolas,
* Nicolas Goaziou <m...@nicolasgoaziou.fr> [14. Oct. 2015]:
> Gregor Zattler <telegr...@gmx.net> writes:
> 
>> when I do M-x org-lint while the active cpoint is in a org-mode
>> buffer nothing happens.
> 
> M-x org-lint should create an "*Org lint*" buffer somewhere. Maybe it is
> buried or on another frame.

When I do this, nothing happens, there is no buffer *Org lint*.

When I do M-: (org-int) it takes a second or two but there is no
*Org-lint* buffer and only this info in *Messages* (I XXXed personal info):


Debug (ox-odt): Searching for OpenDocument styles files...
Debug (ox-odt): Trying /usr/share/emacs/etc/org/styles/... [2 times]
Debug (ox-odt): Trying /home/grfz/src/etc/styles/...
Debug (ox-odt): Trying /home/grfz/src/org-mode/lisp/etc/styles/...
Debug (ox-odt): Trying 
/usr/local/stow/emacs-snapshot/share/emacs/25.0.50/etc/org/...
Debug (ox-odt): Using styles under 
/usr/local/stow/emacs-snapshot/share/emacs/25.0.50/etc/org/
Debug (ox-odt): Searching for OpenDocument schema files...
Debug (ox-odt): Trying /usr/share/emacs/etc/org/schema/... [2 times]
Debug (ox-odt): No OpenDocument schema files installed
((1 ["2395" "low" "Possible incomplete block \"#+BEGIN: clocktable  :tstart 
\"2015-01-01\" :tend \"\" :narrow 80! :minlevel 2 :maxlevel 14 :scope 
agenda :tags \"job\" :stepskip0 :fileskip0 :link :indent\"" 
[cl-struct-org-lint-checker invalid-block "Report invalid blocks" ... low]]) (2 
["2440" "low" "Invalid block closing line \"#+END: clocktable\"" 
[cl-struct-org-lint-checker invalid-block "Report invalid blocks" ... low]]) (3 
["2459" "low" "Misplaced planning info line" [cl-struct-org-lint-checker 
misplaced-planning-info "Report misplaced planning info line" ... low]]) (4 
["2463" "low" "Misplaced planning info line" [cl-struct-org-lint-checker 
misplaced-planning-info "Report misplaced planning info line" ... low]]) (5 
["2545" "low" "Misplaced planning info line" [cl-struct-org-lint-checker 
misplaced-planning-info "Report misplaced planning info line" ... low]]) (6 
["2736" "low" "Misplaced planning info line" [cl-struct-org-lint-checker 
misplaced-planning-info "Report misplaced planning info line" ... low]]) (7 
["3462" "high" "Unknown fuzzy location \" -e \"$envfile\" \"" 
[cl-struct-org-lint-checker invalid-fuzzy-link "Report \"fuzzy\" links with 
unknown destination" ... high]]) (8 ["3570" "high" "Unknown fuzzy location 
\"gitready.com\"" [cl-struct-org-lint-checker invalid-fuzzy-link "Report 
\"fuzzy\" links with unknown destination" ... high]]) (9 ["3589" "low" "Link to 
non-existent local file \"~/src/progit/figures/18333fig0106-tn.png\"" 
[cl-struct-org-lint-checker link-to-local-file "Report links to non-existent 
local files" ... low]]) (10 ["3603" "low" "Link to non-existent local file 
\"~/src/progit/figures/18333fig0201-tn.png\"" [cl-struct-org-lint-checker 
link-to-local-file "Report links to non-existent local files" ... low]]) (11 
["3647" "high" "Unknown fuzzy location 
\"XXX%20XXX%C3%9F%20iXX20%20X%20XXX,%20%20XXX%20XXX,%20%20%0A%20%20XX\""
 [cl-struct-org-lint-checker invalid-fuzzy-link "Report \"fuzzy\" links with 
unknown destination" ... high]]) (12 ["4907" "low" "Misplaced planning info 
line" [cl-struct-org-lint-checker misplaced-planning-info "Report misplaced 
planning info line" ... low]]) ...)


Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-




[O] document depreciation of timeline? (was: Re: Bug: Displaying timeline for .org-file and then switching to including inactive timestamps will not include old and future inactive timestamps [8.3.1 (

2015-08-24 Thread Gregor Zattler
Hi Nicolas,
* Nicolas Goaziou m...@nicolasgoaziou.fr [24. Aug. 2015]:
 There are many advertised limitations to Timeline feature. Actually,
 Timeline feature is moribund[fn:1][fn:2]. Use Agenda view instead.

[... 4 Zeilen gelöscht ...]
 [fn:1] http://thread.gmane.org/gmane.emacs.orgmode/39368/focus=40038
 
 [fn:2] http://permalink.gmane.org/gmane.emacs.orgmode/60518

There are only two commits which mention the timeline in their
summry lines in the newer git history since 2008-01-31.

Shouldn't the feature then be officially depreciated and
mentioned as stale in the manual?  The manual mentions the
timeline in most cases together with the agenda.  And there is a
small chapter dedicated to the timeline.

If depreciation of the timeline is OK I would patch the manual
accordingly. 


Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-



[O] how to merge two datetrees?

2015-08-23 Thread Gregor Zattler
Hello,

I have two datetrees, each in one org-mode file.  Any ideas how
to merge them?

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-



[O] 3 thanks (was: Re: Bug: Capturing to datetree with inactive timestamp messes up level of heading)

2015-08-22 Thread Gregor Zattler
Hi Nicolas,
* Nicolas Goaziou m...@nicolasgoaziou.fr [22. Aug. 2015]:
 Gregor Zattler telegr...@gmx.net writes:
 customizing org to add timestamps in datetrees via …
 (org-datetree-add-timestamp (quote inactive) nil nil Add an
 inactive time stamp when create a datetree entry.)… and
 activating a minimal capture template which captures to a
 datetree results in:

 a)

 * 2015  
 ** 2015-08 August   
 *** 2015-08-19 Mittwoch 
 [2015-08-19 Mi] 
 ** actual entry heading of captured item

 The heading of the newly captured item is at level 2 instead at
 level 4.  I consider this to be a bug.  A second capture item to
 the same day is correctly created at level 4 (and bevor the first
 captured item which does not belong to the same (or any) day in
 the datetree).
 
 Fixed. Thank you.

Thanks.
 2)
 This is a different feature. Since it belongs to the captured entry, the
 timestamp should be defined in your capture template (e.g. %t
 placeholder) instead.

Thanks.
 3)
 See above. You can use %T.

Thanks again.

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-



[O] Bug: Capturing to datetree with inactive timestamp messes up level of heading

2015-08-20 Thread Gregor Zattler
Dear org-mode developers,

customizing org to add timestamps in datetrees via …
(org-datetree-add-timestamp (quote inactive) nil nil Add an
inactive time stamp when create a datetree entry.)… and
activating a minimal capture template which captures to a
datetree results in:

a)

* 2015  
** 2015-08 August   
*** 2015-08-19 Mittwoch 
[2015-08-19 Mi] 
** actual entry heading of captured item

The heading of the newly captured item is at level 2 instead at
level 4.  I consider this to be a bug.  A second capture item to
the same day is correctly created at level 4 (and bevor the first
captured item which does not belong to the same (or any) day in
the datetree).


2)

The timestamp is added to the heading of the day under which the
captured item is stored iff the day entry is created for this
capture.

I think the timestamp should go with the actual captured entry.
This allows for a timestamp for each captured entry under the
same date heading.  They may be made at different days.


3)

The timestamp adds only a date but I think it’s much more
interesting to capture with date+time.  Think of several journal
entries all done at the same day but at different times of a day.


All three observations werde made with an otherwise uncustimazed
org-mode (emacs -Q).  I created the journal capture template from
the org-capture prompt („C“).


Org-mode version 8.3.1 (release_8.3.1-120-gc5cbc6 @ 
/home/grfz/src/org-mode/lisp/)
GNU Emacs 25.0.50.6 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2015-08-19 on 
boo


Thanks for your attention, Gregor



[O] how to quote slashes in org-protocol string?

2015-08-16 Thread Gregor Zattler
Dear org-mode users and developers,

how do I quote slashes (/) in TITLE or BODY in org-protocol
string?

 emacsclient org-protocol:/capture:/x/URL/TITLE/BODY

I capture emails from mutt (mail user agent) to org-mode via mutt
macros and bash scripts.  Now I get errors in Emacs „Greedy
org-protocol handler.  Killing client.“ because TITLE (the
Subject of the email) contains slashes.

I tried to quote the slashes with slashes but this chops of part
of the TITLE.

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-



[O] SOLVED (was: Re: how to quote slashes in org-protocol string?)

2015-08-16 Thread Gregor Zattler
Dear org-mode users and developers,
* Gregor Zattler telegr...@gmx.net [16. Aug. 2015]:
 how do I quote slashes (/) in TITLE or BODY in org-protocol
 string?

Answer: urlencode them as explained in
https://en.wikipedia.org/wiki/Percent-encoding

  emacsclient org-protocol:/capture:/x/URL/TITLE/BODY
 
 I capture emails from mutt (mail user agent) to org-mode via mutt
 macros and bash scripts.  Now I get errors in Emacs „Greedy
 org-protocol handler.  Killing client.“ because TITLE (the
 Subject of the email) contains slashes.
 
 I tried to quote the slashes with slashes but this chops of part
 of the TITLE.

A function to do so in bash can be found at:
http://stackoverflow.com/questions/296536/how-to-urlencode-data-for-curl-command


Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-



  1   2   3   >