Re: Problem with let/cl-letf binding stuff with org-capture

[Bruno Barbier]

Arthur Miller  writes:

>> Bruno Barbier  writes:
>> If you really want to just get the piece of text, you might be able to
>> use the hook `org-capture-mode-hook' to replace the key binding to
>> 'C-c C-c' in the capture buffer, so that it calls your own function that
>> will take the string and call `org-capture-kill'.
>
> In this case you wouldn't like to replace the key binding, it would affect all
> org-capture buffers; the point is just to replace it when called in certain
> context (my-read-line). Let-binding the function in this context achieves
> exactly the same effect of C-c C-c beng bound to my function but without
> affecting all org-capture-buffers.

The hook `org-capture-mode-hook' will be run in your special
capture buffer. You can override the "C-c C-c" binding only there.

>
> Yes, I am aware of both hooks and advising; but again, with those I would 
> affect
> all uses of the function, and that would lead to checking some global state or
> variable to switch on, which is not optimal either. With let-binding we can 
> have
> different behaviour only in a certain context.

Even if I could let bind the function at the right time, I would avoid
that solution, as I can't garantuee that this global hack will not break
other parts of Emacs (other captures, output filters, threads, timers,
etc.).

>
> Anyway, thanks, I needed the reminder above.

You're welcome.

Bruno

[BUG] Smart quotes do not work in export when language is en-gb

[General discussions about Org-mode.]

Hello,

When exporting a document to LaTeX with smart quotes enabled, I found 
that this had been ignored (e.g. "hello" vs ``hello'' in the output). I 
had the document language set to en-gb, which it seems disables smart 
quotes, as there is no corresponding entry in org-export-smart-quotes 
alist. This is inconsistent with org-latex-language-alist, which 
correctly handles the en-gb case for babel and polyglossia.


I did find some old discussion on the ML about how the algorithm may 
have to be adjusted to accommodate “British style” quoting (single outer 
and double inner quotes) but failing a consensus on that (I am British 
but personally do not use that style), I think it at least makes sense 
to replicate the en(-us) behaviour.


As far as I can tell, this applies to en-au and en-nz too.

Corin Hoad

Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.36, cairo version 1.16.0)
Package: Org mode version 9.6 (9.6-??-bed47b4 @ 
/home/corin/.emacs.d/.local/straight/build-28.2/org/)

Multiple noweb-ref

[Théo Maxime Tyburn]

Hi,

I have several code blocks that I label using `:noweb-ref label`. I set
them for all blocks under a subtree by setting the org property
`header-args+` of the root of the subtree to `:noweb-ref label`.

Now with this approach, I can't accumulate `noweb-ref` like I could do for
tags. I would like all blocks under a subtree A to have the
reference "foo" and all the blocks under a subtree B of subtree A to
have the reference "bar", while also having the reference "foo".

What I would like to have, when I expand `<>` is to get all the blocks
under A, and when I expand `<>` I get all the blocks under B. For
now when I expand `<>` I only get the blocks under A that are not under B.

Is there a way to do this with the current features of org-babel?

Anyway I tried to hack my way trough it. It seems there are two things
to do :
1) Enable noweb-ref to contain multiple references.
2) Accumulate references when using header-args+ or use tags to set the
value of noweb-ref

I came up with a quick patch for 1):
modified   lisp/ob-core.el
@@ -2910,8 +2910,11 @@ block but are passed literally to the \"example-block\"."
(if (org-in-commented-heading-p)
(org-forward-heading-same-level nil t)
  (let* ((info (org-babel-get-src-block-info t))
-(ref (cdr (assq :noweb-ref (nth 2 info)
-   (push info (gethash ref cache))
+(refs (cdr (assq :noweb-ref (nth 2 info)
+(if refs
+(dolist (ref (s-split "+" refs))
+ (push info (gethash ref cache)))
+  (push info (gethash refs cache)))
 (funcall expand-references id cache)
 ;; Interpose PREFIX between every line.
 (mapconcat #'identity

With this I already get interesting results. A noweb-ref "foo+bar" gets
expanded by <> by and <>. For example if I define references like
this

#+BEGIN_SRC emacs-lisp :noweb-ref one
aaa
#+END_SRC
#+BEGIN_SRC emacs-lisp :noweb-ref two
bbb
#+END_SRC
#+BEGIN_SRC emacs-lisp :noweb-ref one+two
ababab
#+END_SRC

and tangle them like this

#+BEGIN_SRC emacs-lisp :tangle one.el :noweb yes
<>
#+END_SRC
#+BEGIN_SRC emacs-lisp :tangle two.el :noweb yes
<>
#+END_SRC

I get two files
one.el:
aaa
ababab

and two.el:
bbb
ababab

This is already nice!
Feedback on the code is of course very welcome. Not sure if using a plus
sign as a delimiter is clever. Also not sure if using `s-split` is a
good idea, what would be the builtin alternative?

For 2) I didn't check in detail how one could achieve this. I have the
impression it would be easier to use tags. One could define a
new variable `org-babel-set-noweb-refs-from-tags` that would be used in
`org-babel-get-src-block-info` to generate the value of noweb-ref we
would like to have depending on the tags of the headline of the
block. I'll try this soonish.

Best,

Théo

[BUG] Problems with :exports results for shell and plantuml code [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dzu/.emacs.d/straight/build/org-mode/)]

[Detlev Zundel]

Hi orgmode-list!

I currently have a problem while exporting org-babel blocks to html or
latex output.  Even though I explicitely specify ':exports result' for
the blocks, the exported document contains both the (syntax colored)
code block and the code.  I noticed this in a plantuml block that I use
to generate inline diagrams.  Exporting to PDF actually yields a PDF
looking like it contains only the results, but there are errors in the
'*Org PDF LaTeX Outupt*' buffer, saying that pygmentize misses a lexer
for plantuml.  Checking the generated LaTeX code indeed shows that the
code is exported to LaTeX, even though ':exports result' is passed as a
header argument.

Trying to narrow this down to a simple recipe to reproduce the buggy
behaviour, I encountered another behaviour I don't understand.  Using a
simple 'sh' code block also with ':exports result' works for 'date', but
not for 'pwd'.  Yes, I know that the one is a builtin and the other is
an external command, but I did not expect this to be of any relevance when
':exports result' is used.

So the question is - am I doing something wrong here, or what should I
do to only export the resulting output of the commands into the
document?

Please find the test case attached - if exported to html or pdf, it
shows the problematic output: 'pwd' is included as code, 'date' is not
and 'plantuml' renders errors in the LaTeX run.

Any hint greatly appreciated!

Best wishes
  Detlev

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.




Emacs  : GNU Emacs 30.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, 
cairo version 1.16.0)
 of 2023-01-31
Package: Org mode version 9.6-pre (release_9.5.5-995-g4b9aef @ 
/home/dzu/.emacs.d/straight/build/org-mode/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-html-table-caption-above nil
 org-ditaa-jar-path "/usr/share/ditaa/ditaa.jar"
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-babel-after-execute-hook '(org-redisplay-inline-images)
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 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-default-notes-file "~/nextcloud/org/notes.org"
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
 org-edit-src-content-indentation 0
 org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS 
WIDTH)"]
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
  org-cycle-optimize-window-after-visibility-change)
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 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
 #[0 "\301\211\207" [imenu-create-index-function 
org-imenu-get-tree] 2]
 flymake-languagetool-load)
 org-babel-load-languages '((ditaa . t) (dot . t) (emacs-lisp . t) (gnuplot . 
t) (lilypond . t)
(plantuml . t) (shell . t) (sparql . 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-latex-classes '(("beamer" "\\documentclass[presentation]{beamer}" 
("\\section{%s}" . "\\section*{%s}")
  ("\\subsection{%s}" . "\\subsection*{%s}")
  ("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
 ("article" "\\documentclass[11pt]{article}" 
("\\section{%s}" . "\\section*{%s}")
  ("\\subsection{%s}" . "\\subsection*{%s}")
  ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
  ("\\paragraph{%s}" . "\\paragraph*{%s}")
  ("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
 ("report" "\\documentclass[11pt]{report}" ("\\part{%s}" . 
"\\part*{%s}")
  ("\\chapter{%s}" . "\\chapter*{%s}") ("\\section{%s}" . 
"\\section*{%s}")
  ("\\subsection{%s}" . "\\subsection*{%s}")
  ("\\subsubsection{%s}" . 

Re: Problem with let/cl-letf binding stuff with org-capture

[Arthur Miller]

Bruno Barbier  writes:

> Arthur Miller  writes:
>
>> However I see that the binding for the org-capture-finalizer, in capture 
>> buffer,
>> is still the default 'org-capture--default-finalize' and not my lambda.
>>
>> I am really not an expert on emacs lisp; and I do understand that this is
>> somewhat "creative" use of org-capture (to put it nicely :-)), but I would 
>> like
>> to understand what is going on here.
>>
>> I don't understand why let-binding here does not work?
>
> Your bindings probably work. But, as the function `org-capture'
> just *starts* the capture process, they are removed when exiting the
> 'let', before you even begin editing your capture.

