Re: org-agenda-files: using variables

[Loris Bennett]

Hi Nick,

Nick Dokos  writes:

> "Loris Bennett"  writes:
>
>> Hi,
>>
>> I have
>>
>>   (setq lb/org-directory "~/org/"))
>>   (setq lb/gtd-file (expand-file-name "gtd.org" lb/org-directory))
>>   (setq lb/refile-file (expand-file-name "refile.org" lb/org-directory))
>>   (setq org-agenda-files '(lb/gtd-file lb/refile-file))
>>
>> But generating the agenda fails with
>>
>>   Wrong type argument: stringp, lb/gtd-file  
>>
>> What is the correct syntax to use the variables in the list?
>>
>
> Quoting quotes everything including symbols, so you either do not
> quote or use backquote:
>
>   (setq org-agenda-files (list lb/gtd-file lb/refile-file))
>   (setq org-agenda-files `(,lb/gtd-file ,lb/refile-file))
>
> In this case, I'd prefer the first form, but the second form is often
> useful - see
>
>   (info "(elisp)Backquote")

Thanks, in particular also for the link to the relevant documentation.

Cheers,

Loris

-- 
This signature is currently under constuction.

Re: [BUG] Org-9.6 declares compatibility with Emacs-25.1

[Bastien Guerry]

Ihor Radchenko  writes:

> Bastien, please let me know if you have any objections.

None, thanks for taking action here.

-- 
 Bastien

Re: [BUG] ob-shell doesn't evaluate last line on Windows (cmd/cmdproxy) [9.6.1 ( @ c:/Users/Osher/AppData/Roaming/.emacs.d/elpa/org-9.6.1/)]

[Matt]

  On Tue, 17 Jan 2023 14:53:39 -0500  Osher Jacob  wrote --- 
 > changing shell-command-switch to "/k" or "-k", I get a similar output:

Thanks for checking that.

 > You also mentioned the source code block is being passed through the "-c" 
 > flag as a command-line argument.I might be misunderstanding something here, 
 > but it seems like it is being passed through the stdin of the shell process 
 > when the calls process-file -> call-process are being made.

That the block source is passed through "-c" is an educated guess.  I keep 
finding myself in C land where it's less clear to me what precisely happens.  
You're correct that `call-process' acts on the block source.  It's not clear to 
me whether that's done through stdin or whether being passed through stdin 
would even help us.  Here's what I'm seeing.

Evaluating the block goes through 4 lisp commands and then into C:

1. Calls `(org-babel-eval shell-file-name (org-trim body))'

This evaluates as...

(org-babel-eval
  "cmdproxy.exe" ; command, whatever `shell-file-name' is
  (org-trim body) ; query, the block body
  )

The query parameter (the block body) gets inserted into a temp buffer on which 
`org-babel--shell-command-on-region' is called.

2. Calls `(org-babel--shell-command-on-region command error-buffer)' on a temp 
buffer containing block body.

This evaluates as...

(org-babel--shell-command-on-region
  command   ; "cmdproxy.exe"
  error-buffer  ;  #
  )

This in turn calls `process-file' where INPUT-FILE is a temp file containing 
the contents of the buffer `org-babel--shell-command-on-region' was called on 
(that is, the temp file contains the block body).

3. Calls `(process-file shell-file-name input-file (if error-file (list t 
error-file) t) nil shell-command-switch command)'

This evaluates as...

(process-file
  "cmdproxy.exe"   ; shell-file-name
  "/path/to/temp/containing/block/source"  ; input-file
  (t "/tmp/babel jTCHe/ob-error-yHOivA"); output destination (like 
call-process's DESTINATION)
  nil ; 
display
 "-c"; args
  "cmdproxy.exe"   ; args
)

Of course, I imagine the paths would be Windows paths when run on Windows.

According to the documentation, the args are passed to the process 
(cmdproxy.exe) "verbatim without filename handling, as `call-process' does."  
The `call-process' documentation says, "remaining arguments ARGS are strings 
passed as command arguments to PROGRAM."

To me, that sounds like cmdproxy.exe gets "passed into" cmdproxy.exe.  This 
would explain the nested shell calls.  If all this were written out, I imagine 
it would look something like:

cmdproxy.exe -c cmdproxy.exe

What's not clear to me is how the INPUT-FILE is handled.  

The `process-file' documentation says "normally".  I assume it's how 
`call-process' handles INPUT-FILE, but the documentation doesn't really address 
it.

Finally, `process-file' finally calls `call-process'.

4. Calls `(apply 'call-process program (or lc infile) (if stderr-file (list 
(car buffer) stderr-file) buffer) display args)'

This evaluates as...

(apply 'call-process 
   program  
; cmdproxy
  (or lc infile)
  ; local-copy of the INFILE,  "/path/to/temp/containing/block/source" 
  (if stderr-file (list (car buffer) stderr-file) buffer)  ; (t 
"/tmp/babel jTCHe/ob-error-yHOivA"  )
  display   
  ; nil
  args) 
; ("-c"  "cmdproxy.exe")

How this actually works is non-trivial 
(https://git.savannah.gnu.org/cgit/emacs.git/tree/src/callproc.c#n250) and not 
something I understand at the moment.  We can see here that indeed a call like 
`cmdproxy.exe -c cmdproxy.exe' is being made.  Still, I'm not sure how the 
INPUT-FILE gets processed.  For example, is it passed in the second cmdproxy 
call?  Or, maybe it gets called first and then the second call to cmdproxy 
happens and hangs?  I don't know.

 > Any ideas on how to proceed from here?

I have two ideas.

1. Another naive work around attempt.  Again, I'm going from memory, 
documentation, and what I have previously written.  

I have in my init a command to open a terminal when working on Windows that 
looks like:

(start-process "cmd" nil "cmd.exe" "/C" "start" "cmd.exe" "/K" "cd" dir)

This starts a cmd process with /c which terminates the prompt after the command 
that follows is run.  The command  That follows starts another cmd process with 
/k which changes the directory and leaves the terminal open.

I have another command to open QGIS that does the same thing:

(start-pro

[BUG] Many babel-stable-nnn fodlers created in folders with org files (instead of in /tmp) [9.6.1 ( @ /home/bhrgunatha/.emacs.d/elpa/org-9.6.1/)]

[bhrgunatha]

Reporting this from emacs 28, but I first noticed in a freshly compiled
version of emacs.

This does NOT occur in org 9.5.5 that is included with emacs 28.
I do not have any special configuration for org babel.


Open emacs.
Open some .org file with src blocks in some folder /some.org
Notice a new folder called babel-stable-nnn (some randome 3 digit
number) appears in the folder containing the .org file.

I think these should be created in my /tmp/ folder, not the folder
containing the .org file.

Sometimes they ARE created in my /tmp/ folder.

These bable-stabe-nnn folders are usually deleted but they sometimes
persist even after closing emacs.

The following generated by M-x org-submit-bug-report:
My full org configuration follows that.


Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.36, cairo version 1.17.6)

 of 2023-01-03
Package: Org mode version 9.6.1 ( @ 
/home/bhrgunatha/.emacs.d/elpa/org-9.6.1/)


current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-hide-emphasis-markers t
 org-bibtex-headline-format-function #[257 "\300
\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

 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-archive-hook '(org-attach-archive-delete-maybe)
 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-mode-hook '(#[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-superstar-mode org-indent-mode variable-pitch-mode)
 org-ellipsis " ↷"
 org-confirm-shell-link-function 'yes-or-no-p
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-use-speed-commands '(lambda nil
  (and (looking-at org-outline-regexp)
   (looking-back "^**"))
  )
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-hide-leading-stars t
 org-pretty-entities t
 org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 org-fold-core-isearch-open-function 'org-fold-core--isearch-reveal
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-link-shell-confirm-function 'yes-or-no-p
 org-babel-pre-tangle-hook '(save-buffer)
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("attachment" :follow org-attach-follow :complete
    org-attach-complete-link)
   ("id" :follow org-id-open)
   ("eww" :follow org-eww-open :store 
org-eww-store-link)

   ("rmail" :follow org-rmail-open :store
    org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store 
org-mhe-store-link)

   ("irc" :follow org-irc-visit :store
    org-irc-store-link :export org-irc-export)
   ("info" :follow org-info-open :export 
org-info-export

    :store org-info-store-link :insert-description
    org-info-description-as-command)
   ("gnus" :follow org-gnus-open :store
    org-gnus-store-link)
   ("docview" :follow org-docview-open :export
    org-docview-export :store org-docview-store-link)
   ("bibtex" :follow org-bibtex-open :store
    org-bibtex-store-link)
   ("bbdb" :follow org-bbdb-open :export 
org-bbdb-export

    :complete org-bbdb-complete-link :store
    org-bbdb-store-link)
   ("w3m" :store org-w3m-store-link)
   ("doi" :follow org-link-doi-open :export
    org-link-doi-export)
   ("file+sys") ("file+emacs")
   ("shell" :follow org-link--open-shell)
   ("news" :follow
    #[514 "\301\300\302Q\"\207"
  ["news" browse-url ":"] 6 "\n\n(fn URL ARG)"]
    )
 

Make org-paste-subtree more predictable and useful

[Philipp Kiefer]

Hello there, orgmode list, this is my first contribution here, so please be
gentle with me.

I've now used outlining software for the last twenty years at least and it
is my belief that when a user pastes headlines into an outline, they
usually want to make them either A) siblings of (i. e. paste them at the
same level as) or B) children of (i. e. paste them one level below) the
currently focused heading.

Unfortunately, org-paste-subtree currently attempts to "modify the level of
the subtree to make sure the tree fits in nicely at the yank position"
[from Org Manual]. For me, this has meant unpredictable results. As far as
I know, there is currently no way to use the command while making sure the
result will be A) or B) as desired. The user has to wait for the command to
do its "magic" and then move the headings around manually to achieve the
intended result.
With a numeric prefix argument or by yanking after a headline marker, the
user can specify the yank level. But how likely is it that a user will yank
headings to level five under a level two heading?

I can solve my problem with some additional code, in which I determine the
level of the heading at point and then have two functions to call for same
level or child level respectively, but it strikes me as odd that this is
not part of the default options.

My suggestion would be to make a fundamental change to how the command
works, prioritizing definite A) or B) type results over the current vague
"the tree fits in nicely" approach. IMHO the default should be to yank at
the same level as the focused heading. Then, if the C-u 0 numeric prefix
(which currently produces an error message) were used to yank at one level
below that (as subheadings of the focused heading), the functionality of
the other numeric prefixes to set the yank level could be preserved.

Thanks for considering!

Best regards,

Philipp

[BUG] Org babel does not evaluate last line in Windows shell (cmdproxy.exe) code blocks [9.5.2 (release_9.5.2-25-gaf6f12 @ c:/tools/emacs-28.1/share/emacs/28.1/lisp/org/)]

[Osher Jacob]

*Expected behaviour*:
All lines of the shell block should be evaluated, with full output printed.

*Actual behaviour*:
All lines but the last are evaluated, the output ends with 'More?'
instead of the last command's output.

*Steps to reproduce*:
In Windows, start a clean Emacs instance (I used "runemacs.exe -Q"), and
evaluate the following blocks:

1) Enable shell language support
#+begin_src elisp
(org-babel-do-load-languages
   'org-babel-load-languages
   '(
 (shell . t)
 )
   )
#+end_src

#+RESULTS:


2) Evaluate this shell code block
#+begin_src shell
  echo 1
  echo 2


#+end_src

#+RESULTS:
| Microsoft | Windows   | [Version | 10.0.19044.2364] |
   |   |
| (c)   | Microsoft | Corporation. | All  |
rights | reserved. |
|   |   |  |  |
   |   |
| c:\Users\osherj>echo  | 1 |  |  |
   |   |
| 1 |   |  |  |
   |   |
|   |   |  |  |
   |   |
| c:\Users\osherj>More? |   |  |  |
   |   |


*Additional info:*
After some debugging, it seems to be caused by a missing newline character
at the
end of the code block content.
I believe this is caused by the org-trim function which is called upon the
body of the block.
At the function:
org/ob-shell.el -> (defun org-babel-sh-evaluate ...)
The line:
(org-babel-eval shell-file-name (org-trim body))

What led me to this conclusion, is because I've found that the function
"shell-command-on-region" (and I'm guessing its babel counterpart -
"org-babel--shell-command-on-region"), produces the same behaviour if the
region does not include a newline at its end.

Note: The bug seems to be reproducible in Emacs 28.2 as well