Yes of course :) I am quite aware that org-capture just setups the buffer, and
that org-capture-finalize finnishes by writing stuff to files etc, and yet I
have tottally forgott it when writing this. This for opening my eyes.

> I'm not sure I understand your use case:  if you have a piece
> of org text, you can put it anywhere (possibly using refiling).

it is just a fun test. I wouldn't do that myself normally and I have no idea why
the blog author needs it either. If I wanted to input multiline
text into some dokument I would open dokument itself. But this was just a
thought I am testing; you can read in the link I posted in the first mail.

> If you really want to just get the piece of text, you might be able to
> use the hook `org-capture-mode-hook' to replace the key binding to
> 'C-c C-c' in the capture buffer, so that it calls your own function that
> will take the string and call `org-capture-kill'.

In this case you wouldn't like to replace the key binding, it would affect all
org-capture buffers; the point is just to replace it when called in certain
context (my-read-line). Let-binding the function in this context achieves
exactly the same effect of C-c C-c beng bound to my function but without
affecting all org-capture-buffers.

>You can usually use hooks (like `org-capture-mode-hook'):
>   (info "(elisp) Hooks")
>
> or, if it's not possible, you can advise the functions:
>
>   (info "(elisp) Advising Functions")

Yes, I am aware of both hooks and advising; but again, with those I would affect
all uses of the function, and that would lead to checking some global state or
variable to switch on, which is not optimal either. With let-binding we can have
different behaviour only in a certain context.

Anyway, thanks, I needed the reminder above.

cheers
/arthur

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Max Nikulin]

On 10/02/2023 10:29, Jean Louis wrote:

2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed
UTC"


I do not see any reason why obviously invalid timestamp draws so much 
attention.


Resolution may be rather concise: behavior is *undefined* since field 
values are mutually inconsistent. Perhaps implementation may prefer to 
treat it as 2030-02-09T12:00:00-0800 discarding UTC as time zone 
specifier. `org-lint' should issue a warning requesting a user action.


Could you explain what is wrong with the following (without timezone)?

2030-02-09 12:00 -0800

I consider it as an unambiguous equivalent of 2030-02-09T20:00:00Z that 
is a UTC timestamp. The format with explicit offset may be convenient 
for a person living in an area that *likely* will have -08:00 offset and 
who would like to watch some astronomical event such as lunar eclipse 
and who had a plan to connect to some telescope on the opposite side of 
the globe. Event time will not change if local time changed. Both 
variants 2030-02-09T12:00:00-0800 and 2030-02-09T20:00:00Z may be 
presented as "2030-02-09 12:00" to users. If timezone offset is changed 
both variants will converted to "13:00" or "11:00" depending on sign of 
change. So the format with offset is human friendly because it gives a 
hint concerning *probable* value of local time still remaining *precise* 
in respect to UTC.


I find the following as acceptable, but confusing to some degree:

2030-02-09 12:00 -08

just because "-08" is currently used in TZ database as time zone 
abbreviation (a string similar to "BST"), not as offset that is 
represented in wide spread formats as -0800 or -08:00. Unfortunately the 
latter causes ambiguity in the context of Org.

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

[Alan Tyree]

3 days, 2 hours, 25 minutes, 36 seconds

2.35% of cache searches hashed, 78.11% non-hashable.

Org mode version 9.6.1 ( @ /home/alant/.emacs.d/elpa/org-9.6.1/)



On Fri, 10 Feb 2023 at 22:18, Fraga, Eric  wrote:

> 10.48% of cache searches hashed, 5.66% non-hashable.
> 2 days, 17 hours, 12 minutes, 29 seconds
>
> --
> : Eric S Fraga, with org release_9.6-201-gb58fba in Emacs 30.0.50
>


-- 
Alan L Tyreehttp://www2.austlii.edu.au/~alan

Re: [PATCH] Async evaluation in ob-shell

[Matt]

  On Thu, 09 Feb 2023 06:23:42 -0500  Ihor Radchenko  wrote --- 
 > Could you please elaborate? What was the problem with
 > `buffer-substring'? I am asking because one of the previous versions of
 > `org-babel-comint-wait-for-output' relied upon 'face text property. See
 > a35d16368.

The problem is I got mixed up about the printed string representation and 
thought having properties changed how functions operated on the string.  The 
02-ob-shell-async-non-file.patch works fine with `buffer-substring'.  No need 
for the other patch.

It seems to me like 02-ob-shell-async-non-file.patch is all that's needed for 
basic async in ob-shell.  I'm able to run long processes like `guix pull' and 
`guix package -u' calls without issue and the results look like I expect.  
Similarly for running a web server, such as `python3 -m http.server' and 
killing it.  

Unless there's something you or others think needs to be done, I can get it 
committed (and try to write a test or two for it).

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

[Kévin Le Gouguec]

Kévin Le Gouguec  writes:

> Here are the stats for today:

And today's session:

> org-element-cache-hash-show-statistics:
>> 19.32% of cache searches hashed, 11.88% non-hashable.

23.65% of cache searches hashed, 17.88% non-hashable.

> emacs-uptime:
>> 10 hours, 50 minutes, 12 seconds

13 hours, 5 minutes, 31 seconds

> emacs-version:
>> GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
>> cairo version 1.16.0) of 2023-02-06
>
> emacs-repository-version:
>> 907fd1f7ff402f9d226ebb3b891ea5b54fac1d1c
>
> org-version:
>> Org mode version 9.6.1 (release_9.6.1-23-gc45a05 @
>> /usr/local/share/emacs/30.0.50/lisp/org/)
>
> FWIW, this was with 5 Org files open, clocking in and out of 18 headings
> out of a little under 2000 headings.