*Suggested fix*:
The hacky way I solved it was to change this line:
(t (org-babel-eval shell-file-name (org-trim body))
to this:
(t (org-babel-eval shell-file-name (concat (org-trim body) "\n"))

Let me know if there's any other information you need, or if I can help in
any other way.

Thanks!
Osher


Emacs  : GNU Emacs 28.1 (build 52, x86_64-w64-mingw32)
 of 2022-04-04
Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @
c:/tools/emacs-28.1/share/emacs/28.1/lisp/org/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-odt-format-inlinetask-function
'org-odt-format-inlinetask-default-function
 org-ascii-format-drawer-function #[771 " \207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines org-optimize-window-after-visibility-change)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-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-babel-load-languages '((shell . t))
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-latex-format-headline-function
'org-latex-format-headline-default-function
 org-confirm-shell-link-function 'yes-or-no-p
 org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
 org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-link-shell-confirm-function 'yes-or-no-p
 org-babel-pre-tangle-hook '(save-buffer)
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link) ("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link) ("rmail" :follow org-rmail-open
:store org-rmail-store-link) ("mhe" :follow org-mhe-open :store
org-mhe-store-link)
  ("irc" :follow org-

Re: org-todo-keywords and task sequence

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> The problem is (I think), when you attach @ or ! to the state and, as you
>> cycle thru (S-right), new unintended notes will be added as you cycle to
>> the state you're looking for.  True?
>
> If you attach @ or !, those notes are not unintended.
> S-right is not for you to play around, it is for actual work on actual
> tasks. If you tell Org to take a not on switching to next TODO state,
> that's what you want. If you don't want it, don't put @ or !.

I think I understand what you're saying, but the last statement seems
wrong and should be "don't use cycling or sequences".  Notes are much
more important feature.

What I've been saying is that, except for simple sequences, cycling will
get you into trouble with notes as a lazy person (aren't we all?) may
cycle thru something unintended.

>> Can you repeat a keyword in org-todo-keywords? Perhaps there should be a
>> sparse table defining, for a current state, what are the potential next
>> states? ...
>
> No. S-right feature is there for simple workflows.
> I am against introducing complex workflows for no reason.
> It will do no good for the users. Complex workflows are rarely useful in
> practice, except some specialized scenarios, which are not common enough
> to include into the core.

The problem is that todo keywords are being treated both as "state"
(sequence) and "type" (type) which mixes things up.  I guess I'm used to
thinking of workflows as a digraph -- particularly in big projects where
you want to be able to justify your work to the boss.  But, I guess
that's clock in/out.

> And yes, you can use org-edna or custom org-trigger-hook if you need
> something non-orthodox.

I'll have to look at org-edna more.

Thanks

-- 
David Masterson

Re: org-todo-keywords and task sequence

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>>> #+TODO: WAIT IN-PROCESS
>>> #+TODO: TODO IN-PROCESS | DONE
>>
>>> Note, however, that moving S- will be ambiguous.
>>
>> Ambiguous or not possible?
>
> Ambiguous is: consider a task IN-PROCESS and you press S-left. Should
> Org go to TODO or to WAIT? Org will choose one, but there are no defined
> rules.

Ah.  Could Org offer a choice of TODO or WAIT (a la Ido style)?

-- 
David Masterson

Re: org-todo-keywords and task sequence

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> The problem is (I think), when you attach @ or ! to the state and, as you
>> cycle thru (S-right), new unintended notes will be added as you cycle to
>> the state you're looking for.  True?
>
> If you attach @ or !, those notes are not unintended.
> S-right is not for you to play around, it is for actual work on actual
> tasks. If you tell Org to take a note on switching to next TODO state,
> that's what you want. If you don't want it, don't put @ or !.

Or cycling -- note taking is much more important and cycling only works
for simple workflows.  My previous example shows how easy it is to make
a (by Org definition) "complex" workflow.  I could probably use tags for
changing states, but notes are not automatic.  And you're using two
things for essentially the same purpose (state transition).

>> Can you repeat a keyword in org-todo-keywords? Perhaps there should be a
>> sparse table defining, for a current state, what are the potential next
>> states? ...
>
> No. S-right feature is there for simple workflows.  I am against
> introducing complex workflows for no reason.  It will do no good for
> the users. Complex workflows are rarely useful in practice, except
> some specialized scenarios, which are not common enough to include
> into the core.

If org-todo-keywords has no sequence, does S-right cycle?  I suppose I
could shift to just types and tags and avoid S-right.

Workflows can easily get complex -- just add WAIT and HOLD for example.

> And yes, you can use org-edna or custom org-trigger-hook if you need
> something non-orthodox.

I'll have to explore org-edna more.  I do think that the use of
"sequence" in org-todo-keywords complicates the variable because it
talks about "simple workflow" and leaves people wondering (like me) how
to change their view of a workflow to fit Org.

I'll play with it some more.

-- 
David Masterson

Re: [PATCH 0/4] Structure editing when region is active

[Samuel Wales]

On 1/17/23, Ihor Radchenko  wrote:
>>   * one
>>   ** two
>>
>> which seemed slightly relevant to the patch.
>
> Sorry, but could you further elaborate? What kind of integrity and what
> kind of structure editing do you have in mind here?

maybe my comment is too unrelated to the patch, but it just seemed
worth raising in the context.  to me it feels wrong to have a
non-linline-task child entry whose heading is star-indented more
levels than needed to denote a child entry.

in my own case, it suggests corruption, because i would not
deliberately create that.  i have encountered it.  similarly if
org-odd-levels-only is non-nil and there is an even star heading.  i
have encountered it.  confusing to track down.

i was merely asking if there was anything in e.g. main or syntax
documents etc. that refers to or enforces this.


as for active region or transient mark, to me, they are supposed to be
transient, unlike, for example, agenda restriction lock, and thus, for
example, having to c-g or so to get rid of a highlighted region feels
like a bug.

there might be exceptions where you pretty much always want to run a
command more than once with the region remaining active, perhaps such
as a rectange opening type of command, but to me the patch commands do
not apply there.

[BUG] org-agenda: definition is void: org-element--cache-active-p

[zimoun]

Hi,

The reproducer using Emacs 28.2 and Org 9.6.1 both from Guix (29efa27):

--8<---cut here---start->8---
$ cd /tmp/
$ cat config.el
(setq
 org-directory "/tmp/"
 org-agenda-files '("example.org"))
$ cat example.org
* TODO Stuff
$ emacs -q -l config.el -f org-agenda

Press m  Match a TAGS/PROP/TODO query

Error:
org-get-buffer-tags: Symbol's function definition is void: 
org-element--cache-active-p

$ emacs -q -l config.el --eval '(org-batch-agenda "m")' --batch
Debugger entered--Lisp error: (void-function org-element--cache-active-p)
  org-element--cache-active-p()
  org-get-buffer-tags()
  org-make-tags-matcher(nil)
  org-tags-view(nil)
  funcall-interactively(org-tags-view nil)
  call-interactively(org-tags-view)
  org-agenda(nil "m")
  #f(compiled-function () #)()
  funcall(#f(compiled-function () #))
  (let nil (funcall '#f(compiled-function () #)))
  eval((let nil (funcall '#f(compiled-function () #
  org--batch-agenda("m" nil nil)
  (org-batch-agenda "m")
  command-line-1(("-l" "config.el" "--eval" "(org-batch-agenda \"m\")"))
  command-line()
  normal-top-level()
--8<---cut here---end--->8---

To be precise, it is run inside a Linux namespace container:

guix shell --container emacs emacs-org -E TERM \
 -- emacs -q -l config.el -f org-agenda


This message [1] about a similar topic leads to this commit
791ea50528df55bac110fe5e2731af056989bedb [2]:

--8<---cut here---start->8---
* lisp/org-element.el (org-element--cache-active-p): Fix compiler warning
Using `defsubst' here is impractical because some code above does call
`org-element--cache-active-p'.  Moving would trigger major refactoring
for little gain.  Hence, move back to using simple `defun' until we
modularize lisp/org-element.el better.

Reported-by: No Wayman 
Link: https://orgmode.org/list/874jws2v87@gmail.com
--8<---cut here---end--->8---

and I guess it is related.  Especially with release note 9.6 [3]:

Element cache is enabled by default and work for headings

Obviously, loading org-element fixes the issue:

$ emacs -q -l config.el --eval "(require 'org-element)" -f org-agenda

Therefore, maybe the addition of such requirement in org-agenda.el could
be enough?

1:
[BUG] org-element: defsubst org-element--cache-active-p used before defined
Tue, 27 Sep 2022 20:32:36 -0400
id:874jws2v87@gmail.com

2: 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=791ea50528df55bac110fe5e2731af056989bedb
3: 

Cheers,
simon

Re: New face: org-agenda-calendar-timerange

[gautier]

Ihor Radchenko  writes:


"timerange" is a bit confusing because the patch will only affect date
ranges like <2022-12-22 Thu>--<2023-01-01 Sun> and
<2022-12-22 Thu 12:00>--<2023-01-01 Sun 10:00>, but not time ranges
<2022-12-22 Thu 10:00-12:00>

Is it what you are proposing? Or do you also want to include the time 
ranges?



Hello Ihor,

Currently, the entries with a time range of the form
<2022-12-22 Thu 10:00-12:00>
use the face 'org-agenda-calendar-event'.
While the entries with time ranges of the form
<2022-12-22 Thu>--<2023-01-01 Sun>, or
<2022-12-22 Thu 12:00>--<2023-01-01 Sun 10:00>, or even
<2023-01-01 Sun 10:00>--<2023-01-01 Sun 15:00>
use the default face.

The face in the patch would apply to the second type of entries. These
second type of entries are precisely the ones to which applies the
'org-agenda-timerange-leaders', this is why I have chosen the name
"org-agenda-calendar-timerange". Another name would be fine though,
maybe "daterange" instead of "timerange"? (However, it would be less
consistent with the 'org-agenda-timerange-leaders' name or the last
example <2023-01-01 Sun 10:00>--<2023-01-01 Sun 15:00>.)

All the best,
Gautier.

Re: [BUG] ob-shell doesn't evaluate last line on Windows (cmd/cmdproxy) [9.6.1 ( @ c:/Users/Osher/AppData/Roaming/.emacs.d/elpa/org-9.6.1/)]

[Osher Jacob]

Hey, thanks for the input!
My shell-file-name is indeed pointing to cmdproxy.exe, and after changing
shell-command-switch to "/k" or "-k", I get a similar output:

#+begin_src shell
  echo 1
  echo 2
  echo 3

#+end_src

#+RESULTS:
| Microsoft| Windows | [Version  | 10.0.14393]  | ||
|
| (c)  |2016 | Microsoft | Corporation. | All | rights |
reserved. |
|  | |   |  | ||
|
| c:\tmp>echo  |   1 |   |  | ||
|
| 1| |   |  | ||
|
|  | |   |  | ||
|
| c:\tmp>echo  |   2 |   |  | ||
|
| 2| |   |  | ||
|
|  | |   |  | ||
|
| c:\tmp>More? | |   |  | ||
|

Where only the last line is missing.

Another observation that might be relevant, is that the block execution
works well when I set shell-file-name to "powershell.exe"

#+begin_src shell
  echo 1
  echo 2
  echo 3

#+end_src

#+RESULTS:
| Windows   | PowerShell |  |   |  | ||
  |
| Copyright | (C)| 2016 | Microsoft | Corporation. | All | rights |
reserved. |
|   ||  |   |  | ||
  |
| PS| C:\tmp>| echo | 1 |  | ||
  |
| 1 ||  |   |  | ||
  |
| PS| C:\tmp>| echo | 2 |  | ||
  |
| 2 ||  |   |  | ||
  |
| PS| C:\tmp>| echo |33 |  | ||
  |
| PS| C:\tmp>|  |   |  | ||
  |

And here, it might be that the missing newline in the last command is
visible, hence the double '3' character (one is a part of the "echo 3"
input, the second is the output "3" echoed back).

You also mentioned the source code block is being passed through the "-c"
flag as a command-line argument.
I might be misunderstanding something here, but it seems like it is being
passed through the stdin of the shell process when the calls process-file
-> call-process are being made.

Just to confirm, I've made a simple utility that prints the contents of
argc and argv as hex strings, and got the following output when setting it
in place of the the shell-file-name:

#+begin_src shell
  echo 1
  echo 2
  echo 3


#+end_src

#+RESULTS:
| argc:  | 3 |
| 633a5c6d73797336345c686f6d655c4f736865725c6563686f5f6865782e657865 |   |
| 2d63   |   |
| 633a2f6d73797336342f686f6d652f4f736865722f6563686f5f6865782e657865 |   |

Which translates to:
c:\msys64\home\Osher\echo_hex.exe -c c:/msys64/home/Osher/echo_hex.exe

Exposing that there are two nested shell-file-name running.

And now I was curious to see if babel executes cmdproxy.exe -c
cmdproxy.exe, so I fired up Procmon, and indeed that was the case (see
attached screenshot).

[image: image.png]

Not sure if this nesting is really relevant to the problem at hand, but
thought it could be useful information.

Any ideas on how to proceed from here?


On Tue, Jan 17, 2023 at 3:07 AM Matt  wrote:

>
>   On Mon, 16 Jan 2023 16:40:27 -0500  Matt  wrote ---
>  > That is, go through the steps to reproduce and before executing the
> block, run `M-: (setq shell-command-switch "/k")'.
>
> Whoa, just re-read this after stepping away and it sounds super
> demanding!  Please excuse me, I've been trying to use active voice while
> writing documentation.
>
> Let me try that again:
>
> What happens if you go through the steps to reproduce and run `M-: (setq
> shell-command-switch "/k") before executing the block?
>

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Max Nikulin  writes:

> https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
>Falsehoods programmers believe about time

Some potentially relevant items:

- Each calendar date is followed by the next in sequence, without
  skipping.
- The standard library supports negative years and years above 1
- The day of the month always advances contiguously from N to either N+1
  or 1, with no discontinuities.
- There are 60 seconds in every minute.

All the above statements are FALSE!

All the above statements may affect, in particular, timestamps with
repeaters. Repeaters like +1h or +1d may require querying the TZdb (time
API).

Some good news is that all the above edge cases would equally affect the
current Org's timestamp handling code. Yet, we have no bug reports in
this area. I'd even go further and say that we should not try hard to
make things 100% accurate: (1) it will waste a lot of resources; (2)
users dealing with these edge cases are likely already accustomed to
most programs not handling things correctly for their special time zone
situations.

That said, if there is an easy way to handle some of the edge cases, we
can implement them.

Important: if some edge cases with time zones are buggy in OS time API,
it is not Org's job to work around the problem - we should rather report
those bugs upstream. What we should check, however, is the Org's own
ad-hoc code that is dealing with timestamps. In particular, I am
concerned about the repeater intervals. We will need to carefully review
the code to avoid nasty surprises.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-todo-keywords and task sequence

[Ihor Radchenko]

David Masterson  writes:

>> #+TODO: WAIT IN-PROCESS
>> #+TODO: TODO IN-PROCESS | DONE
>
> This is on a per-file basis, correct?  This can't be done in
> org-todo-keywords? 

It can. You can have multiple 'sequence-s there.

>> Note, however, that moving S- will be ambiguous.
>
> Ambiguous or not possible?

Ambiguous is: consider a task IN-PROCESS and you press S-left. Should
Org go to TODO or to WAIT? Org will choose one, but there are no defined
rules.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-todo-keywords and task sequence

[Ihor Radchenko]

David Masterson  writes:

> The problem is (I think), when you attach @ or ! to the state and, as you
> cycle thru (S-right), new unintended notes will be added as you cycle to
> the state you're looking for.  True?

If you attach @ or !, those notes are not unintended.
S-right is not for you to play around, it is for actual work on actual
tasks. If you tell Org to take a not on switching to next TODO state,
that's what you want. If you don't want it, don't put @ or !.

> Can you repeat a keyword in org-todo-keywords? Perhaps there should be a
> sparse table defining, for a current state, what are the potential next
> states? ...

No. S-right feature is there for simple workflows.
I am against introducing complex workflows for no reason.
It will do no good for the users. Complex workflows are rarely useful in
practice, except some specialized scenarios, which are not common enough
to include into the core.

And yes, you can use org-edna or custom org-trigger-hook if you need
something non-orthodox.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-todo-keywords and task sequence

[David Masterson]

Ihor Radchenko  writes:

F> David Masterson  writes:
>
>> I'm not sure I understand 'sequence' and 'type' in org-todo-keywords.
>> In particular, I can only think of the following simple sequence as
>> being possible in org-todo-keywords:
>>
>> TODO -> IN-PROCESS -> DONE
>>
>> If I want to add in (say) WAITING, the graph (represented as a table)
>> becomes:
>>
>> i\o  | TODO | IN-P | WAIT | DONE
>> TODO |  N   |  Y   |  N   |  N
>> IN-P |  N   |  N   |  Y   |  Y
>> WAIT |  N   |  Y   |  N   |  N
>> DONE |  N   |  N   |  N   |  N
>
> The main purpose of the keyword sequences is working on tasks in steps.
> When a keyword is a part of sequence, you can just use S-
> S- to progress the task. For example:
>
> NEXT -> DOING -> REVIEW -> DONE 
>
> Such sequence is only making sense when everything goes "as usual" with
> a task and you do not want to think about which keyword to assign.
>
> The transition IN-PROGRESS -> WAIT is something you have to decide
> consciously. Org cannot just read you mind and change IN-PROGRESS to
> WAIT. You will have set such transition manually.
>
> For your table, you can try something like
>
> #+TODO: WAIT IN-PROCESS
> #+TODO: TODO IN-PROCESS | DONE

This is on a per-file basis, correct?  This can't be done in
org-todo-keywords? 

> Note, however, that moving S- will be ambiguous.

Ambiguous or not possible?

Perhaps there should be a sparse table var to represent the table above
and drop sequence?  More flexible?  Org-Edna?

-- 
David Masterson

Re: org-todo-keywords and task sequence

[David Masterson]

Daniel Fleischer  writes:

> Daniel Fleischer [2023-01-17 Tue 10:10] wrote:
>
>> Don't let the cyclical switching dictates the meaning, it's just an
>> implementation detail, done for simplicity. Hope it helped.
>
> Put another way, if you define A B | C D E
>
> and the UI switching is A->B->C->D->E->A
>
> it doesn't mean the B going into C makes sense or D going into E makes
> sense, it's just how the UI is built. You give meaning to the states and
> what states transitions are valid (in your world). Like many things, org
> gives some structure to work with and we need to give the meaning.

The problem is (I think), when you attach @ or ! to the state and, as you
cycle thru (S-right), new unintended notes will be added as you cycle to
the state you're looking for.  True?

Can you repeat a keyword in org-todo-keywords? Perhaps there should be a
sparse table defining, for a current state, what are the potential next
states?  Org-Edna...?

-- 
David Masterson

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Max Nikulin]

On 17/01/2023 01:37, Ihor Radchenko wrote:

Some formats may be confusing for users, e.g. TZ=GMT+5 actually means
-0500 offset.

Let's just recommend +- and @location in the manual. And mention
briefly that TZ format is supported in addition.

We might also provide an optional linter for GMT, if necessary.


"GMT" in this example is an arbitrary string. It adds some complications 
to the linter.


Notice that in POSIX "GMT+5" is *definition* of timezone with "GMT" 
abbreviation and shifted by 5 hours to the west. It is not a *reference* 
to IANA (Olson) Etc/GMT+5. I do not remember concerning "GMT", but Qt 
allows to use something like "UTC+5" (east like IANA, not west like 
POSIX). I am unsure concerning Windows, it may have an option of quite 
similar variant. That is why I am not sure to which degree Org should be 
liberal in respect to various time zones.

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Max Nikulin]

On 17/01/2023 02:07, Ihor Radchenko wrote:

https://www.youtube.com/watch?v=-5wpm-gesOY gives various examples.


More links:
- https://stackoverflow.com/tags/timezone/info
- 
https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

  Falsehoods programmers believe about time

Observation of hysteresis in a GNU libc time conversion function

[Max Nikulin]

#+title: Observation of hysteresis in a GNU libc time conversion function

#+begin_abstract
The ~mktime~ function in GNU libc for specific arguments
may possess properties similar to ferromagnetic materials.
Dependence of returned value on arguments passed during
earler calls gives evidences that it has hidden state.
#+end_abstract

I was experimenting with a code sample posted to the thread on
support of time zones in Org. I noticed rather strange behavior
of ~encode-time~ and thus underlying ~mktime~ function.
At first I considered it as non-deterministic, but later
I realized that time zone offset calculated earlier
may affect following calls. I was aware that the function is
not pure since it calls ~tzset~ to initialize time zone from
the ~TZ~ environment variable and e.g. ~tzname~ global variable.
It was a surprise that the function can not be considered
even as a stable one. Passing same arguments may lead
to different results. I am unsure whether it is intentional
or at least known property.

#+begin_src elisp :exports nil :results silent
  (require 'ob-shell)
  (require 'ob-gnuplot)
#+end_src

Let's take some backward time transition, so with ambiguous local time,
where daylight saving time state is not changed and preferably
is not in action. As a result it is impossible to disambiguate
whether local time is before or after time jump.
Attempt to specify ~dst~ as ~t~
(or set ~t.tm_isdst = 1~ for ~mktime~) will lead to an error.

#+begin_src sh :results verbatim :exports both
  zdump -v Africa/Juba | grep 2021
#+end_src

#+RESULTS:
: Africa/Juba  Sun Jan 31 20:59:59 2021 UT = Sun Jan 31 23:59:59 2021 
EAT isdst=0 gmtoff=10800
: Africa/Juba  Sun Jan 31 21:00:00 2021 UT = Sun Jan 31 23:00:00 2021 
CAT isdst=0 gmtoff=7200


We may convert broken down local time representation
around 23:30 local time
for a sequence of time moments passing values to ~encode-time~
in increasing and decreasing their order.
Under the hood the function calls the =mktime(3)= function.

#+name: timestamp
#+header: :exports code
#+begin_src elisp :var tz="Africa/Juba" :var t0='(0 30 23 31 1 2021)
(let* ((f (lambda (minutes)
(float-time
 (encode-time
  (list (nth 0 t0) (+ (nth 1 t0) minutes) (nth 2 t0)
(nth 3 t0) (nth 4 t0) (nth 5 t0)
nil -1 tz)
   (dt '(-90 -60 -31 -30 -29 -15 0 15 29 30 31 60 90))
   (values (mapcar (lambda (m)
 (cons m (funcall f m)))
   dt))
   (ts0 (cdr (nth (/ (length values) 2) values
  (mapcar (lambda (pair)
(let ((m (car pair)))
  (list m (- (cdr pair) ts0) (- (funcall f m) ts0
  (reverse values)))
#+end_src

#+RESULTS: timestamp
|  90 |  9000.0 |  9000.0 |
|  60 |  7200.0 |  7200.0 |
|  31 |  5460.0 |  5460.0 |
|  30 |  5400.0 |  5400.0 |
|  29 |  1740.0 |  5340.0 |
|  15 |   900.0 |  4500.0 |
|   0 | 0.0 |  3600.0 |
| -15 |  -900.0 |  2700.0 |
| -29 | -1740.0 |  1860.0 |
| -30 | -1800.0 |  1800.0 |
| -31 | -1860.0 | -1860.0 |
| -60 | -3600.0 | -3600.0 |
| -90 | -5400.0 | -5400.0 |

#+begin_src gnuplot :file mktime-hyst.png :var data=timestamp
  set key bottom right
  set xlabel 'minutes'
  set ylabel 'UNIX epoch difference, seconds'
  set title 'Hysteresis in GNU libc mktime'
  plot data using 1:2 with lp title 'increasing', \
 '' using 1:3 with lp title 'decreasing'
#+end_src

#+RESULTS:
[[file:mktime-hyst.png]]

So result for the same arguments may depend on previous calls.

Likely it is due to a
[[https://sourceware.org/git/?p=glibc.git;a=blob;f=time/mktime.c;h=94a4320e6ca9d935fc534991f9b57a2f1cc185de;hb=HEAD#l544][static 
variable]]

used in the =mktime.c= file. Such a variable appeared in the commit
[[https://sourceware.org/git/?p=glibc.git;a=commit;h=80fd73873b][80fd73873b]]
#+begin_example
Fri Sep 29 03:43:51 1995  Paul Eggert

Rewrite mktime from scratch for performance, and for correctness
in the presence of leap seconds.
#+end_example

Perhaps hidden internal state may be used to disambiguate local
time values around backward time steps with unchanged daylight
saving time. Unfortunately relying on such implementation details
hardly can be considered as a robust approach.

Re: org-agenda-files: using variables

[Nick Dokos]

"Loris Bennett"  writes:

> Hi,
>
> I have
>
>   (setq lb/org-directory "~/org/"))
>   (setq lb/gtd-file (expand-file-name "gtd.org" lb/org-directory))
>   (setq lb/refile-file (expand-file-name "refile.org" lb/org-directory))
>   (setq org-agenda-files '(lb/gtd-file lb/refile-file))
>
> But generating the agenda fails with
>
>   Wrong type argument: stringp, lb/gtd-file  
>
> What is the correct syntax to use the variables in the list?
>

Quoting quotes everything including symbols, so you either do not
quote or use backquote:

  (setq org-agenda-files (list lb/gtd-file lb/refile-file))
  (setq org-agenda-files `(,lb/gtd-file ,lb/refile-file))

In this case, I'd prefer the first form, but the second form is often
useful - see

  (info "(elisp)Backquote")

-- 
Nick

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Ihor Radchenko  [2023-01-16 22:08]:
> 1. Time (-MM-DD HH:MM) not continuous and may change arbitrarily at
>certain times a year or in future or in the past:

I am sure that system library must be responsible to know those
changes. It is not for Org. 

So the calculation which transforms +1 time zone to -5 time zone shall
be done by using system libraries which are supposed to have those
options. I have no idea if they have.

> 2. There might be arbitrary time gaps due to time transition, including

>- One hour back during DST transition (northern and southern
>  hemispheres do the transitions in opposite directions)
>- Multiple days skipped (Samoa skips a whole day during DST
>  transition)

Interesting, but I still think that shall be in system library, and
system libraries shall provide calculation functions. 

Does that exist in C library?

> 3. We cannot assume that the same geographical area has fixed time zone
>even at given point of time:
>- Palestinian/Israeli people follow different time zones in the
>  contested territories

They may, sure, I can also follow my own, but Org and system libraries
shall use internationally accepted norms.

> 4. Great Britain had new year on March 25 until 16th century
>(March 24, 1000 -> (+1 day) March 25, 1001)

Of course, that is why December is called by that way, as the tenth
month, not twelfth. That may be part of representation of calendar,
but because it is history, it is not so important for us in future.

> 5. Leap seconds! 23:59:59 -> 23:59:60 -> 00:00:00, according to
>astronomical Earth observations

Should be part of C library to observe those things.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Ihor Radchenko  [2023-01-16 14:21]:
> In another message, I also mentioned an idea of specifying time zone
> globally or per file. Other suggestion was per-heading specification. In
> addition to time zone being specified directly inside the timestamp.

Of course that is solution. iCalendar export already supports time
zones. It was logical to author or maybe requirement of iCalendar.

And then comes the calculation, there must be way to re-calculate
representation of timestamps:

When there is global variable for Org file about time zone, then:

- every timestamp with time zone, shall be left intact or
re-calculated to diffrent local time zone. Imagine person giving Org
file from Russia to somebody in Florida, or travelling there. That
user or recipient would like to see the actual time, which is time for
him in Florida, but in its representation different from time in
Russia.

- ever timestamp with settings in heading, shall be calculated as
such.

It means there shall be functions which can convert timestamps to the
new time zone, with the option to left unchanged those timestamps who
already have time zone specified, and with option not to be converted.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Ihor Radchenko  [2023-01-16 14:25]:
> Jean Louis  writes:
> 
> >> I am not sure what is the problem.
> >> The timestamps that should stay in local time will be automatically
> >> updated as your system TZ is updated.
> >
> > Then Org shall know what was local time! Without being specified in
> > the time stamp, it has to be specified somewhere, as computer can't
> > know at which time zone was it specified.
> 
> We need nothing to use current time zone. And we already do it.
> 
> System clock knows the current time zone. Emacs has an ability to
> determine current time zone. See `current-time-zone'. This works
> automatically (and already) because we use `encode-time'.

Then you did not understand the point.

For users who use Org personally, in single place, single time zone,
who do no travel, who do not share headings, tasks, and files
internationally, they really do not need hussle with time zones!

However, when nice strong guy makes an Org file with list of tasks in
Ukraine and send it to nice girl Florida, she will simply think that
at 9 o'clock she has to discuss making visa with her fiance, but
fiance is already pissed off because she did not appear at online
meeting.

Time zones are useful for:

- people who travel from one time zone to other;
- people who share Org files, headings, tasks;

Of course I was doing it since 2016 until some year when I realized
that there are serious human usability related limits. 

But let's review, what would it be, when it would be that Jean works
in Org:

I have switched from Org to Hyperscope in June 2021:

# SELECT hypeoplerelations_datecreated FROM hypeoplerelations WHERE 
hypeoplerelations_hypeoplereltypes = 2 LIMIT 1;
 hypeoplerelations_datecreated 
---
 2021-06-09 10:19:06.19327+03

That was the date when I slowly transitioned from sharing Org tasks to
people, in fact those were Org headings.

Since June 2021, I have shared 6176 time heading, without using Org,
to people all in various countries.

# SELECT count(1) FROM hypeoplerelations WHERE 
hypeoplerelations_hypeoplereltypes = 2;
 count 
---
  6176
(1 row)

Time zones are small detail that does matter. 

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

org-agenda-files: using variables

[Loris Bennett]

Hi,

I have

  (setq lb/org-directory "~/org/"))
  (setq lb/gtd-file (expand-file-name "gtd.org" lb/org-directory))
  (setq lb/refile-file (expand-file-name "refile.org" lb/org-directory))
  (setq org-agenda-files '(lb/gtd-file lb/refile-file))

But generating the agenda fails with

  Wrong type argument: stringp, lb/gtd-file  

What is the correct syntax to use the variables in the list?

Cheers,

Loris

-- 
This signature is currently under constuction.

Re: Help with a workflow to export plantuml diagrams

[Ihor Radchenko]

Ypo  writes:

> Could be the headlines exported in a faster way?
>
> Could be possible to avoid the duplication of information? (To create 
> the diagram directly from the headlines, without yanking a copy of them).

You can use noweb reference syntax.

#+name: collect-headings
#+begin_src emacs-lisp :results silent
;; Collect all the headings in current buffer.
(concat
 "* Top\n"
 (mapconcat
  #'identity
  (org-map-entries
   '(concat "*"
(buffer-substring-no-properties
 (line-beginning-position) (line-end-position
  "\n"))
#+end_src

#+begin_src plantuml :noweb yes :file my-diagram.png
@startwbs
<>
@endwbs
#+end_src

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Org-9.6 declares compatibility with Emacs-25.1

[Ihor Radchenko]

Ihor Radchenko  writes:

> We should fix this before Org 9.6.1.
> I will leave the decision about exact Emacs version to Bastien.
>
> One notable fact is that Debian oldstable we use on CI [1] appears to
> use Emacs 26.1. So, we are probably safe to declare Emacs 26.1
> compatibility.
>
> [1] https://builds.sr.ht/api/jobs/915058/manifest

Given that we have started getting some bug reports about Org not
working in Emacs 25, I just bumped the version requirement on bugfix.
This will prevents Emacs 25 installing incompatible versions of Org.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c7b976a05

Bastien, please let me know if you have any objections.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Throw an error when bibliography field is not properly parsed (was: [PATCH] oc-basic.el: Fix wrong type for the editors field when parsing JSON.)

[Ihor Radchenko]

Ihor Radchenko  writes:

> I am attaching tentative patch that will make
> `org-cite-basic--get-field' throw an error when the filed value is not a
> string.

Applied, onto main; with minor amendments.
I made the new code not throw error on nil return value.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=104311c7f

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Supporting non-free SQL clients in ob-sql (was: [PATCH] ob-sql: Add support for Athena)

[Tim Cross]

Ihor Radchenko  writes:

> Daniel Kraus  writes:
>
>> Tim Cross  writes:
>>
>>> I think you run a high risk of running into GNU policy issues wrt
>>> licensing and free software support given this is a cleint for an AWS
>>> only database.
>>
>> Is it because it's cloud only or because it's proprietary?
>
> Both. For cloud, see
> https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
> (we can have cloud service support, but only those that are not unjust)
>
>> Because we already support Orcale, SAP Hana, MSSql and Vertico for example.
>
> We probably should not.
> Ideally, we need universal SQL cli support and then move all non-free
> clients to external packages.

Well, we don't really support those other databases in the same sense as
is bieng proposed here for this AWS db. Those other databases are only
supported in the sense that you can tell sql mode you are using one of
them and you can add the necessary configuration parameters to make a
connnection, but that is it. We don't, for example, provide the Oracle
client in order to use the oracle database. The user has to install the
Oracle client separately.

So, you could likely modify sql-mode to support the ability to pass
necessary parameters to a client which can connect to the AWS database,
but you cannot bundle the client (in this case, the python code you
referenced).

The fact this is also a cloud based database does make the situation
worse as the official FSF and GNU position is that cloud based services
represent a reduction in user freedom because they do not control those
services and cannot see the soruce code - essentially, use of those
services makes you dependent on and to some extent beholding to (in this
case) Amazon. With the other non-free databases, such as Oracle, you can
at least install the database on your own hardware.

Re: New face: org-agenda-calendar-timerange

[Ihor Radchenko]

Gautier Ponsinet  writes:

> I would like to propose the introduction of a new face:
> org-agenda-calendar-timerange.
> It is used to show entries with a timerange in the agenda, that is,
> entries with a timestamp of the form:
> <2022-12-22 Thu>--<2023-01-01 Sun>
> At the moment, these entries with a timerange use the default face.
> Please find attached a patch.

Thanks!

"timerange" is a bit confusing because the patch will only affect date
ranges like <2022-12-22 Thu>--<2023-01-01 Sun> and
<2022-12-22 Thu 12:00>--<2023-01-01 Sun 10:00>, but not time ranges
<2022-12-22 Thu 10:00-12:00>

Is it what you are proposing? Or do you also want to include the time ranges?

> This is my first contribution (I just finished the copyright assignment
> process with the FSF), so any feedback would be greatly appreciated.

Bastien, could you please confirm?


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-cite-insert only searches on truncate author list

[Fraga, Eric]

Hi Ihor,

On Tuesday, 17 Jan 2023 at 10:22, Ihor Radchenko wrote:
> In oc-basic, there is `org-cite-basic-author-column-end' and it indeed
> truncates the match.  Eric, as temporary workaround, you can try to
> increase `org-cite-basic-author-column-end'.

Ah, interesting.  I had to restart Emacs (:-O) to get it to take effect
but it now works perfectly.  Thank you!  

> Note that completion might look ugly though.

It doesn't look ugly as I have a very wide monitor and although I tend
to write prose in a frame with >170 columns (typically split in two or
three windows), the minibuffer is full width so plenty of room for full
author list along with year and title.

> One needs to rewrite `org-cite-basic--complete-key' adding 'annotation
> function to `completing-read' call instead of passing the truncated
> author/title list as completion table. [...]

I'll add this to my list of possible things to do on org: ever growing,
including ox-beamer and a few other things.  Once my (paid ;-)) work
(teaching etc.) load lightens up hopefully, if ever...

Thanks again,
eric

-- 
: Eric S Fraga, with org release_9.6-201-gb58fba in Emacs 30.0.50

Re: org-todo-keywords and task sequence

[Ihor Radchenko]

David Masterson  writes:

> I'm not sure I understand 'sequence' and 'type' in org-todo-keywords.
> In particular, I can only think of the following simple sequence as
> being possible in org-todo-keywords:
>
> TODO -> IN-PROCESS -> DONE
>
> If I want to add in (say) WAITING, the graph (represented as a table)
> becomes:
>
> i\o  | TODO | IN-P | WAIT | DONE
> TODO |  N   |  Y   |  N   |  N
> IN-P |  N   |  N   |  Y   |  Y
> WAIT |  N   |  Y   |  N   |  N
> DONE |  N   |  N   |  N   |  N

The main purpose of the keyword sequences is working on tasks in steps.
When a keyword is a part of sequence, you can just use S-
S- to progress the task. For example:

NEXT -> DOING -> REVIEW -> DONE 

Such sequence is only making sense when everything goes "as usual" with
a task and you do not want to think about which keyword to assign.

The transition IN-PROGRESS -> WAIT is something you have to decide
consciously. Org cannot just read you mind and change IN-PROGRESS to
WAIT. You will have set such transition manually.

For your table, you can try something like

#+TODO: WAIT IN-PROCESS
#+TODO: TODO IN-PROCESS | DONE

Note, however, that moving S- will be ambiguous.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Support building Org from shallow clone [9.6.1 (release_9.6.1-137-gecb62e @ /home/n/.emacs.d/elpaca/builds/org/)]

[Ihor Radchenko]

No Wayman  writes:

> Ihor Radchenko  writes:
>
>> What we should not have is "make autoloads" failing without 
>> internet.
>
> The attached patch should take care of that.
> If the ls-remote errors, GITVERSION will be set to N/A as when it 
> is generally unavailable. 

I just tried your patch running make without internet. I got the
following Org version:

Subject: [BUG] test [9.6.1 ( @ /tmp/org-mode/lisp/)]

As you can see, the last commit number is not listed even though I can
see it via git log.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [patch] improved: add TTL as defcustom to ox-icalendar

[Ihor Radchenko]

Detlef Steuer  writes:

>> The patch only allows to the TTL globally for all the calendars.
>> However, it would make sense to specify TTL on per-file basis. WDYT?
>> 
>
> Hmm. Surely it would be useful to have the option to use different TTL
> settings for different calendar exports, yes.
>
> The next question would be, if org-icalendar-combine-agenda-files is
> called and the files have different per-file settings, which will be
> used?

The only sane way would be using the global default.

> May be single file org-icalendar-export-to-ics and
> org-icalender-export-agenda-files use an existing per-file setting,
> global setting otherwise, but org-icalendar-combine-agenda-files always
> uses the global setting?

Agree.

To achieve this you just need to update the export option settings:

(:icalendar-ttl nil nil org-icalendar-ttl)

adding a file keyword to be used.
See `org-export-options-alist' docstring.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[BUG] org-cite-insert only searches on truncate author list

[Ihor Radchenko]

"Fraga, Eric"  writes:

>> org-cite-insert simply calls whatever is provided by the citation
>> backend you use. Please tell us which oc-*.el backend is creating the
>> problem.
>
> Maybe I'm doing something wrong somewhere because whether I try basic,
> biblatex, or csl, they appear the same in terms of selection interface.
> Maybe it's something in vertico although I cannot see what it would be.

In oc-basic, there is `org-cite-basic-author-column-end' and it indeed
truncates the match.

oc-csl and oc-biblatex do not specify insert processor and thus the
default is used (from oc-basic).

So, I confirm the bug.

Eric, as temporary workaround, you can try to increase
`org-cite-basic-author-column-end'. Note that completion might look ugly
though.

One needs to rewrite `org-cite-basic--complete-key' adding 'annotation
function to `completing-read' call instead of passing the truncated
author/title list as completion table. See 21.6.7 Programmed Completion
section of Elisp manual.
https://github.com/alphapapa/org-ql/blob/master/org-ql-completing-read.el
also contains an example of implementing the annotations.

Patches welcome!

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Supporting non-free SQL clients in ob-sql (was: [PATCH] ob-sql: Add support for Athena)

[Ihor Radchenko]

Daniel Kraus  writes:

> Tim Cross  writes:
>
>> I think you run a high risk of running into GNU policy issues wrt
>> licensing and free software support given this is a cleint for an AWS
>> only database.
>
> Is it because it's cloud only or because it's proprietary?

Both. For cloud, see
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
(we can have cloud service support, but only those that are not unjust)

> Because we already support Orcale, SAP Hana, MSSql and Vertico for example.

We probably should not.
Ideally, we need universal SQL cli support and then move all non-free
clients to external packages.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [patch] improved: add TTL as defcustom to ox-icalendar

[Detlef Steuer]

Am Tue, 17 Jan 2023 09:43:18 +
schrieb Ihor Radchenko :

> Detlef Steuer  writes:
> 
> > I tried to follow your advice to improve the patch accordingly.
> > New version attached.  
> 
> I have amended your patch fixing some of the spelling issues and
> indentation. See the attached. Note that I used "time to live"
> consistently instead of "time to life". The former is the right
> abbreviation meaning, AFAIU
> (https://www.cloudflare.com/learning/cdn/glossary/time-to-live-ttl/)
> 

Thx!

> I also have a more general comment.
> 
> The patch only allows to the TTL globally for all the calendars.
> However, it would make sense to specify TTL on per-file basis. WDYT?
> 

Hmm. Surely it would be useful to have the option to use different TTL
settings for different calendar exports, yes.

The next question would be, if org-icalendar-combine-agenda-files is
called and the files have different per-file settings, which will be
used?

May be single file org-icalendar-export-to-ics and
org-icalender-export-agenda-files use an existing per-file setting,
global setting otherwise, but org-icalendar-combine-agenda-files always
uses the global setting?

Detlef

Re: org-cite-insert only searches on truncate author list

[Fraga, Eric]

On Tuesday, 17 Jan 2023 at 08:38, Ihor Radchenko wrote:
> ⚠️ Caution: External sender
>
>
> "Fraga, Eric"  writes:
>
>> I assume that, maybe, this is not org's fault but this kind of problem
>> only arises when using org-cite-insert so I was wondering if indeed
>> there is something I can tweak in org or oc- to get better completion
>> behaviour?  Or maybe something I can specify for vertico?
>
> org-cite-insert simply calls whatever is provided by the citation
> backend you use. Please tell us which oc-*.el backend is creating the
> problem.

Maybe I'm doing something wrong somewhere because whether I try basic,
biblatex, or csl, they appear the same in terms of selection interface.
Maybe it's something in vertico although I cannot see what it would be.

-- 
: Eric S Fraga, with org release_9.6-201-gb58fba in Emacs 30.0.50

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>> It also seems that the solution will need some mechanism (possibly on a
>> per time stamp basis) for the user to specify what should happen when
>> either the time zone has a daylight savings transition, when the
>> timezone rules change or when the user's 'default' time zone changes
>> because they have changed locations. 
>
> Could you please elaborate here?

I have some meetings scheduled in my org files which show up in the
agenda.

Meeting 1 is a reoccurring meeting which happens every 2 weeks. All of
the people in that meting are in the same timezone as I'm in. When we
transition into/out of daylight savings time, I don't want the timestamp
to change. THe meeting will remain at 3pm.

Meeting 2. This is also a reoccuring meeting. However, this meeting is
with people from a number of idfferent time zones. When my timezone
moves into or out of daylight savings time, I need the meeting time to
be updated - moved forward/back 1 hour.

Next week, I'm travelling to a different city for work and will be in a
different timezone. I need all my meetings to be adjusted except for
those I've already booked that are in the timezone I willl be in while
I'm away.

Finally, I have a few timestamps I use to track some projects and
progress on various tasks as well as reports showing actual and
estimated effort comparisons as well as managing billing/invoicing. The
actual timestamp times are less important than the calculation of
durations etc. When durations do cross daylight savings transition
points, it is critical that additonal hours are not accidentally
added/removed from the duration calculation. Mistakes here could result
in me loosing revenue or over charging clients.

So, for the first 2 I probably need to somehow flag/indicate that I do
or do not want the time adjusted as a result of a daylight savings
transition. For the 3rd group, I only want adjustments for timestamps
which are not in the 'current' (where I've travelled to) time zone. The
final one is really just about ensuring the transitions don't throw out
duration calculations accidentally.

Re: [PATCH 0/4] Structure editing when region is active

[Ihor Radchenko]

Samuel Wales  writes:

> oh i was just saying what does modern org e.g. main have for ensuring
> star structure integrity, if anything.  i have a git commit that has
> something similar to:
>
>   * one
>   ** two
>
> which seemed slightly relevant to the patch.

Sorry, but could you further elaborate? What kind of integrity and what
kind of structure editing do you have in mind here?

> do i misunderstand?  i set region, then set todo kw, which loops me
> manually through the region.  when the last todo kw is chosen, the
> active region disappears.i personally would find it annoying if
> transient mark mode stuck around.  fwiw.

Fair point. I guess the same holds for scheduling/setting deadlines/tags.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] ob-sql: Add support for Athena

[Daniel Kraus]

Tim Cross  writes:

> I think you run a high risk of running into GNU policy issues wrt
> licensing and free software support given this is a cleint for an AWS
> only database.

Is it because it's cloud only or because it's proprietary?
Because we already support Orcale, SAP Hana, MSSql and Vertico for example.

Cheers,
  Daniel

Re: [patch] improved: add TTL as defcustom to ox-icalendar

[Ihor Radchenko]

Detlef Steuer  writes:

> I tried to follow your advice to improve the patch accordingly.
> New version attached.

I have amended your patch fixing some of the spelling issues and
indentation. See the attached. Note that I used "time to live"
consistently instead of "time to life". The former is the right
abbreviation meaning, AFAIU
(https://www.cloudflare.com/learning/cdn/glossary/time-to-live-ttl/)

I also have a more general comment.

The patch only allows to the TTL globally for all the calendars.
However, it would make sense to specify TTL on per-file basis. WDYT?

>From 04174d53b84e32a2a73eb19ce9a1e12dff69d071 Mon Sep 17 00:00:00 2001
Message-Id: <04174d53b84e32a2a73eb19ce9a1e12dff69d071.1673948403.git.yanta...@posteo.net>
From: Detlef Steuer 
Date: Mon, 16 Jan 2023 23:27:33 +0100
Subject: [PATCH v2] lisp/ox-icalendar.el: Add customize option
 `org-icalendar-ttl'

* ox-icalendar.el: New option `org-icalendar-ttl' to add en entry
for the X-PUBLISHED-TTL option to ox-icalendar.  Default value is nil,
what means no such entry is exported.  If non nil the value must be
formated according to
https://icalendar.org/iCalendar-RFC-5545/3-8-2-5-duration.html.
---
 etc/ORG-NEWS | 15 +++
 lisp/ox-icalendar.el | 62 ++--
 2 files changed, 64 insertions(+), 13 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index c5d9bdf6e..fd44198ab 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -13,6 +13,21 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
 ** New options
+*** New custom setting ~org-icalendar-ttl~ for the ~ox-icalendar~ backend
+
+The option ~org-icalendar-ttl~ allows to advise a subscriber to the
+exported =.ics= file to reload after the given time interval.
+
+This is useful i.e. if a calendar server subscribes to your exported
+file and that is updated regularly.
+
+See IETF RFC 5545, Section 3.3.6 Duration and
+https://en.wikipedia.org/wiki/ICalendar#Other_component_types for
+details.
+
+Default for ~org-icalendar-ttl~ is ~nil~.  In that case the setting
+will not be used in the exported ICS file.
+
 *** New options for the "csl" citation export processor's LaTeX output
 
 The ~org-cite-csl-latex-label-separator~ and
diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index 81a77a770..081a0a516 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -297,6 +297,30 @@ (defcustom org-icalendar-date-time-format ":%Y%m%dT%H%M%S"
 	  (const :tag "Universal time" ":%Y%m%dT%H%M%SZ")
 	  (string :tag "Explicit format")))
 
+(defcustom org-icalendar-ttl nil
+  "Time to live for the exported calendar.
+
+Subscribing clients to the exported ics file can derive the time
+interval to read the file again from the server.  One example of such
+client is Nextcloud calendar, which respects the setting of
+X-PUBLISHED-TTL in ICS files.  Setting `org-icalendar-ttl' to \"PT1H\"
+would advise a server to reload the file every hour.
+
+See https://icalendar.org/iCalendar-RFC-5545/3-8-2-5-duration.html for
+a complete description of possible specifications of this option.  For
+example, \"PT1H\" stands for 1 hour and \"PT0H27M34S\" stands for 0
+hours, 27 minutes and 34 seconds.
+
+The default value is nil, which means no such option is set in the ICS
+file."
+  :group 'org-export-icalendar
+  :type '(choice
+  (const :tag "No refresh period" nil)
+  (const :tag "One day" "PT1D")
+  (const :tag "One week" "PT7D")
+  (string :tag "Other"))
+  :package-version '(Org . "9.7"))
+
 (defvar org-icalendar-after-save-hook nil
   "Hook run after an iCalendar file has been saved.
 This hook is run with the name of the file as argument.  A good
@@ -334,7 +358,8 @@ (org-export-define-derived-backend 'icalendar 'ascii
 (:icalendar-use-deadline nil nil org-icalendar-use-deadline)
 (:icalendar-use-scheduled nil nil org-icalendar-use-scheduled)
 (:icalendar-scheduled-summary-prefix nil nil org-icalendar-scheduled-summary-prefix)
-(:icalendar-deadline-summary-prefix nil nil org-icalendar-deadline-summary-prefix))
+(:icalendar-deadline-summary-prefix nil nil org-icalendar-deadline-summary-prefix)
+(:icalendar-ttl nil nil org-icalendar-ttl))
   :filters-alist
   '((:filter-headline . org-icalendar-clear-blank-lines))
   :menu-entry
@@ -872,26 +897,34 @@ (defun org-icalendar-template (contents info)
(or (org-string-nw-p org-icalendar-timezone) (format-time-string "%Z"))
;; Description.
(org-export-data (plist-get info :title) info)
+   ;; TTL
+   (plist-get info :icalendar-ttl)
contents))
 
-(defun org-icalendar--vcalendar (name owner tz description contents)
+(defun org-icalendar--vcalendar (name owner tz description ttl contents)
   "Create a VCALENDAR component.
-NAME, OWNER, TZ, DESCRIPTION and CONTENTS are all strings giving,
+NAME, OWNER, TZ, DESCRIPTION, TTL and CONTENTS are all strings giving,
 respectively, the name of the calendar, its owner, t

Re: [BUG] Code block contents do not match when seen from org file [9.6 (N/A @ /gnu/store/dqry6gr6wjaabd4v8cl40ab2ganrbn2l-emacs-org-9.6/share/emacs/site-lisp/org-9.6/)]

[Ihor Radchenko]

André A. Gomes  writes:

> Run the command org-edit-src-code, and notice that the contents look
> correct.  However, when you run the command org-edit-src-exit the org
> file shows:
>
> --8<---cut here---start->8---
> #+begin_src conf
> ,*.test
> #+end_src
> --8<---cut here---end--->8---
>
> Notice that a comma was magically insert at the beginning of the line!

The comma is just an escape symbol. It will not affect anything.
See https://orgmode.org/manual/Literal-Examples.html

Canceled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Tim Cross  writes:

> It also seems that the solution will need some mechanism (possibly on a
> per time stamp basis) for the user to specify what should happen when
> either the time zone has a daylight savings transition, when the
> timezone rules change or when the user's 'default' time zone changes
> because they have changed locations. 

Could you please elaborate here?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[FR] Allow BC years in timestamps (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Tom Gillespie  writes:

>> > As for years BC, <-0001-...> will be a breaking change. But I do not
>> > think that we need to really worry about this. Not unless we actually
>> > get feature request. What is the practical application?
>
> Using org as a format for writing about history and being able to
> reference dates in the past accurately and have the dates be
> first class entities that can be parsed and checked etc.
>
> The example in my head is a history professor who wants to
> write about e.g. the collapse of the Roman republic and not
> have to come up with their own time keeping system or force
> any one who wants to work with referenced dates to do a bunch
> of math to translate from a roman time system to a modern one.

This is an OK feature request. But it is orthogonal to time zones. Time
zones cannot help with BC years.

To support BC, we may need to change the timestamp format to, for
example, allow negative years. In addition, we might need to update
exporters to handle such scenarios.

Let's discuss BC/AC years in this thread, if there is further interest.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[BUG] Code block contents do not match when seen from org file [9.6 (N/A @ /gnu/store/dqry6gr6wjaabd4v8cl40ab2ganrbn2l-emacs-org-9.6/share/emacs/site-lisp/org-9.6/)]

[André A . Gomes]

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.


Steps to reproduce:

$ emacs -q

Write a file called test.org with the following content:

--8<---cut here---start->8---
#+begin_src conf
*.test
#+end_src
--8<---cut here---end--->8---

Run the command org-edit-src-code, and notice that the contents look
correct.  However, when you run the command org-edit-src-exit the org
file shows:

--8<---cut here---start->8---
#+begin_src conf
,*.test
#+end_src
--8<---cut here---end--->8---

Notice that a comma was magically insert at the beginning of the line!

Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, 
cairo version 1.16.0)
Package: Org mode version 9.6 (N/A @ 
/gnu/store/dqry6gr6wjaabd4v8cl40ab2ganrbn2l-emacs-org-9.6/share/emacs/site-lisp/org-9.6/)


-- 
André A. Gomes
"You cannot even find the ruins..."

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Tim Cross  writes:

> Daryl Manning  writes:
>
>> I think timezone you're in should be declared globally, surely?  And then 
>> defined in the timestamp?
>>
>
> Do you mean globally as in at the OS level or globally in org mode. If
> the latter, I disagree. The OS has this information and there is no need
> for org to repeat it (and possibly hav it wrong). I would go the other
> direction and say that the TZ should only be defined in an org file i it
> differs from the OS setting.

I am not sure here.

Consider the following situation:

1. Someone lives in Berlin most of the time and has all the business
   activity, including meetings in Berlin.
2. All the timestamps, including scheduled meetings are thus recorded in
   local time - there is not much point specifying that it is
   Europe/Berlin when system time is Europe/Berlin anyway.
3. The meetings are scattered across various Org files.   
4. The same person goes on holiday to a different time zone with no
   plans to do work meetings there. No adjustments to Org settings or
   files are being made.
5. There is a meeting in Berlin time being scheduled shortly after the
   holiday.   
6. Due to emergency (say, flight delay), it becomes impossible to come
   back to Berlin in time. The meeting must be attended online thus.
7. The local computer time zone is automatically set to the local time
   though. And combined with the timestamps being scheduled in "local"
   time (assuming that they will only matter in Berlin), it becomes a
   problem. Note that the computer time zone should be retained to make
   agenda display real meeting times in local time.
8. Solution to that problem is telling Org somehow that all the
   timestamps without time zone specifier must be considered in
   Europe/Berlin, not local time zone. At least, temporarily.
9. The easiest way Org can support such need would be global "default"
   time zone. It will be easier than a need to go through every possible
   Org file on computer and hand-setting the Europe/Berlin there.   

So, I am in favour of allowing Org-global "default" time zone in addition
to setting it on per-file, per-heading, and per-timestamp basis.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Robert Horn  writes:

> Those who wanted astronomical or other relationships would usually
> specify UTC or TAI.  They might use a fixed offset for UTC.  People who
> are into the demands of TAI (e.g., orbital mechanics) generally don't
> want to deal with the offsets or other issues that come up with UTC, so
> they wanted TAI.

Unless time zone database supports TAI, we cannot support it.
Does someone know if TAI is available somewhere in TZdb?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tim Cross]

Daryl Manning  writes:

> I'd argue that setting a specific datestamp  and time for DST would mean that 
> you expected to meet at that
> specific time and date as per DST. If the clocks changed you'd be out of luck 
> (that's where I'd argue you'd
> use a non-specified timezone for a meeting that re-occurs at 10:05 regardless 
> of say PDT or PST).
>
> But if this was an issue with a recurring meeting, then when the clocks 
> changed someone would be out an
> hour because they had specifically booked with DST in mind (note: this is 
> more useful than you think -
> being in non-DST countries and having scheduled meetings in DST based 
> countries, a lot of cal applications
> get this wrong when what I actually want is for that DST scheduled meeting to 
> now be reflected in my
> calendar on the fact they've switched to ST in their time zone - so shifted 
> an hour.). 
>
> But I feel this is something that would be for people who need to take 
> advantage of this. And, more often
> than not, is a recurring meeting issue when DST/ST changes occur. 
>

Yes, this is one of the areas where there are some subtle issues to work
through. With regards to just meetings, I see 3 common scenarios

1. Meeting wiht all participants in the same time zone. The time (lets
say 3pm) should not change when daylight savings comes in or goes
out. The meeting is always at 3pm even though that 3pm might be
different when considered against UTC time.

2. A meeting where some participants are in different time zones to the
org user. Here it isn't clear exactly what should happen when there is a
daylight savings transition in the org user's time zone. Should the org
user's meeting time change or should the participants in the other time
zones update their time for the meeting. On one hand, it makes sense
that the local org user change the meeting time for themselves either
forward/back an hour because it is their time zone which has
changed. However, if the meting has a majority of participants in the
same time zone as the org user, perhaps those in the other time zones
should adjust. Point is, it isn't obvious and there isn't a 'right
solution'. Both needs to be supported and probably need to have some way
to indicate which is the preferred behaviour. 

3. An org user who travels and is often in a different time zone from
their 'home' time zone. IN this scenario, they probably want their
meeting times to be adjusted to the local time zone they are in (unless
they are already recorded in that time zone). Note that this was a
specific example form a previous feature request for time zone support
in org time stamps.

This is just wiht respect to timestamps used for meetings. There are
other scenarios with other subtle issues. For example, someone already
mentioned a scenario where org is being used to record details about
experiments. In this situation, the amount of 'real' time passed between
two timestamps is possibly the most important factor. The fact daylight
savings time transitions have occured are likely irrelevant - just
important any calculations relating to duration are accurate and not
thrown out by one hour due to the wall clock moving forward/abck an
hour.

So far, it seems clear that the solution needs to be flexible and
support timestamps without time zone information, with fully qualified
time zone specification, with time zone abbreviated names and with time
zone offsets.

It also seems that the solution will need some mechanism (possibly on a
per time stamp basis) for the user to specify what should happen when
either the time zone has a daylight savings transition, when the
timezone rules change or when the user's 'default' time zone changes
because they have changed locations. 

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Robert Horn  writes:

>> Not really. Countries may change DST at any moment in future. Or decide
>> to switch calendars (consider countries near the day transition line).
>>
>> And "past local time, according to the DST rules in effect at the time"
>> is also an option that might be useful in certain scenarios.
>>
> The issue is clarity of the expected rules for the format.  If I
> schedule a meeting for 10:05 DST, but the rules change so that it is not
> DST at that location at that time in the future, what is the expected
> interpretation?  It could be:

Let me clarify. I do not think that we need to offer selecting DST/no
DST in the timestamp. Instead, we offer something like
<2028-12-11 18:00@Europe/Berlin>, specifying local time, including
possible DST transitions or any other political decisions the country
might make regarding the local time rules.

Or, if the preference is specifying time in such a way that it is
unaffected by the local time rules (for example, "+1 hours from now,
no matter what the DST/no DST or whatever rules will happen in the
middle"), one can use explicit UTC offsets like <2028-12-11 18:00@UTC+02>

Can you think of any situations when these two variants are not
sufficient? AFAIU, they should cover your example just fine.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-cite-insert only searches on truncate author list

[Ihor Radchenko]

"Fraga, Eric"  writes:

> I assume that, maybe, this is not org's fault but this kind of problem
> only arises when using org-cite-insert so I was wondering if indeed
> there is something I can tweak in org or oc- to get better completion
> behaviour?  Or maybe something I can specify for vertico?

org-cite-insert simply calls whatever is provided by the citation
backend you use. Please tell us which oc-*.el backend is creating the
problem.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-todo-keywords and task sequence

[Daniel Fleischer]

Daniel Fleischer [2023-01-17 Tue 10:10] wrote:

> Don't let the cyclical switching dictates the meaning, it's just an
> implementation detail, done for simplicity. Hope it helped.

Put another way, if you define A B | C D E

and the UI switching is A->B->C->D->E->A

it doesn't mean the B going into C makes sense or D going into E makes
sense, it's just how the UI is built. You give meaning to the states and
what states transitions are valid (in your world). Like many things, org
gives some structure to work with and we need to give the meaning.

-- 
Daniel Fleischer

Re: org-todo-keywords and task sequence

[Daniel Fleischer]

David Masterson  writes:

> I'm not sure I understand 'sequence' and 'type' in org-todo-keywords.

You're over thinking it. You can define various todo keywords and they
are divided into two groups that can be thought of as "ones that need
your attention" and "ones that don't need your attention" and they are
separated by a literal "|". Example: todo, in progress, on hold,
waiting, phonecall etc are of the 1st type. Done, canceled, postponed are of the
2nd type. In terms of "moving" between them, it's either cyclical or you
can jump to a specific word using shortcuts you define e.g.

#+TODO: TODO(t) | DONE(d)

Don't let the cyclical switching dictates the meaning, it's just an
implementation detail, done for simplicity. Hope it helped.

-- 
Daniel Fleischer