7 Org files open, clocking in and out of 19 headings.

Re: Problem with let/cl-letf binding stuff with org-capture

[Bruno Barbier]

Arthur Miller  writes:

> However I see that the binding for the org-capture-finalizer, in capture 
> buffer,
> is still the default 'org-capture--default-finalize' and not my lambda.
>
> I am really not an expert on emacs lisp; and I do understand that this is
> somewhat "creative" use of org-capture (to put it nicely :-)), but I would 
> like
> to understand what is going on here.
>
> I don't understand why let-binding here does not work?

Your bindings probably work. But, as the function `org-capture'
just *starts* the capture process, they are removed when exiting the
'let', before you even begin editing your capture.

I'm not sure I understand your use case:  if you have a piece
of org text, you can put it anywhere (possibly using refiling).

If you really want to just get the piece of text, you might be able to
use the hook `org-capture-mode-hook' to replace the key binding to
'C-c C-c' in the capture buffer, so that it calls your own function that
will take the string and call `org-capture-kill'.

Note that they are safer way to modify Emacs behavior than overwriting
the functions. You can usually use hooks (like `org-capture-mode-hook'):

  (info "(elisp) Hooks")

or, if it's not possible, you can advise the functions:

  (info "(elisp) Advising Functions")


Bruno

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

[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

[PATCH] Introduce "export features"

[Timothy]

Hello everyone,

I’m thrilled to finally be presenting a feature that I’ve been incubating for a
while now that I call “export features”. This work is based on the observation
that often we include content in export templates that is only relevant in
particular situations.

This leaves one having to choose between a “kitchen sink” approach where
everything that could be used is all included, or a “manual inclusion” approach
where the template is minimal and the relevant setup code must be manually
included each time.

I think it’s fair to say neither situation is ideal, and I’ve become
dissatisfied enough that I’ve sunk some time into working on a better way of
handling this. In this patch set it’s just being applied to LaTeX preambles, but
this is just a start — there are plans to apply this more broadly.

“export features” allow for the specification of qualities of the org buffer
being exported that imply certain “features”, and how those features may be
implemented in a particular export.

This is done by augmenting the backend struct with two new fields:
`feature-conditions' and `feature-implementations'.

The feature conditions are resolved during the annotation of `info', in the Org
buffer after `#+include' expansion and the removal of comments.

The feature implementations are expanded by the backend itself, in the case of
`ox-latex' this currently means during preamble construction.

With this change, `ox-latex' produces more minimal /and/ more capable exports 
out of
the box. The number of default packages has been ~halved, but OOTB capability
has been improved by dynamically adding them to the preamble when needed, and
now `\usepackage{svg}' is automatically added when exporting a buffer that
includes SVG images.

This also opens new frontiers for user customisation. For instance, adding
particular beamer customisations when using the `metropolis' beamer theme with 
the
following snippet:

┌
│ (org-export-update-features 'beamer
│   (beamer-metropolis
│:condition (string-match-p \"metropolis$\" (plist-get info :beamer-theme))
│:snippet my-org-beamer-metropolis-tweaks
│:order 3))
└


Hopefully this gives you an idea of the feature. See the patches attached for
the implementation (and some hopefully informative code comments). Feel free to
toss any you may have question my way :)

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .
>From 5575a0f18277ef34f4003c1bccf650e4237e6048 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 25 Jul 2022 23:37:13 +0800
Subject: [PATCH 1/6] ox: Introduce conditional/generated preamble

* lisp/ox.el (org-export-detect-features, org-export-expand-features,
org-export-generate-features-preamble): New functions for detecting
features and generating content based on them.
* lisp/ox.el (org-export-conditional-features): Customisation for
feature detection.
* lisp/ox.el (org-export-as): Add detected to features to info in the
slot :features.
---
 lisp/ox.el | 217 +
 1 file changed, 217 insertions(+)

diff --git a/lisp/ox.el b/lisp/ox.el
index 0a48e850a..1a75ed28d 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2030,6 +2030,221 @@ (defun org-export-expand (blob contents  with-affiliated)
 	(funcall (intern (format "org-element-%s-interpreter" type))
 		 blob contents
 
+
+;;; Conditional/Generated Preamble
+;;
+;; Many formats have some version of a preamble, whether it be HTML's
+;; ... or the content before LaTeX's \begin{document}.
+;; Depending on the particular features in the Org document being
+;; exported, different setup snippets will be needed.  There's the
+;; "everything and the kitchen sink" approach of adding absolutely
+;; everything that might be needed, and the post-translation editing
+;; with filters approach, but neither really solve this problem nicely.
+;;
+;; The conditional/generated preamble defines mechanisms of detecting
+;; which "features" are used in a document, handles interactions
+;; between features, and provides/generates preamble content to
+;; support the features.
+
+(defcustom org-export-conditional-features
+  `(("^[ \t]*#\\+print_bibliography:" . bibliography)
+(,(lambda (info)
+   (org-element-map (plist-get info :parse-tree)
+   'link
+ (lambda (link)
+   (and (member (org-element-property :type link)
+'("http" "https" "ftp" "file"))
+(file-name-extension (org-element-property :path link))
+(string= (downcase (file-name-extension
+(org-element-property :path link)))
+ "svg")))
+ info t))
+ . svg)
+(,(lambda (info)
+   (org-element-map (plist-get info :parse-tree)
+   'link
+ (lambda 

Re: Problem with let/cl-letf binding stuff with org-capture

[Arthur Miller]

Ruijie Yu  writes:

> Hi Arthur,
>
> Please excuse my brevity and semi-random line of thought, as I’m replying on 
> mobile right now.  See below. 
>
>> On Feb 10, 2023, at 23:11, Arthur Miller  wrote:
>> 
>> 
>> Based on a Reddit thread:
>> 
>> https://www.reddit.com/r/emacs/comments/10xhvd8/a_little_readstring_utility_using_an_org_mode/j7xziao/?context=3
>> 
>> I did a small experiment to see if I can re-use org-capture, to just capture 
>> a
>> string from a buffer, without actually writing to any file.
>> 
>> My plan was to just let-bind org-capture-finalize with cl-letf:
>> 
>> #+begin_src emacs-lisp
>> (defun my-read-string ()
>> (cl-letf (((symbol-function 'org-capture-finalize) ;; C-c C-c
>>   (lambda ( _) (interactive "P") (buffer-string)))
>>  ((symbol-function 'org-kill-note-or-show-branches) #'kill-buffer)) 
>> ;; C-c C-k
>>  (let ((org-capture-templates '(("s" "string" plain (function ignore)
>>(org-capture nil "s"
>> #+end_src
>
> Based on my somewhat-limited experience with CL (and elisp), I have never seen
> this particular type of letf structure.  What I am used to seeing and writing 
> is
> the following:

It uses "place" or "field" to set the symbol binding, as in setf or incf.

You can read more on SX:

https://stackoverflow.com/questions/39550578/in-emacs-what-is-the-difference-between-cl-flet-and-cl-letf

> (cl-letf ((f (x) (1+ x))
>(1+ (f 2)))
> ; => 4
>
> In particular, IIUC, I don’t think you would need symbol-function here.  Maybe
> you can learn more from the docstring of cl-letf than me trying to drain my
> memory on this topic without reference.
>
> Also, in the code snippet you provided, what *should* org-capture-finalize 
> be?  A function that can be called like this:
>
>(org-capture-finalize arg1 arg2)
>
> ? Or a variable containing a function (reference) that can be called like 
> this:
>
>(funcall org-capture-finalize arg1 arg2)
>
> ?  In the former case you might be able to use cl-letf, and in the latter 
> case you should use let with a lambda value. 
>
>> Unfortunately, that does not work. Regardless of binding, and if I used 
>> cl-letf
>> or cl-flet or cl-labels, or old let, or something brewed on the internet, the
>> binding org-capture see for org-capture-finalize, is the original one from
>> org-capture.el.
>> 
>> My second experiment was to abstract the finalize function into a funcallable
>> fariable in org-capture.el (I have patched org-capture.el with this):
>> 
>> #+begin_src emacs-lisp
>> (defvar org-capture-finalizer #'org-capture--default-finalize)
>> 
>> (defun org-capture-finalize ( stay-with-capture)
>> "Finalize the capture process.
>> With prefix argument STAY-WITH-CAPTURE, jump to the location of the
>> captured item after finalizing."
>> (interactive "P")
>> (funcall org-capture-finalizer stay-with-capture))
>> 
>> 
>> (defun org-capture--default-finalize ( stay-with-capture)
>> "Default implementation for org-capture finalizer function."
>> 
>> ;; this is the original org-capture-finalize just renamed to 
>> "default-finalize"
>> )
>> #+end_src
>> 
>> So I could then have something like this (never mind C-c C-k function being
>> removed):
>> 
>> #+begin_src emacs-lisp
>> (defun my-read-string ()
>> (let ((org-capture-templates '(("s" "string" plain (function ignore
>>  (org-capture-finalizer
>>   (lambda ( _) (interactive "P") (buffer-string
>>  (org-capture nil "s")))
>> #+end_src
>> 
>> However I see that the binding for the org-capture-finalizer, in capture 
>> buffer,
>> is still the default 'org-capture--default-finalize' and not my lambda.
>
> I guess this answers part of my question in my previous paragraph.  Is
> org-capture-finalizer defined via defvar?  If so, does it help if you put an
> empty defvar before the let binding?  If not, maybe someone actually using 
> Emacs
> right now can be of more help here.

These were two different examples; one that let-binds the function
'org-caputre-finalize', via cl-letf and the latter one that was completely
different in which I have defvared a symbol so I can let-bind it as a variable.

>   If not, maybe someone actually using 
> Emacs
> right now can be of more help here.

Don't worry; thanks for the help anyway!

/a

Re: [BUG] Problems with ':exports result' for shell and plantuml blocks [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dzu/.emacs.d/straight/build/org-mode/)]

[Detlev Zundel]

Hi list,

found the problem.  Misspelled ':export results' as ':exports result'.
Of course it does not throw an error, but simply does not work.  Fixing
this, fixes all of my problems...  *shame on me*

Thanks
  Detlev

Re: Problem with let/cl-letf binding stuff with org-capture

[General discussions about Org-mode.]

Hi Arthur,

Please excuse my brevity and semi-random line of thought, as I’m replying on 
mobile right now.  See below. 

> On Feb 10, 2023, at 23:11, Arthur Miller  wrote:
> 
> 
> Based on a Reddit thread:
> 
> https://www.reddit.com/r/emacs/comments/10xhvd8/a_little_readstring_utility_using_an_org_mode/j7xziao/?context=3
> 
> I did a small experiment to see if I can re-use org-capture, to just capture a
> string from a buffer, without actually writing to any file.
> 
> My plan was to just let-bind org-capture-finalize with cl-letf:
> 
> #+begin_src emacs-lisp
> (defun my-read-string ()
> (cl-letf (((symbol-function 'org-capture-finalize) ;; C-c C-c
>   (lambda ( _) (interactive "P") (buffer-string)))
>  ((symbol-function 'org-kill-note-or-show-branches) #'kill-buffer)) 
> ;; C-c C-k
>  (let ((org-capture-templates '(("s" "string" plain (function ignore)
>(org-capture nil "s"
> #+end_src

Based on my somewhat-limited experience with CL (and elisp), I have never seen 
this particular type of letf structure.  What I am used to seeing and writing 
is the following:

(cl-letf ((f (x) (1+ x))
   (1+ (f 2)))
; => 4

In particular, IIUC, I don’t think you would need symbol-function here.  Maybe 
you can learn more from the docstring of cl-letf than me trying to drain my 
memory on this topic without reference. 

Also, in the code snippet you provided, what *should* org-capture-finalize be?  
A function that can be called like this:

   (org-capture-finalize arg1 arg2)

? Or a variable containing a function (reference) that can be called like this:

   (funcall org-capture-finalize arg1 arg2)

?  In the former case you might be able to use cl-letf, and in the latter case 
you should use let with a lambda value. 

> Unfortunately, that does not work. Regardless of binding, and if I used 
> cl-letf
> or cl-flet or cl-labels, or old let, or something brewed on the internet, the
> binding org-capture see for org-capture-finalize, is the original one from
> org-capture.el.
> 
> My second experiment was to abstract the finalize function into a funcallable
> fariable in org-capture.el (I have patched org-capture.el with this):
> 
> #+begin_src emacs-lisp
> (defvar org-capture-finalizer #'org-capture--default-finalize)
> 
> (defun org-capture-finalize ( stay-with-capture)
> "Finalize the capture process.
> With prefix argument STAY-WITH-CAPTURE, jump to the location of the
> captured item after finalizing."
> (interactive "P")
> (funcall org-capture-finalizer stay-with-capture))
> 
> 
> (defun org-capture--default-finalize ( stay-with-capture)
> "Default implementation for org-capture finalizer function."
> 
> ;; this is the original org-capture-finalize just renamed to 
> "default-finalize"
> )
> #+end_src
> 
> So I could then have something like this (never mind C-c C-k function being
> removed):
> 
> #+begin_src emacs-lisp
> (defun my-read-string ()
> (let ((org-capture-templates '(("s" "string" plain (function ignore
>  (org-capture-finalizer
>   (lambda ( _) (interactive "P") (buffer-string
>  (org-capture nil "s")))
> #+end_src
> 
> However I see that the binding for the org-capture-finalizer, in capture 
> buffer,
> is still the default 'org-capture--default-finalize' and not my lambda.

I guess this answers part of my question in my previous paragraph.  Is 
org-capture-finalizer defined via defvar?  If so, does it help if you put an 
empty defvar before the let binding?  If not, maybe someone actually using 
Emacs right now can be of more help here. 

> I am really not an expert on emacs lisp; and I do understand that this is
> somewhat "creative" use of org-capture (to put it nicely :-)), but I would 
> like
> to understand what is going on here.
> 
> I don't understand why let-binding here does not work? If I take 
> (symbol-functon
> 'org-capture) I see it is a closure. I am not sure if it has something with 
> the
> problem to do? I have tested to disable lexical binding, re-eval things, but
> the let-binding seems rock stable :). Nothing makes org-capture to reconsider
> using my local let-binding.
> 
> I would really like to understand this, so please if someone can explain it, I
> will appreciate to hear.
> 
> Thanks in advance
> /arthur

Best,


RY

Problem with let/cl-letf binding stuff with org-capture

[Arthur Miller]

Based on a Reddit thread:

https://www.reddit.com/r/emacs/comments/10xhvd8/a_little_readstring_utility_using_an_org_mode/j7xziao/?context=3

I did a small experiment to see if I can re-use org-capture, to just capture a
string from a buffer, without actually writing to any file.

My plan was to just let-bind org-capture-finalize with cl-letf:

#+begin_src emacs-lisp
(defun my-read-string ()
  (cl-letf (((symbol-function 'org-capture-finalize) ;; C-c C-c
 (lambda ( _) (interactive "P") (buffer-string)))
((symbol-function 'org-kill-note-or-show-branches) #'kill-buffer)) 
;; C-c C-k
(let ((org-capture-templates '(("s" "string" plain (function ignore)
  (org-capture nil "s"
#+end_src

Unfortunately, that does not work. Regardless of binding, and if I used cl-letf
or cl-flet or cl-labels, or old let, or something brewed on the internet, the
binding org-capture see for org-capture-finalize, is the original one from
org-capture.el.

My second experiment was to abstract the finalize function into a funcallable
fariable in org-capture.el (I have patched org-capture.el with this):

#+begin_src emacs-lisp
(defvar org-capture-finalizer #'org-capture--default-finalize)

(defun org-capture-finalize ( stay-with-capture)
  "Finalize the capture process.
With prefix argument STAY-WITH-CAPTURE, jump to the location of the
captured item after finalizing."
  (interactive "P")
  (funcall org-capture-finalizer stay-with-capture))


(defun org-capture--default-finalize ( stay-with-capture)
  "Default implementation for org-capture finalizer function."

;; this is the original org-capture-finalize just renamed to "default-finalize"
)
#+end_src

So I could then have something like this (never mind C-c C-k function being
removed):

#+begin_src emacs-lisp
(defun my-read-string ()
  (let ((org-capture-templates '(("s" "string" plain (function ignore
(org-capture-finalizer
 (lambda ( _) (interactive "P") (buffer-string
(org-capture nil "s")))
#+end_src

However I see that the binding for the org-capture-finalizer, in capture buffer,
is still the default 'org-capture--default-finalize' and not my lambda.

I am really not an expert on emacs lisp; and I do understand that this is
somewhat "creative" use of org-capture (to put it nicely :-)), but I would like
to understand what is going on here.

I don't understand why let-binding here does not work? If I take (symbol-functon
'org-capture) I see it is a closure. I am not sure if it has something with the
problem to do? I have tested to disable lexical binding, re-eval things, but
the let-binding seems rock stable :). Nothing makes org-capture to reconsider
using my local let-binding.

I would really like to understand this, so please if someone can explain it, I
will appreciate to hear.

Thanks in advance
/arthur

[BUG] Problems with ':exports result' for shell and plantuml blocks [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dzu/.emacs.d/straight/build/org-mode/)]

[Detlev Zundel]

Hi list,

I am having problems with exporting code blocks to pdf or html
documents.  I noticed the problem with a PlantUML block that I use for
inline diagrams.  As I only want the diagram in the output, I use
':exports result' in the header of the block.  My main target is PDF
output and the PDF looks fine, although I get errors in the '*Org PDF
LaTeX Output*' buffer: 'Error: no lexer for alias 'plantuml' found'.

Looking at the intermediate LaTeX buffer, the code block indeed is also
there, but because of the error does not produce any output in the PDF.

So I tried to shrink the problem down to reproduce the error and there I
found another thing that I do not understand.  To proove that ':exports
result' works, I added two one line shell calls, but to my amazement,
calling 'pwd' also exports the code, but not calling 'date'.  To me
things look identical, so I have no idea why this would happen.

The problems also show when exporting to html, so they seem to be
somewhere in the inner workings of org mode.

Please find attached a short test case showing the problem.  It requires
PlantUML to generate the diagram, but the shell blocks also show a
problem that should be easy to reproduce.

Am I doing something terribly stupid?  How can I make things work, like
I would expect them to?  Any hint greatly appreciated!

Thanks
  Detlev


8<--
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.


Emacs  : GNU Emacs 30.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, 
cairo version 1.16.0)
 of 2023-01-31
Package: Org mode version 9.6-pre (release_9.5.5-995-g4b9aef @ 
/home/dzu/.emacs.d/straight/build/org-mode/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-html-table-caption-above nil
 org-ditaa-jar-path "/usr/share/ditaa/ditaa.jar"
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-babel-after-execute-hook '(org-redisplay-inline-images)
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 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-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
 org-edit-src-content-indentation 0
 org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS 
WIDTH)"]
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
  org-cycle-optimize-window-after-visibility-change)
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 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
 #[0 "\301\211\207" [imenu-create-index-function 
org-imenu-get-tree] 2]
 flymake-languagetool-load)
 org-babel-load-languages '((ditaa . t) (dot . t) (emacs-lisp . t) (gnuplot . 
t) (lilypond . t)
(plantuml . t) (shell . t) (sparql . 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-latex-classes '(("beamer" "\\documentclass[presentation]{beamer}" 
("\\section{%s}" . "\\section*{%s}")
  ("\\subsection{%s}" . "\\subsection*{%s}")
  ("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
 ("article" "\\documentclass[11pt]{article}" 
("\\section{%s}" . "\\section*{%s}")
  ("\\subsection{%s}" . "\\subsection*{%s}")
  ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
  ("\\paragraph{%s}" . "\\paragraph*{%s}")
  ("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
 ("report" "\\documentclass[11pt]{report}" ("\\part{%s}" . 
"\\part*{%s}")
  ("\\chapter{%s}" . "\\chapter*{%s}") ("\\section{%s}" . 
"\\section*{%s}")
  ("\\subsection{%s}" . "\\subsection*{%s}")
  ("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
 ("book" "\\documentclass[11pt]{book}" ("\\part{%s}" . 
"\\part*{%s}")

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

[Detlev Zundel]

oops, C-c C-c in message mode sends the message, *smirk*

Ihor Radchenko  writes:

  M-x org-element-cache-hash-show-statistics 
  M-x emacs-uptime 

#+begin_src elisp
(org-element-cache-hash-show-statistics)
#+end_src

#+RESULTS:
: 6.60% of cache searches hashed, 34.35% non-hashable.

#+begin_src elisp
(emacs-uptime)
#+end_src

#+RESULTS:
: 9 days, 22 hours, 28 minutes, 16 seconds

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

[Detlev Zundel]

Ihor Radchenko  writes:

>  M-x org-element-cache-hash-show-statistics 
>  M-x emacs-uptime 

#+begin_src elisp
org-element-cache-hash-show-statistics
#+end_src


-- 
Restrict Digital Restrictions Management:
If you can't copy it - don't buy it

Re: [FR] Allow emojis in tags (was: emojis in tags?)

[Robert Nikander]

> On Feb 10, 2023, at 6:23 AM, Ihor Radchenko  wrote:
> 
> Robert Nikander  writes:
> 
>> […]
> 
> It is not hard to do, but I am not sure about consequences of such a
> change in Org syntax.
> 
> I see no obvious downsides though.

I noticed that other potentially useful symbols do not work. For example, a 
string with an arrow symbol (a→b) does not parse as a tag.

I’d vote for also enabling things like the arrows, math symbols, and 
pictographs.

I sometimes don’t like how Emojis alter the line height, because to me it 
doesn’t look as nice when lines have different height. But if that can’t be 
controlled, and people don’t like it, then they are free to simply not use 
emojis. 

Rob

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]

Max Nikulin  writes:

> another option is to use --always
>
> git describe --match release\* --abbrev=6 --always HEAD
> 52f29d

This is indeed more reliable.
Applied, onto main. With your version instead of git log.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6d37d2a8e

> and some make code that prepends it with release_$(ORGVERSION)- if it 
> has not release prefix.

This is not needed. ORGVERSION as defined in Org .el files will be
available. The patch only deals the git tags, when they are missing.

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

Re: [PATCH] ol.el: Recommend `browse-url' to `:follow' links

[Max Nikulin]

On 10/02/2023 18:13, Ihor Radchenko wrote:

Max Nikulin writes:


I think, it might be helpful to mention the `browse-url' package in the
docs for the :follow property of `org-link-parameters'. Writing code to
launch an external application may be tricky, so it is better to
delegate the task to existing utilities.


Maybe better add this to "A.3 Adding Hyperlink Types" section of the manual?


If you you believe that the (info "(org) Adding Hyperlink Types") 
section should be expanded then a complete example is necessary, some 
ideas may be picked from


https://orgmode.org/worg/org-faq.html#mailto-links
https://orgmode.org/worg/org-faq.html#mid-url-handler

While the manual section and the `org-link-parameters' docstring as the 
reference may be cross-linked, some note on `browse-url' still may be 
helpful in the latter.

Re: [PATCH] remove unused code in ob-octave.el

[Ihor Radchenko]

Leo Butler  writes:

> What is the point of ob-octave-prep-session:octave or its brother,
> ob-octave-prep-session:matlab?
>
> These two functions are unused in the existing code.

They are used.
ob-core.el library prescribed certain function names to be defined in
order to declare new babel backend:
- org-babel-default-header-args:lang
- org-babel-execute:lang
- org-babel-expand-body:lang
- org-babel-variable-assignments:lang
- org-babel-header-args:lang
- org-babel-load-session:lang
- org-babel-lang-initiate-session
- org-babel-prep-session:lang

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

Re: [org-promote-subtree + undo] adds one star

[Ihor Radchenko]

Ihor Radchenko  writes:

> alain.coch...@unistra.fr writes:
>
>> I fear that, even if the emacs people fix the problem, it still won't
>> work with, say, emacs 27 or 28.
>>
>> Oh, well...
>
> If they fix this, we will at least have a clue what is causing it.

The bug has been fixed for Emacs 29.
Earlier Emacs will still suffer.
I committed a workaround onto bugfix.
Fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=af1bb1b06

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

[FR] Allow emojis in tags (was: emojis in tags?)

[Ihor Radchenko]

Robert Nikander  writes:

> Does anyone else think it might be nice to allow emojis in tags? I used to 
> use OmniFocus before I got into org-mode. I had some tags that were certain 
> symbols that had meaning to me. 

It is not hard to do, but I am not sure about consequences of such a
change in Org syntax.

I see no obvious downsides though.

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

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

[Fraga, Eric]

10.48% of cache searches hashed, 5.66% non-hashable.
2 days, 17 hours, 12 minutes, 29 seconds

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

Re: [PATCH] ol.el: Recommend `browse-url' to `:follow' links

[Ihor Radchenko]

Max Nikulin  writes:

> I think, it might be helpful to mention the `browse-url' package in the 
> docs for the :follow property of `org-link-parameters'. Writing code to 
> launch an external application may be tricky, so it is better to 
> delegate the task to existing utilities.

Maybe better add this to "A.3 Adding Hyperlink Types" section of the manual?

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

Re: [BUG] list.orgmode.org managed to parse a message in future: 2023-10-29 [9.6.1 (release_9.6.1-223-gc8d20d @ /home/yantar92/.emacs.d/straight/build/org/)]

[Greg Minshall]

Jean Louis,

> In my opinion central computer that manages mailing lists should
> recogniz if time of users is far in future and handle it
> appropriately.

> Maybe re-writing time with explanation in e-mail header would be more
> appropriate.

maybe something like that.  though, this seems more an issue for
"mailing list management" mailing lists than for org-mode itself.
(maybe send them such a message, from the future? :)

cheers, Greg

Re: new org mode, changed folding behavior could be improved / more consistent

[Ihor Radchenko]

[ Adding Org ML back to CC ]

Laurenz Wiskott  writes:

>> What about only enabling this feature when you pass "0" prefix argument:
>> C-u 0 S- ?
>
> I would like to avoid the extra key strokes, and I don't know why that should 
> be needed.
> What could this first star-line be used for except to indicate a specific 
> default
> unfolding depth?  So, I don't think anybody would use it without this 
> intention, and
> therefore there is no need to introduce these extra key strokes.

People do all kinds of weird things including deeply nested entry on top.
I did not mean toggling, I did mean only having the proposed behavior
only with C-u 0 S- key sequence.

In any case, I now reviewed the manual and I think that you can use
alternative approach to set which headings are visible in overview
folding state.

Try

#+STARTUP: show3levels
* 1
  Text 1
** 2
   Text 2
*** 3
Text 3
 4
 Text 4

and then C-u C-u 

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

Re: [BUG] CUSTOM_id ignored on blocks by ox-beamer

[Ihor Radchenko]

Alan Schmitt  writes:

> Here is an updated patch.

Thanks!
Applied, onto main. I changed quoting style of some terms in ORG-NEWS
and moved the new item to the top as we usually do for new items (last
comes first).
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=666a61bcc

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

> If you start adding in Org "fixed" time with UTC offset, that is a new
> type of timestamp, as it is not common in world.

It is how ISO8601 defines offsets.

> Here is suggestion:
> ---
>
> 1. Convert local time timestamp to UTC
> 2. Add 10024 hours
> 3. Provide timestamp in UTC

This will involve converting time, which is prone to errors. I still
think that sometimes it is more convenient for human to use familiar
time zone and fix the offset for future.

> Also look at this reference:
> https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html
>
> ,
> | The form of date and time with UTC offset MUST NOT be used. For
> | example, the following is not valid for a DATE-TIME value:
> | 
> |  19980119T23-0800   ;Invalid time format
> `

> As with the above format, author would maybe think it is alright, but
> in general it is confusing. If author wish to specify UTC time, then
> no offset shall be used.

icalendar is _not_ the only time spec around. We can take it into
account, but I do not see any reason to follow it blindly.

Reading the linked RFC spec, I did note that the motivation for the time
format used in calendar is mainly scheduling meetings for people
residing in different time zones. I can see how the icalendar format is
reasonable within that specific purpose. I cannot see why Org timestamps
should be limited to meetings.

Note that the idea with (optionally) providing two time zones/offsets is
also coming from a time spec in
https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/

Considering that the idea with "!" has been independently proposed
within the current discussion, I assess that allowing two time zones can
be useful.

Please remember that this format is optional. If it is not useful for
your use cases, feel free to specify a single time zone.

>> I would like to remind you that timestamps are not necessarily used for
>> meetings. And not always shared with other people.
>
> Ok, and I have asked you to provide practical examples.

And I did, in one of the previous replies - scientific experiment.
Another example can be solar eclipse.

> Timestamps for past time, like for logs, I always store as UTC time in
> database, with time zone (which does not mean that time zone is
> stored, but displayed in local time zone).

For Org, the aim is not to rely solely on programmatically calculating
time in current time zone. It should be possible to create timestamps
readable in raw text. UTC may be readable for some people, but not for
others. Of course, you can put UTC timestamps in your files, if you
prefer. But more general timestamp format should permit different use
cases.

> 1. [2024-02-04 12:00 @-08,America/Vancouver] you define that @-08 has
>priority, OK fine, but how does user sees that? Only by reading
>documentation?

Yes. Either way, the timestamp should follow some format defined
in documentation.

> 2. You wish to say it will be future time of 20:00 o'clock, but time
>zone definition can change, so if it can change, why use time zone
>definition?

To get notified about the change.

> 3. UTC offset is displayed for past, as such time is accurate, but if
>you display it for future, be aware that it is wrong for reason
>that you cannot know the UTC offset in future without time
>zone. Just display UTC time. Offset is not relevant, it will be
>displayed to every user in their local time anyway, once they get
>UTC.

It may or may not be displayed. Because Org should be readable as plain
text.

> 4. Hypothetical example of clear timestamp for future:
>[2024-02-04 12:00! @-08,America/Vancouver]
>where the time would be stamped with "!" and that would mean that in the 
> time zone, meeting is at 12 o'clock.
>It would assume that UTC offset can change in future, but 12:00 clock 
> would be authoritative time for future.

This is ambiguous. 12:00 which time zone? GTM+08? America/Vancouver?

>> > Maybe this way (hypothetically):
>> >
>> > [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED]
>> >
>> > as that way you would give signal to program that you want UTC fixed
>> > time in future, and not 12:00 o'clock necessary.
>> 
>> I am sorry, but I don't understand what you mean by UTC-FIXED.
>
> You mentioned it, you wish to have offset and to remain UTC fixed.
>
> And UTC is not fixed, it is either UTC without offset, or time zone
> with UTC offset.
>
> But if you do wish, you have to make "tag" somehow, for computer
> program to know what you mean, "UTC-FIXED" is only hypothetical tag.

Sorry but I still don't understand.
For me, -08 is GMT+08 nautical time zone. Short form.
America/Vancouver is a time zone.
What is America/Vancouver/UTC-FIXED?

>> It is sometimes easier to define UTC time +offset instead of doing an
>> extra conversion in your head.
>
> I hope you understood the difference.
>
> Providing UTC time plus some offset is inconclusive. It is idea that
> is 

Should we extend org-catch-invisible-edits to more interactive commands? (was: Catching invisible edits: problem understanding doc)

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

>M-x undo
>
> I visually see no change, but I can observe by unfolding the headline
> that 'bar' has disappeared.  In my understanding of the documentation
> above and of the docstring for org-fold-catch-invisible-edits, this
> should only happen with 'nil'.
>
> What am I understanding incorrectly?  Thank you.

Only a handful of interactive commands support invisible edit checks. In
particular: self-insert-command (typing), deleting char
forward/backward, and `org-meta-return'.

I guess we may instead provide a defcustom and hook the check into
`pre-command-hook'. Would it be of interest?

> PS: a very minor incidental point: after 'bar' has disappeared, the
> headline is then void, so I tend to say that the ellipsis should
> immediately disappear as well.

The headline still contains newlines.

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

Re: Either zero or two newlines with org-agenda-block-separator, cannot seem to get one?

[Detlef Steuer]

Am Thu, 09 Feb 2023 11:53:16 -0500
schrieb TRS-80 :

> Hello List,
> 
> I had sent original email to the list some time ago, never received a
> reply.
> 
> Hopefully I have set the correct headers for proper threading; if not
> the OP can be found at (either of) these URLs:
> 
> https://yhetil.org/orgmode/33fe6d20c0591fedbdd8c6ea78e34...@isnotmyreal.name/
> 
> https://list.orgmode.org/33fe6d20c0591fedbdd8c6ea78e34...@isnotmyreal.name/
> 
> I just looked at latest master(main) and It looks like this part of
> the function `org-agenda-prepare' (in org-agenda.el) remains the same:
> 
> #+begin_src emacs-lisp
>   (insert "\n"
>   (if (stringp org-agenda-block-separator)
>   org-agenda-block-separator
> (make-string (window-max-chars-per-line)
> org-agenda-block-separator)) "\n"))
> #+end_src
> 
> This results in problem mentioned in title.
> 
> I guess no one else is affected/bothered by this?
> 
> I have been patching it locally, it would be nice not to have to
> manage that any longer.
> 

FWIW, I'm bothered, too. Would like to see that in main!

Detlef