Re: [PATCH] Re: [feature request] startup variable for link display

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> Applied, onto main; after changing the terms to
> literallinks/descriptivelinks as suggested.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dd4fd0299
> Done.

Thank you, Ihor!

Rudy
-- 
"I do not fear death.  I had been dead for billions and billions of years
before I was born, and had not suffered the slightest inconvenience from it."
--- Mark Twain, paraphrased

Rudolf Adamkovič  [he/him]
http://adamkovic.org

Feature request: support sessions in ob-emacs-lisp via IELM

[Suhail Singh]

IELM (M-x ielm) derives from comint-mode and provides a convenient
interactive environment for evaluating lisp expressions.  Some of the
conveniences such as automatically evaluating expressions can make
iterative development easier.

Currently, ob-emacs-lisp does not support sessions.  It would be nice if
support of sessions was added to ob-emacs-lisp such that the session
buffer is an ielm-mode buffer.

-- 
Suhail

Re: Feature request: exclude sub-trees by backend

[Ihor Radchenko]

Edgar Lux  writes:

> Hi, I had a need for this again (sorry for the necro-bump).

One month is perfectly normal reply time by mailing list standards :)
We just start questioning whether the discussion is active after one month.

> On Feb 26, 2024 at 5:51 PM, Ihor Radchenko  wrote:
>> The suggestions to use backend-specific export tag in the links are used
>> as ugly workarounds...
>
> Ok. It was just to show that there are other people who may use it :) .

Note that we are currently discussing somewhat similar idea, but for all
the Org markup elements, not just headings:
https://list.orgmode.org/877chvvq1b.fsf...@posteo.net/T/#madc064d96ae66467adc2ea9adb53c6c0edc7aaf7

>> As for ignore-heading, ...
>> ... the author of Org export system
>> repeatedly opposed it. This is why:
>> https://list.orgmode.org/87mwdfzmox@nicolasgoaziou.fr/
>
> Ok. Sorry. I should have assumed (or looked for) that there was a reason :) .

To be fair, it would be nice to include :ignore: tag as a part of the
Org. However, we need to somehow make sure that nothing unexpected
happens when users use :ignore: in a context where it does not make
sense:

* Heading
** Sub-heading
Text.
* Ignored :ignore:
Merging this text with previous sub-heading is unexpected.

If you have ideas how to address such scenarios, feel free to share
them.

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

Re: Feature request: exclude sub-trees by backend

[Edgar Lux]

Hi, I had a need for this again (sorry for the necro-bump).

On Feb 26, 2024 at 5:51 PM, Ihor Radchenko  wrote:
> The suggestions to use backend-specific export tag in the links are used
> as ugly workarounds...

Ok. It was just to show that there are other people who may use it :) .

> As for ignore-heading, ...
> ... the author of Org export system
> repeatedly opposed it. This is why:
> https://list.orgmode.org/87mwdfzmox@nicolasgoaziou.fr/

Ok. Sorry. I should have assumed (or looked for) that there was a reason :) .

-- 
Sent with https://mailfence.com  
Secure and private email

Re: Feature request: IDs for everything

[Tor Erlend Fjelde]

Oh, that's great news! Will be very useful; thanks Ihor!

Unfortunately life has come in the way so I haven't had the chance to pursue 
this further at the moment.

All the best,
Tor

On Wed, 06/03/2024, Ihor Radchenko  wrote:

> Tor Erlend Fjelde  writes:
>
>>> As an alternative option, we had a proposal that extends id: links to
>>> have a search option:
>>>
>>>  [[id:::search-string]]
>> ...
>> Indeed; I was actually about to have a go at implementing this because
>> I thought this would be the quickest way of adding support for referencing
>> blocks in something like org-roam. But this does seem like a sub-optimal
>> solution vs. just adding support for more general IDs, and so I thought
>> it would be better to see if that could be done first (hence I'm here).
>
> FYI, we added [[id:::search-string]] links to the latest development
> version of Org mode. This new feature does not cover global ids for
> non-headings though.
>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: Feature request: IDs for everything

[Ihor Radchenko]

Tor Erlend Fjelde  writes:

>> As an alternative option, we had a proposal that extends id: links to
>> have a search option:
>>
>>  [[id:::search-string]]
> ...
> Indeed; I was actually about to have a go at implementing this because
> I thought this would be the quickest way of adding support for referencing
> blocks in something like org-roam. But this does seem like a sub-optimal
> solution vs. just adding support for more general IDs, and so I thought
> it would be better to see if that could be done first (hence I'm here).

FYI, we added [[id:::search-string]] links to the latest development
version of Org mode. This new feature does not cover global ids for
non-headings though.

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

Re: Feature request: exclude sub-trees by backend

[Ihor Radchenko]

[ Adding Org mailing list back to CC. ]

Edgar Lux  writes:

> ...
>> I think that it would be ok to add such feature if multiple users are
>> interested.
>
> Similar (and may be the ignore-heading from ox-extra should also become 
> standard, because I found it a lot):
>
> https://emacs.stackexchange.com/a/75510
> https://emacs.stackexchange.com/a/75573
> https://emacs.stackexchange.com/a/60016

The suggestions to use backend-specific export tag in the links are used
as ugly workarounds. I am not sure if they justify adding a new feature
for Org mode. (Why would we add something with a purpose of being used
as a workaround instead of fixing the original problem, after all?)

As for ignore-heading, please search list archives - adding this feature
has been discussed many times and the author of Org export system
repeatedly opposed it. This is why:
https://list.orgmode.org/87mwdfzmox@nicolasgoaziou.fr/

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

Re: Feature request: exclude sub-trees by backend

[Ihor Radchenko]

Edgar Lux  writes:

> I am trying to exclude different sub-trees (a.k.a. headings or sections), 
> depending on the exporter backend. I am familiar with =:noexport:= to exclude 
> selected sections (disregarding the backend). I found a solution, but it is 
> only intended for a specific backend:
>
> https://emacs.stackexchange.com/a/76454

For arbitrary backend, you can try

(defun exclude-from-latex-export-hook (backend)
  (setq org-export-exclude-tags (cons (format "noexport_%s" backend) 
org-export-exclude-tags)))

> I would like to recommend that such a thing is implemented for any backend. 
> So that :noexport_X: (where X is a backend) is excluded. Something like:
>
> * Not for html   :noexport_html:
>
> * For HTML   :noexport_latex:

This is not a feature request I see often in the forums.
It is also easy to implement.
I think that it would be ok to add such feature if multiple users are 
interested.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Feature request: exclude sub-trees by backend

[Edgar Lux]

Hello!

I am trying to exclude different sub-trees (a.k.a. headings or sections), 
depending on the exporter backend. I am familiar with =:noexport:= to exclude 
selected sections (disregarding the backend). I found a solution, but it is 
only intended for a specific backend:

https://emacs.stackexchange.com/a/76454

I would like to recommend that such a thing is implemented for any backend. So 
that :noexport_X: (where X is a backend) is excluded. Something like:

* Not for html   :noexport_html:

* For HTML   :noexport_latex:

Thank you!



-- 
Sent with https://mailfence.com  
Secure and private email

Re: [PATCH] Re: [feature request] startup variable for link display

[Ihor Radchenko]

Ihor Radchenko  writes:

> See the attached patch.

Applied, onto main; after changing the terms to
literallinks/descriptivelinks as suggested.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dd4fd0299
Done.

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

Re: Feature request: export form feed as page break

[Ihor Radchenko]

Timothy  writes:

>> This is a fork of the ODT exporter in Emacs Orgmode.
>
> Should I take this to mean that the ox-odt.el in org-mode is no longer 
> actively
> maintained?

ox-odt.el in Org mode does not currently have a dedicated maintainer.
So, it is maintained just as any other library without maintainer in Org
- by core maintainers.

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

Re: Feature request: export form feed as page break

[Timothy]

Hi Jambunathan,

> I am the original author of ox-odt.el.
>
> The page break feature is available as part of
> 
>
> This is a fork of the ODT exporter in Emacs Orgmode.

Should I take this to mean that the ox-odt.el in org-mode is no longer actively
maintained?

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 .

Re: [PATCH] Re: [feature request] startup variable for link display

[Ihor Radchenko]

Rudolf Adamkovič  writes:

>> #+startup: showlinks
>> and
>> #+startup: compresslinks
>
> Why not continue with established terminology?
>
> #+STARTUP: descriptivelinks
> #+STARTUP: literallinks

I do not have a strong opinion here.
I used "show" following showstars/showeverything/etc and because it is
shorter. "hide" did not fit though, which is why I went with "compress".

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

Re: [PATCH] Re: [feature request] startup variable for link display

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> #+startup: showlinks
> and
> #+startup: compresslinks

Why not continue with established terminology?

#+STARTUP: descriptivelinks
#+STARTUP: literallinks

Rudy
-- 
"It is no paradox to say that in our most theoretical moods we may be
nearest to our most practical applications."
--- Alfred North Whitehead, 1861-1947

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

[PATCH] Re: [feature request] startup variable for link display

[Ihor Radchenko]

"Fraga, Eric"  writes:

> Assuming I have not missed something, is there a variable I can set on
> visiting an org buffer/file that ensures that links are displayed fully?
>
> Once I've loaded an org file, I can
>
>M-x org-toggle-link-display RET.
>
> but I would like certain files to start up with links displayed.
>
> If not already possible, it would be nice to either set a file local
> variable or have, say:
>
> #+startup: displaylinks

I went with

#+startup: showlinks
and
#+startup: compresslinks

See the attached patch.
Please test.

>From f180be291a81062a5c6344876c172282969d4c66 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Fri, 22 Dec 2023 13:04:04 +0100
Subject: [PATCH] Allow per-buffer setting of org-link-descriptive via
 #+STARTUP options

* lisp/org.el (org-startup-options): Add new startup options to set
`org-link-descriptive'.
(org-mode): Move #+startup keyword parsing before setting up link
visibility.
* doc/org-manual.org (Link Format):
(Summary of In-Buffer Settings): Document the new startup option.
* etc/ORG-NEWS (~org-link-descriptive~ can now be set per-buffer via
=#+STARTUP= options): Announce the new feature.

Link: https://orgmode.org/list/87bkst1nfl@ucl.ac.uk
---
 doc/org-manual.org | 14 +-
 etc/ORG-NEWS   |  8 
 lisp/org.el| 24 +---
 3 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index cfa59ec37..da9d8c837 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -3172,7 +3172,8 @@ ** Link Format
 incomplete and the internals are again displayed as plain text.
 Inserting the missing bracket hides the link internals again.  To show
 the internal structure of all links, use the menu: Org \rarr
-Hyperlinks \rarr Literal links.
+Hyperlinks \rarr Literal links, customize ~org-link-descriptive~, or use
+=showlinks= [[*Summary of In-Buffer Settings][startup option]].
 
 ** Internal Links
 :PROPERTIES:
@@ -20229,6 +20230,17 @@ ** Summary of In-Buffer Settings
   | =inlineimages=   | Show inline images.   |
   | =noinlineimages= | Do not show inline images on startup. |
 
+  #+vindex: org-link-descriptive
+  Bracket links in Org buffers are displayed hiding the link path and
+  brackets.  For example, =[[https://orgmode.org][Org Website]]= is,
+  by default, displayed as "Org Website", hiding the link itself and
+  just displaying its description.  Alternatively, the links can be
+  displayed in full.  The corresponding variable is
+  ~org-link-descriptive~.
+
+  | =compresslinks= | Hide path and brackets in links. |
+  | =showlinks= | Do not hide anything.|
+
   #+vindex: org-log-done
   #+vindex: org-log-note-clock-out
   #+vindex: org-log-repeat
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 6c81221c1..9b3f83705 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -362,6 +362,14 @@ The change is breaking when ~org-use-property-inheritance~ is set to ~t~.
 
 The =TEST= parameter is better served by Emacs debugging tools.
 ** New and changed options
+*** ~org-link-descriptive~ can now be set per-buffer via =#+STARTUP= options
+
+In addition to ~org-link-descriptive~ custom option, link display can
+now be controlled per-buffer as:
+
+: #+STARTUP: showlinks
+: #+STARTUP: compresslinks
+
 *** New variable ~org-clock-out-removed-last-clock~
 
 The variable is intended to be used by ~org-clock-out-hook~.  It is a
diff --git a/lisp/org.el b/lisp/org.el
index 6e6e075b4..7f7bc3000 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4061,6 +4061,8 @@ (defconst org-startup-options
 ("align" org-startup-align-all-tables t)
 ("noalign" org-startup-align-all-tables nil)
 ("shrink" org-startup-shrink-all-tables t)
+("compresslinks" org-link-descriptive t)
+("showlinks" org-link-descriptive nil)
 ("inlineimages" org-startup-with-inline-images t)
 ("noinlineimages" org-startup-with-inline-images nil)
 ("latexpreview" org-startup-with-latex-preview t)
@@ -4847,6 +4849,17 @@ (define-derived-mode org-mode outline-mode "Org"
   (org-load-modules-maybe)
   (when org-agenda-file-menu-enabled
 (org-install-agenda-files-menu))
+  (setq-local outline-regexp org-outline-regexp)
+  (setq-local outline-level 'org-outline-level)
+  ;; Initialize cache.
+  (org-element-cache-reset)
+  (when (and org-element-cache-persistent
+ org-element-use-cache)
+(org-persist-load
+ `((elisp org-element--cache) (version ,org-element-cache-version))
+ (current-buffer)
+ 'match-hash :read-related t))
+  (org-set-regexps-and-options)
   (when (and org-link-descriptive
  (eq org-fold-core-style 'overlays))
 (add-to-invisibility-spec '(org-link)))
@@ -4857,8 +4870,6 @@ (define-derived-mode org-mode outline-mode "Org"
   (if org-link-descriptive
   (org-fold-core-set-folding-spec-property (car org-link--link-folding-spec) :visible nil)
 (org-fold-core-set-folding-spec-property (car 

Re: Feature request: IDs for everything

[Ihor Radchenko]

Max Nikulin  writes:

>> If we simply allow id: links to point to non-headings, it will be a
>> major breaking change that may affect third-party packages. So, we
>> need to design the extended ids carefully to avoid breakage.
>
> A defcusom user options whether id:UUID links for non-heading elements 
> are allowed. It is just an opinion/idea and nothing more.

> Are ids for whole files (placed before first headings) are problematic 
> for 3rd party packages?

Fair point. Even existing id links may not always point to a heading
(when pointing to IDs in top-level property drawer). So, the potential
breakage I was talking about is already there, and third-party packages
already have to adapt.

I still do not feel confident that it will be safe to blindly change
org-id in the proposed way though. Although I cannot think of clear
examples why it would cause problems worse compared to the existing id:
links to files. So, it may just be my unmotivated concern.

>>   [[id:unique-file-id:object-id-inside-the-file]]
>
> Perhaps than it should be id:FILE-UUID::SEARCH with usual search options 
> like #CUSTOM_ID, *Heading, etc., with the new variant id:OBJECT-UUID. 
> However I am unsure if search should be limited to a subtree if 
> HEADING-UUID is specified instead of FILE-UUID.

I indeed meant "::" search option. Sorry for the typo.

In any case, I agree with Tor that search option is less elegant. If we
can go for direct UUIDs, let's do it.

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

Re: Feature request: IDs for everything

[Max Nikulin]

On 21/10/2023 20:05, Ihor Radchenko wrote:

Tor Erlend Fjelde writes:


I was wondering if there's a reason why we couldn't have IDs a la
org-id.el for everything? It seem to me that it would be useful to use
something like `#+ID` in place of `#+NAME` for tables, blocks, etc. as
well as headlines.


I think, another complication is referring source code blocks as 
variable values in header arguments and as noweb fragments. It would be 
great to be possible to specify "id:UUID" instead of fuzzy names. 
Perhaps it may be solved by explicit calls to new functions. If 
possible, I would avoid proliferation of keyword in favor of "#+name: 
id:UUID"


And there are references to particular lines inside code blocks...


Apart from #+NAME, we also have radio <<>> that can be used a
link anchors (#+NAME or other affiliated keywords are not allowed, for
example, in items).


I think, you mean <>, not <<>> targets that activates 
plain text words. It seems, the latter cannot be currently exported as 
explicit links [[radio][Radio]]. I am unsure what conflicts may appear 
during attempt to allow optional explicit types, e.g. <>.



We also discussed linking to #+name and <<>> globally, without
specifying the file path.


From my point of view, it should be either global id:UUID links or 
file:doc.org::name local links.



If we simply allow id: links to point to non-headings, it will be a
major breaking change that may affect third-party packages. So, we
need to design the extended ids carefully to avoid breakage.


A defcusom user options whether id:UUID links for non-heading elements 
are allowed. It is just an opinion/idea and nothing more.


Are ids for whole files (placed before first headings) are problematic 
for 3rd party packages?



  [[id:unique-file-id:object-id-inside-the-file]]


Perhaps than it should be id:FILE-UUID::SEARCH with usual search options 
like #CUSTOM_ID, *Heading, etc., with the new variant id:OBJECT-UUID. 
However I am unsure if search should be limited to a subtree if 
HEADING-UUID is specified instead of FILE-UUID.

Re: Feature request: IDs for everything

[Ihor Radchenko]

Tor Erlend Fjelde  writes:

>> If we simply allow id: links to point to non-headings, it will be a
>> major breaking change that may affect third-party packages. So, we
>> need to design the extended ids carefully to avoid breakage. For
>> example, `org-id-find' and other API function may need to work in two
>> modes: (1) legacy, only searching for headings; (2) new, searching for
>> anything. This can, for example, be done via an extra optional argument.
>
> This is a very good point, and definitively makes things non-trivial.
> Nonetheless, I'd be happy to have a go at it if this seems like the way
> to go! But I'll probably need quite a bit of help in the process as I
> haven't contributed to Org before.

This is a moderately difficult contribution. As a first step, you will
need to study org-id.el and see what should be changed there to support
the new feature.

If you encounter any difficulties, feel free to ask here.

Also, before you invest too much time into this, please check if you can
do FSF copyright assignment (see
https://orgmode.org/worg/org-contribute.html#copyright). As a GNU
project, we cannot accept large contributions without this paperwork.

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

Re: Feature request: IDs for everything

[Tor Erlend Fjelde]

> Although we have at least one caveat that we need to consider - the
> current users of the id: links blindly assume that they always link to
> headings. This includes many third-party packages, like org-roam.
>
> If we simply allow id: links to point to non-headings, it will be a
> major breaking change that may affect third-party packages. So, we
> need to design the extended ids carefully to avoid breakage. For
> example, `org-id-find' and other API function may need to work in two
> modes: (1) legacy, only searching for headings; (2) new, searching for
> anything. This can, for example, be done via an extra optional argument.

This is a very good point, and definitively makes things non-trivial.
Nonetheless, I'd be happy to have a go at it if this seems like the way
to go! But I'll probably need quite a bit of help in the process as I
haven't contributed to Org before.

> As an alternative option, we had a proposal that extends id: links to
> have a search option:
>
>  [[id::search-string]]
>
> Then, we may have top-level drawer like
>
> :PROPERTIES:
> :ID: unique-file-id
> :END:
>
> And then refer to anything inside the file as
>
>  [[id:unique-file-id:object-id-inside-the-file]]

Indeed; I was actually about to have a go at implementing this because
I thought this would be the quickest way of adding support for referencing
blocks in something like org-roam. But this does seem like a sub-optimal
solution vs. just adding support for more general IDs, and so I thought
it would be better to see if that could be done first (hence I'm here).

All the best,
Tor


On Sat, 21/10/2023, Ihor Radchenko  wrote:

> Tor Erlend Fjelde  writes:
>
>> I was wondering if there's a reason why we couldn't have IDs a la
>> org-id.el for everything? It seem to me that it would be useful to use
>> something like `#+ID` in place of `#+NAME` for tables, blocks, etc. as
>> well as headlines.
>
> This has been discussed in the past.
>
> Apart from #+NAME, we also have radio <<>> that can be used a
> link anchors (#+NAME or other affiliated keywords are not allowed, for
> example, in items).
>
> We also discussed linking to #+name and <<>> globally, without
> specifying the file path.
>
>> Would this go against the intended design of
>> org-id.el, or is this a change that would be welcome but that no one
>> has gotten around to implementing yet?
>
> Mostly nobody has gotten around.
>
> Although we have at least one caveat that we need to consider - the
> current users of the id: links blindly assume that they always link to
> headings. This includes many third-party packages, like org-roam.
>
> If we simply allow id: links to point to non-headings, it will be a
> major breaking change that may affect third-party packages. So, we
> need to design the extended ids carefully to avoid breakage. For
> example, `org-id-find' and other API function may need to work in two
> modes: (1) legacy, only searching for headings; (2) new, searching for
> anything. This can, for example, be done via an extra optional argument.
>
> -
>
> As an alternative option, we had a proposal that extends id: links to
> have a search option:
>
>  [[id::search-string]]
>
> Then, we may have top-level drawer like
>
> :PROPERTIES:
> :ID: unique-file-id
> :END:
>
> And then refer to anything inside the file as
>
>  [[id:unique-file-id:object-id-inside-the-file]]
>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: Feature request: export form feed as page break

[Marvin Gülker]

Am Sonntag, dem 22. Oktober 2023 schrieb Jambunathan K:
> I am the original author of ox-odt.el.
>
> The page break feature is available as part of
> https://github.com/kjambunathan/org-mode-ox-odt

I took a look at 
https://github.com/kjambunathan/org-mode-ox-odt/blob/master/notes/SNIPPETS.org#improve-support-for-pagebreaks
and indeed, there is a page break feature, but it seems to be exclusive
to this backend. I would prefer it if the page break feature was part of
org’s actual markup and thus work with all backends, including LaTeX,
without backend-specific markup.

> This is a fork of the ODT exporter in Emacs Orgmode.

I heard of it before; for now I think I want to stick with upstream org.
I do keep an eye on this fork in case I need one of its exclusive
features. Since from a technical point, I am mostly writing pretty
boring pure text documents, it worked out until now mostly.

  -MG

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Feature request: export form feed as page break

[Max Nikulin]

On 22/10/2023 16:00, Ihor Radchenko wrote:

Max Nikulin writes:


P.S. I am against using non-printable characters for markup. It might be
an \... entity for page break inside a paragraph, "#+...:" keyword
between block-level elements, etc.


What about all the above? We may provide entity, keyword, and also ^L.


I have not changed my opinion. Control characters should not be used for 
plain text markup.


^L might be inconvenient for users of browser-based tools (organice, 
etc.). Firefox displays it as a square with 0c code inside  
and as some space in regular tags. In Chromium it is invisible similar 
to zero-width space. Fortunately browsers allows to copy a paste it, it 
is exemption from control characters that are stripped on copy to 
protect users from unexpected effects of paste.


However e.g. konsole (terminal application) shows a warning popup on 
attempt to paste text containing ^L.


My vote is for portability, so usage of ^L should be discouraged.

Re: Feature request: export form feed as page break

[Uwe Brauer]

>>> "JK" == Jambunathan K  writes:

> I am the original author of ox-odt.el.
> The page break feature is available as part of
> https://github.com/kjambunathan/org-mode-ox-odt

> This is a fork of the ODT exporter in Emacs Orgmode.


Hello

Since I have used this exporter for some time now, I would like to share
a few thoughts.

I am «forced» in my university to interchange docx(odt) and excel(ods)
file with my colleagues.[1]. By interchange, I really mean editing
documents. For those of you, who had a similar experience, I presume you
can feel the pain.

Now there were a couple of features I needed and which the org vanilla
exporter did not provide:

- odt: nested tables and page breaks

- ods: you can export org-tables to ods in org-mode (I use the
  following wrapper)

#+begin_src 
(defun org-table-export-to-spreadsheet (arg) 
  "Export org table to varios first to cvs and then via LO/OO 
to various  spreadsheet  format, the most common are `ods', `xls' and 
`xlsx'."
  (interactive "sFormat: ")
  (let* ((source-file  (file-name-sans-extension (buffer-file-name 
(current-buffer
 (csv-file (concat source-file ".csv")))
(org-table-export csv-file "my-tbl-to-csv")
(org-odt-convert csv-file arg)))
#+end_src

But formulas are not exported, nor can you export various tables to
different sheets.

The https://github.com/kjambunathan/org-mode-ox-odt exporter on the
other side, can:

1. Export simple formulas such as *vsum* etc

2. More complicated things like org-lookup-first and remote which
   are then exported as VSLOOKUP etc

3. Export several tables in one org document to several sheets in an
   ods document.

For me, these features have speeded up my workflow considerably.

Two additional comments

1. The exporter regularly merges the latest org versions into its
   fork, so there is no compatibility problem.

2. The author/maintainer is very responsive to bug reports and keen
   to implement new features.

So in summary my experience has been entirely positive.

Regards

Uwe Brauer  


-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Hamas bestialic terroristic attack on Israel, especially the 
despicable pogroms.
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of Ukraine.
I support the EU membership of Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/


smime.p7s
Description: S/MIME cryptographic signature

Re: Feature request: export form feed as page break

[Ihor Radchenko]

Max Nikulin  writes:

> P.S. I am against using non-printable characters for markup. It might be 
> an \... entity for page break inside a paragraph, "#+...:" keyword 
> between block-level elements, etc.

What about all the above? We may provide entity, keyword, and also ^L.

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

Re: Feature request: export form feed as page break

[Ihor Radchenko]

Marvin Gülker  writes:

> ...
> On the other hand, there are semantic page breaks. The page break I
> described in the OP is of this kind – it has been added specifically to
> hide the proposed solution from the first page and allow me to just
> print page 1 and hand that one to the students. For this page break, the
> paper size is completely irrelevant. Even if I printed on A3 for
> whatever reason (maybe I ran out of A4 paper), the semantic still
> requires the solution to be on page 2. It is this kind of page break I
> am referring to and which I think is representable in markup.

Fair point. And adding "semantic" page breaks to Org syntax will not
rule out "typographical" page breaks via @@backend:...@@ or macro syntax.

>> - In LaTeX, this is easy to achieve simply putting =\clearpage=
>
> A quick note here: \newpage and \clearpage do different things in LaTeX
> if there is floating material in the document. \clearpage typesets the
> floats and then breaks the page, whereas \newpage does not consider them.

If we consider semantic page breaks, I think that \newpage is more
appropriate as it will prevent floats defined below from showing up.

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

Re: Feature request: export form feed as page break

[Ihor Radchenko]

Max Nikulin  writes:

> On 21/10/2023 16:19, Ihor Radchenko wrote:
>> - page breaks location is very much backend-dependent; typographic 
>>   detail https://list.orgmode.org/orgmode/875yhiyxnb.fsf@localhost
>
> Is the link correct?

Indeed, it is not.
The right link is:

https://list.orgmode.org/orgmode/87sfkaague@posteo.net/
Manuel Macías [ML:Org mode] (2022) Re: Explicit page breaks

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

Re: Feature request: export form feed as page break

[Jambunathan K]

I am the original author of ox-odt.el.

The page break feature is available as part of
https://github.com/kjambunathan/org-mode-ox-odt

This is a fork of the ODT exporter in Emacs Orgmode.

If you are interested, please open an Discussions thread or a Issue on
Github.  Outline your requirements, and I will be happy to share a
recipe or improve the ODT exporter.

For those who rely on ODT exporter--I know there aren't many--please
consider switching to my repo.

If you are going to ask for a feature request for ODT exporter in
emacs-orgmode, you can get some lip-service, and low-effort
patches. (TLDR: The ODT exporter in Emacs is a working, but a dead
code.)

If you are going to ask for a feature request from me, you will
actually see patches.  (TLDR: I have been at this exporter for well
over 13 years now.  See my contribution activity on Github).

As a PSA, I have been working on an experimental ODS export feature in
order to help Uwe Brauer share Org mode tables (with TBLFMs) to ODS
spreadsheet with Excel formulae.

PS: ox-odt fork is a GPL software.  (People who insist on licenses and 
go crazy about it are commercial minded, or ideological nuts.  I am your 
neighbour uncle who wants to help you (and interact with you) in an 
unstructured setting ...


Jambunathan K.



On 21/10/23 13:12, Marvin Gülker wrote:

Dear list,

I am creating training material for the education of German law
students, which usually consists of a case story on one or two pages,
followed by a page break after which a proposal for resolving the case
is provided. The structure is like this because usually I provide the
case story before the meeting, where I work out a solution with the
students, and afterwards I want to provide them with complete material,
while still having everything contained in one file.

With org, I can easily export to LaTeX and thereby to PDF, and it works
quite nicely. However, for the page break I always need to write a
literal \newpage into the document, which does work, but only in LaTeX.
Since I am the only one using org/LaTeX at my chair, I have to convert
these documents to DOCX (using the ODT exporter) when a collegue wants
an editable version of them. As a LaTeX command, \newpage does not work
when exporting to ODT. I thus open the exported document manually after
the export and insert the page break using LibreOffice.

To ease this process, I would like to request that the ASCII control
character U+000C FORM FEED (displayed by emacs as ^L and also known as
`\f' in C string notation) is recognised by exporters and translated to
the corresponding page break command, that is, in LaTeX \newpage and in
ODT to the XML that makes LibreOffice start a new page. For HTML, it
could be exported as  or similar, and for exporters which have no notion of
pages, it could just be copied over to the exported document as-is.

   -MG

Re: Feature request: export form feed as page break

[Marvin Gülker]

Am Samstag, dem 21. Oktober 2023 schrieb Ihor Radchenko:
> In general, adding page breaks can make sense. The main concern is that
> the location of page breaks may or may not be export
> backend-independent. In certain scenarios, you may need to put page
> breaks in one place for odt export, but in other place in LaTeX export
> (for example, when page size is different in these two cases).

I think this conflates two different things. On the one hand, there are
typographically indicated page breaks, which appear to be those you are
thinking of here. For instance, the question where to break the page
within a running paragraph of text does depend on how many lines will
show up on the next page; if the answer is 1, better not put a break
here and rather break after the paragraph. Another example would be if
you want a page break before a heading only in certain cases dependent
on other material on the page or the page (size) itself. I agree that
this kind of page break feature cannot be represented properly in (org)
markup.

On the other hand, there are semantic page breaks. The page break I
described in the OP is of this kind – it has been added specifically to
hide the proposed solution from the first page and allow me to just
print page 1 and hand that one to the students. For this page break, the
paper size is completely irrelevant. Even if I printed on A3 for
whatever reason (maybe I ran out of A4 paper), the semantic still
requires the solution to be on page 2. It is this kind of page break I
am referring to and which I think is representable in markup.

> - In LaTeX, this is easy to achieve simply putting =\clearpage=

A quick note here: \newpage and \clearpage do different things in LaTeX
if there is floating material in the document. \clearpage typesets the
floats and then breaks the page, whereas \newpage does not consider them.

  -MG

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Feature request: export form feed as page break

[Marvin Gülker]

Am Samstag, dem 21. Oktober 2023 schrieb Max Nikulin:
> As a workaround you may define an Org macro that expands to
> @@latex:\newpage@@ and appropriate XML element inside @@odt:…@@.

Fair enough, this is possible, but then I have to consider each backend
I may export to and read up on how the respective backend does this. As
it stands, I just do not know how the piece inside @@odt:…@@ would have
to look like. If the decision here is to not add a page break feature to
org, then I will probably go that route, though.

> P.S. I am against using non-printable characters for markup. It might
> be an \... entity for page break inside a paragraph, "#+...:" keyword
> between block-level elements, etc.

I have no strong opinion on that, but I just thought that ^L seems like
a good fit, and I saw it used in Elisp files earlier so I thought it is
common enough to just reuse it.

  -MG

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Feature request: export form feed as page break

[Max Nikulin]

On 21/10/2023 16:19, Ihor Radchenko wrote:
- page breaks location is very much backend-dependent; typographic 
  detail https://list.orgmode.org/orgmode/875yhiyxnb.fsf@localhost


Is the link correct?

  Ihor Radchenko to emacs-orgmode… Re: FR: support hard-newlines
  [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]
  Tue, 20 Sep 2022 21:37:44 +0800.

Re: Feature request: export form feed as page break

[Max Nikulin]

On 21/10/2023 14:42, Marvin Gülker wrote:
However, for the page break I always need to write a literal \newpage 
into the document, which does work, but only in LaTeX.


As a workaround you may define an Org macro that expands to 
@@latex:\newpage@@ and appropriate XML element inside @@odt:…@@.


Another approach is a tag or a property for headings and custom export 
backends that adds page break before or after such headings.


P.S. I am against using non-printable characters for markup. It might be 
an \... entity for page break inside a paragraph, "#+...:" keyword 
between block-level elements, etc.

Re: Feature request: IDs for everything

[Ihor Radchenko]

Tor Erlend Fjelde  writes:

> I was wondering if there's a reason why we couldn't have IDs a la
> org-id.el for everything? It seem to me that it would be useful to use
> something like `#+ID` in place of `#+NAME` for tables, blocks, etc. as
> well as headlines.

This has been discussed in the past.

Apart from #+NAME, we also have radio <<>> that can be used a
link anchors (#+NAME or other affiliated keywords are not allowed, for
example, in items).

We also discussed linking to #+name and <<>> globally, without
specifying the file path.

> Would this go against the intended design of
> org-id.el, or is this a change that would be welcome but that no one
> has gotten around to implementing yet?

Mostly nobody has gotten around.

Although we have at least one caveat that we need to consider - the
current users of the id: links blindly assume that they always link to
headings. This includes many third-party packages, like org-roam.

If we simply allow id: links to point to non-headings, it will be a
major breaking change that may affect third-party packages. So, we
need to design the extended ids carefully to avoid breakage. For
example, `org-id-find' and other API function may need to work in two
modes: (1) legacy, only searching for headings; (2) new, searching for
anything. This can, for example, be done via an extra optional argument.

-

As an alternative option, we had a proposal that extends id: links to
have a search option:

 [[id::search-string]]

Then, we may have top-level drawer like

:PROPERTIES:
:ID: unique-file-id
:END:

And then refer to anything inside the file as

 [[id:unique-file-id:object-id-inside-the-file]]

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

Re: Feature request: export form feed as page break

[Ihor Radchenko]

Marvin Gülker  writes:

> 
> To ease this process, I would like to request that the ASCII control
> character U+000C FORM FEED (displayed by emacs as ^L and also known as
> `\f' in C string notation) is recognised by exporters and translated to
> the corresponding page break command, that is, in LaTeX \newpage and in
> ODT to the XML that makes LibreOffice start a new page. For HTML, it
> could be exported as  or similar, and for exporters which have no notion of
> pages, it could just be copied over to the exported document as-is.

See https://list.orgmode.org/orgmode/87mtamjrft.fsf@localhost/

In general, adding page breaks can make sense. The main concern is that
the location of page breaks may or may not be export
backend-independent. In certain scenarios, you may need to put page
breaks in one place for odt export, but in other place in LaTeX export
(for example, when page size is different in these two cases).

Below are some of my personal notes on this topic:

Page breaks is one of the common typographical settings people do use.

- In LaTeX, this is easy to achieve simply putting =\clearpage=
- However, in exports like odt, the page break may be tricky and involve direct 
xml - not great
  https://list.orgmode.org/orgmode/87leq49bu0.fsf...@posteo.net/
  
- Page breaks even make sense in text files (ASCII or even directly in Org)
  https://list.orgmode.org/orgmode/87mtamjrft.fsf@localhost
  
- Page breaks are directly supported by Emacs (filling), alongside with 
hard-newlines
  https://list.orgmode.org/orgmode/875yhiyxnb.fsf@localhost
  

We may as well add a new element to Org that marks page breaks.

+ Page break should be an object as page breaks do not necessarily split 
paragraphs
+ People also want page breaks to precede certain elements (most importantly, 
headlines)
  + This is somewhat unrelated issue though -- too complex just for a single 
syntax element
+ It would be more productive to introduce generalized syntax to prepend 
actual Org elements during export

- page breaks location is very much backend-dependent; typographic detail
  https://list.orgmode.org/orgmode/875yhiyxnb.fsf@localhost

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

Re: Feature request: IDs for everything

[Tor Erlend Fjelde]

> What could be the added benefits of having such a header argument? I can 
> think of this benefit: #+NAME would be used for referencing them through a 
> human-friendly name and the name could change and the #+ID would be an UUID 
> that is not expected to change.

This is indeed one use-case I had in mind!


Generally speaking, I would imagine the motivation is the same as for ID vs. 
CUSTOM_ID for headlines? As in, most arguments made for the introduction of 
org-id.el in the first place can be made about linking to blocks, etc. too? I 
haven't seen the original discussions around this, so I'm only speeculating 
here.

What I specifically had in mind is mainly about what you can expect from an ID 
vs. NAME. IIUC the ID property is meant to be a "globally" unique identifier, 
while something like NAME is generally only meant to only be /locally/ unique.
Hence, if you want to interact with such references programmatically, it's 
useful to have an a "globally" consistent way of referencing not just 
headlines, but also blocks, etc.

A fairly prominent example is org-roam.el, which, when they moved to v2, 
decided to solely rely on IDs rather than allowing all standard forms of Org 
links exactly because "global" consistency is so important for them.

org-id.el also just provides a lot of convenient functionality, e.g. automatic 
creation of ID if it does not yet exist, which would similarly benefit linking 
to non-files and -headlines.

Hope that clearifies a bit!

All the best,
Tor


On Fri, 20/10/2023, Rodrigo Morales  wrote:

> Currently, headlines can have an ID (see minimal working example below):
>
> #+BEGIN_SRC org
> * My headline 1
> * My headline 2
> :PROPERTIES:
> :ID: e8745be0-906d-4e02-b427-d298f5751f6c
> :END:
> #+END_SRC
>
> Blocks can't have IDs, but you could use a UUID as the for blocks (see
> minimal working example below). You can do the same with tables.
>
> #+BEGIN_SRC org
> ,#+NAME: 412f567b-26ce-4f21-b07f-f5296c830314
> ,#+BEGIN_SRC sh
> seq 1 3
> ,#+END_SRC
>
> ,#+RESULTS: 412f567b-26ce-4f21-b07f-f5296c830314
> ,#+begin_example
> 1
> 2
> 3
> ,#+end_example
>
> ,#+HEADER: :noweb yes
> ,#+BEGIN_SRC sh
> echo foo <<412f567b-26ce-4f21-b07f-f5296c830314()>>
> ,#+END_SRC
>
> ,#+RESULTS:
> ,#+begin_example
> foo 1
> foo 2
> foo 3
> foo
> ,#+end_example
> #+END_SRC
>
> What I understand from your message is that you would like to have a new
> header argument called #+ID: that could be used for code blocks and tables.
> Am I right? If so, I have a question: What could be the added benefits of
> having such a header argument? I can think of this benefit: #+NAME would be
> used for referencing them through a human-friendly name and the name could
> change and the #+ID would be an UUID that is not expected to change.
>
> On Fri, 20 Oct 2023 at 19:13, Tor Erlend Fjelde 
> wrote:
>
>> Hi all,
>>
>> I was wondering if there's a reason why we couldn't have IDs a la
>> org-id.el for everything?
>> It seem to me that it would be useful to use something like `#+ID` in
>> place of `#+NAME` for tables, blocks, etc. as well as headlines.
>> Would this go against the intended design of org-id.el, or is this a
>> change that would be welcome but that no one has gotten around to
>> implementing yet?
>>
>> Also, sorry if this is not correct way to go about this; it's my first
>> time posting to a mailing list. Let me know if there are some guidelines or
>> something somewhere that I should read and make use of.
>>
>> All the best,
>> Tor
>>
>>

Feature request: export form feed as page break

[Marvin Gülker]

Dear list,

I am creating training material for the education of German law
students, which usually consists of a case story on one or two pages,
followed by a page break after which a proposal for resolving the case
is provided. The structure is like this because usually I provide the
case story before the meeting, where I work out a solution with the
students, and afterwards I want to provide them with complete material,
while still having everything contained in one file.

With org, I can easily export to LaTeX and thereby to PDF, and it works
quite nicely. However, for the page break I always need to write a
literal \newpage into the document, which does work, but only in LaTeX.
Since I am the only one using org/LaTeX at my chair, I have to convert
these documents to DOCX (using the ODT exporter) when a collegue wants
an editable version of them. As a LaTeX command, \newpage does not work
when exporting to ODT. I thus open the exported document manually after
the export and insert the page break using LibreOffice.

To ease this process, I would like to request that the ASCII control
character U+000C FORM FEED (displayed by emacs as ^L and also known as
`\f' in C string notation) is recognised by exporters and translated to
the corresponding page break command, that is, in LaTeX \newpage and in
ODT to the XML that makes LibreOffice start a new page. For HTML, it
could be exported as  or similar, and for exporters which have no notion of
pages, it could just be copied over to the exported document as-is.

  -MG

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Feature request: IDs for everything

[Rodrigo Morales]

Currently, headlines can have an ID (see minimal working example below):

#+BEGIN_SRC org
* My headline 1
* My headline 2
:PROPERTIES:
:ID: e8745be0-906d-4e02-b427-d298f5751f6c
:END:
#+END_SRC

Blocks can't have IDs, but you could use a UUID as the for blocks (see
minimal working example below). You can do the same with tables.

#+BEGIN_SRC org
,#+NAME: 412f567b-26ce-4f21-b07f-f5296c830314
,#+BEGIN_SRC sh
seq 1 3
,#+END_SRC

,#+RESULTS: 412f567b-26ce-4f21-b07f-f5296c830314
,#+begin_example
1
2
3
,#+end_example

,#+HEADER: :noweb yes
,#+BEGIN_SRC sh
echo foo <<412f567b-26ce-4f21-b07f-f5296c830314()>>
,#+END_SRC

,#+RESULTS:
,#+begin_example
foo 1
foo 2
foo 3
foo
,#+end_example
#+END_SRC

What I understand from your message is that you would like to have a new
header argument called #+ID: that could be used for code blocks and tables.
Am I right? If so, I have a question: What could be the added benefits of
having such a header argument? I can think of this benefit: #+NAME would be
used for referencing them through a human-friendly name and the name could
change and the #+ID would be an UUID that is not expected to change.

On Fri, 20 Oct 2023 at 19:13, Tor Erlend Fjelde 
wrote:

> Hi all,
>
> I was wondering if there's a reason why we couldn't have IDs a la
> org-id.el for everything?
> It seem to me that it would be useful to use something like `#+ID` in
> place of `#+NAME` for tables, blocks, etc. as well as headlines.
> Would this go against the intended design of org-id.el, or is this a
> change that would be welcome but that no one has gotten around to
> implementing yet?
>
> Also, sorry if this is not correct way to go about this; it's my first
> time posting to a mailing list. Let me know if there are some guidelines or
> something somewhere that I should read and make use of.
>
> All the best,
> Tor
>
>

Feature request: IDs for everything

[Tor Erlend Fjelde]

Hi all,

I was wondering if there's a reason why we couldn't have IDs a la org-id.el for 
everything?
It seem to me that it would be useful to use something like `#+ID` in place of 
`#+NAME` for tables, blocks, etc. as well as headlines.
Would this go against the intended design of org-id.el, or is this a change 
that would be welcome but that no one has gotten around to implementing yet?

Also, sorry if this is not correct way to go about this; it's my first time 
posting to a mailing list. Let me know if there are some guidelines or 
something somewhere that I should read and make use of.

All the best,
Tor

Re: [BUG] Feature request: Add group checks for manual tag setting (not just fast tags) [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> ...
> In case of the default settings (org-use-fast-tag-selection = auto), the
> interface is different - prompt will list all the tags already present
> in the heading:
> ...
> In the above scenario, there is no non-ambiguous way to know which
> exclusive tag is implied by the user. So, I am inclined to keep the
> current behavior. Unless there are better ideas.

I am thus closing this bug, as partially addressed.
Fixed.

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

Re: [BUG] Feature request: Add group checks for manual tag setting (not just fast tags) [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

sreenivas sumadithya  writes:

> Currently, tag groups/ mutually exclusive tags can be set when tags are set
> manually (without shortcuts being assigned to the tags / fast tags). Need
> the behavior seen in fast tags in manual tagging for tag groups.
>
> Reproduction:
> - Create an org file
> - "#+tags: {dog cat} mat"
> - Save the file after setting this.
> - Close buffer
> - Open file
> - Make a heading
> - C-c C-q dog
> - C-c C-q cat
>
> Result:
> - Both 'cat' and 'dog' are assigned to the heading.
>
> Desired behavior:
> - One of the tags should be replaced by the other.

I can only follow the described recipe when setting
org-use-fast-tag-selection to non-standard value of t.

For such scenario, I just pushed a fix onto main - entering group tags
from exclusive groups will now clear already applied tags from the same
group.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=edcb8eca5

In case of the default settings (org-use-fast-tag-selection = auto), the
interface is different - prompt will list all the tags already present
in the heading:

- C-c C-q dog from the recipe will look like

  TAGS: 
  TAGS: dog
  * heading :dog:

- Another C-c C-q will, however, yield
  TAGS: :dog:
  entering "cat" manually
  TAGS: :dog:cat
  will still force setting both the tags:
  * heading :dog:cat:

In the above scenario, there is no non-ambiguous way to know which
exclusive tag is implied by the user. So, I am inclined to keep the
current behavior. Unless there are better ideas.

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

[BUG] Feature request: Add group checks for manual tag setting (not just fast tags) [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[sreenivas sumadithya]

Currently, tag groups/ mutually exclusive tags can be set when tags are set
manually (without shortcuts being assigned to the tags / fast tags). Need
the behavior seen in fast tags in manual tagging for tag groups.

Reproduction:
- Create an org file
- "#+tags: {dog cat} mat"
- Save the file after setting this.
- Close buffer
- Open file
- Make a heading
- C-c C-q dog
- C-c C-q cat

Result:
- Both 'cat' and 'dog' are assigned to the heading.

Desired behavior:
- One of the tags should be replaced by the other.


Emacs  : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8)
Package: Org mode version 9.6.6 (release_9.6.6 @
/usr/share/emacs/29.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-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-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-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)
 org-confirm-shell-link-function 'yes-or-no-p
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 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-persist-directory "/tmp/org-persist-yxcGf7"
 org-fold-core-isearch-open-function 'org-fold--isearch-reveal
 org-persist-before-write-hook '(org-element--cache-persist-before-write)
 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\302 Q \"\207" ["news" browse-url ":"] 6 "\n\n(fn URL ARG)"])
  ("mailto" :follow
#[514 "\301\300\302 Q \"\207" ["mailto" browse-url ":"] 6 "\n\n(fn URL
ARG)"])
  ("https" :follow
#[514 "\301\300\302 Q \"\207" ["https" browse-url ":"] 6 "\n\n(fn URL
ARG)"])
  ("http" :follow
#[514 "\301\300\302 Q \"\207" ["http" browse-url ":"] 6 "\n\n(fn URL ARG)"])
  ("ftp" :follow #[514 "\301\300\302 Q \"\207" ["ftp" browse-url ":"] 6
"\n\n(fn URL ARG)"])
  ("help" :follow org-link--open-help :store org-link--store-help)
  ("file" :complete org-link-complete-file) ("elisp" :follow
org-link--open-elisp))
 org-metaup-hook '(org-babel-load-in-session-maybe)
 )

Re: [FEATURE REQUEST] Introduce support for FILETAGS in the org-set/toggle-tag function. [9.6.6 (release_9.6.6 @ /opt/homebrew/Cellar/emacs-head@30/30.0.50_1/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Tianshu Wang  writes:

> I am seeking this support because when adding Attachments to Org File
> without Headlines, I get a user-error: Before first headline at position
> 1 in buffer filename.org, even if the attachment has been successfully
> added. I hope there are no errors, and the #+FILETAGS of filename.org
> buffer has added `org-attach-auto-tag'. After a simple exploration, I
> found that this requires the support of org-set/toggle-tag to modify
> FILETAGS.

Confirmed.
Steps to reproduce:

1. emacs -Q
2. Open a new Org file
3. C-c C-a c  
4. Get an error "Before first heading ..."

The problem is that `org-attach-attach' tries to set "ATTACH" flag
running `org-set-tags'. And `org-set-tags' does not know how to set file
tags.

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

[FEATURE REQUEST] Introduce support for FILETAGS in the org-set/toggle-tag function. [9.6.6 (release_9.6.6 @ /opt/homebrew/Cellar/emacs-head@30/30.0.50_1/share/emacs/30.0.50/lisp/org/)]

[Tianshu Wang]

I am seeking this support because when adding Attachments to Org File
without Headlines, I get a user-error: Before first headline at position
1 in buffer filename.org, even if the attachment has been successfully
added. I hope there are no errors, and the #+FILETAGS of filename.org
buffer has added `org-attach-auto-tag'. After a simple exploration, I
found that this requires the support of org-set/toggle-tag to modify
FILETAGS.

Emacs  : GNU Emacs 30.0.50 (build 1, aarch64-apple-darwin22.4.0, NS 
appkit-2299.50 Version 13.3.1 (a) (Build 22E772610a))
 of 2023-05-25
Package: Org mode version 9.6.6 (release_9.6.6 @ 
/opt/homebrew/Cellar/emacs-head@30/30.0.50_1/share/emacs/30.0.50/lisp/org/)

--
Tianshu Wang

Re: Feature request: Allow export to convert broken links to plain text

[Berry, Charles]

Ryan,

> On Sep 9, 2023, at 9:13 PM, Ryan C. Thompson  wrote:
> 
> So, this isn't an ideal solution, since it requires me to prefix any 
> potential offending links with "maybe:". But it's good enough for me.
> 

It is good that you have a solution, albeit with the caveat you mention above.

A couple of thoughts:

There is a hook that operates on the copy buffer before parsing viz. 
"org-export-before-parsing-functions is a variable defined in ‘ox.el’." (In 
older versions, it was org-export-before-parsing-hook.) Maybe you can add a 
hook that will add that prefix to all links, so you do not need to put it in 
your working files.

Or you could write an elisp macro that takes two arguments (link, desc) and 
uses them to either construct a link or your preferred substitute if it fails 
validation. 

HTH,

Chuck

Re: Feature request: kill-buffer for org-capture-finalize

[Eduardo Suarez]

On Sun, Sep 10, 2023 at 10:57:46AM +, Ihor Radchenko wrote:
> Then, what you can do is
> 
> (defun my-org-capture-finalize (arg)
> "Like `org-capture-finalize', but kill Org buffer with double prefix arg."
>   (interactive "P")
>   (if (equal arg '(16))
> (save-excursion
>   (org-capture-finalize)
>   (org-capture-goto-last-stored)
>   (kill-buffer))
>(org-capture-finalize arg)))
> (define-key org-capture-mode-map "\C-c\C-c" #'my-org-capture-finalize)

It worked! Thanks a lot for the help.

Re: Feature request: kill-buffer for org-capture-finalize

[Ihor Radchenko]

Eduardo Suarez  writes:

> On Sun, Sep 10, 2023 at 08:19:25AM +, Ihor Radchenko wrote:
>>   (defun my-org-capture-kill-buffer ()
>> (when (equal current-prefix-arg '(16))
>>   (save-excursion
>> (org-capture-goto-last-stored)
>> (kill-buffer
>
> Thanks for the proposed solution. I have tried it and it didn't work for me. 
> Or
> it worked somehow. If it kills the buffer, then the buffer is opened again
> right after it is killed, jumping to the last stored position. I think this is
> because of the way the 'org-capture-finalize' function is implemented:

> ...

Right.

Then, what you can do is

(defun my-org-capture-finalize (arg)
"Like `org-capture-finalize', but kill Org buffer with double prefix arg."
  (interactive "P")
  (if (equal arg '(16))
(save-excursion
  (org-capture-finalize)
  (org-capture-goto-last-stored)
  (kill-buffer))
   (org-capture-finalize arg)))
(define-key org-capture-mode-map "\C-c\C-c" #'my-org-capture-finalize)

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

Re: Feature request: kill-buffer for org-capture-finalize

[Eduardo Suarez]

On Sun, Sep 10, 2023 at 08:19:25AM +, Ihor Radchenko wrote:
>   (defun my-org-capture-kill-buffer ()
> (when (equal current-prefix-arg '(16))
>   (save-excursion
> (org-capture-goto-last-stored)
> (kill-buffer

Thanks for the proposed solution. I have tried it and it didn't work for me. Or
it worked somehow. If it kills the buffer, then the buffer is opened again
right after it is killed, jumping to the last stored position. I think this is
because of the way the 'org-capture-finalize' function is implemented:

...
(cond
 (abort-note
  (cl-case abort-note
(clean
 (message "Capture process aborted and target buffer cleaned up"))
(dirty
 (error "Capture process aborted, but target buffer could not be \
ned up correctly"
 (stay-with-capture  ;;<- this cond is executed
  (org-capture-goto-last-stored)))
...

It seems that the 'org-capture-goto-last-stored' function is called after the
hooks so the buffer is opened again.

This is just my interpretation. I'm not an expert in elisp.

Re: Feature request: kill-buffer for org-capture-finalize

[Ihor Radchenko]

Eduardo Suarez  writes:

> I have tried something simple like
>
>  (defun my-org-capture-kill-buffer ()
>(when (equal current-prefix-arg '(16))
>  (kill-buffer)))
>
> as an after-finalize hook. It seems to recognize the 'current-prefix-arg'
> variable.
>
> However,
>
> 1. it looks to me that org-capture-finalize jumps to the captured item if 
> there
> are any number greater than zero of preffix arguments,
>
> 2. the code above tries to kill the buffer I was working before invoking the
> capture process.
>
> Any hint?

  (defun my-org-capture-kill-buffer ()
(when (equal current-prefix-arg '(16))
  (save-excursion
(org-capture-goto-last-stored)
(kill-buffer

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

Re: Feature request: Allow export to convert broken links to plain text

[Ryan C. Thompson]

On 1/13/19 5:34 PM, Berry, Charles wrote:

Looks like your original idea to revise `org-export-data' might be best.

IIUC, you need to add the link text to the SIGNAL-DATA in each of the places 
where `org-export-resolve-*-link' functions call `signal', then modify 
`org-export-data' to ignore the addition for `mark' and add it back for your 
new `mark-with-text' option.

HTH,

Chuck


Years later, I became annoyed enough by this to attempt to fix it again. 
Unfortunately, I looked into changing all the functions that signal 
org-link-broken, and not all of them can be modified in the way you 
described, at least not easily. Instead, I came up with a fairly clean 
alternative solution: define a new link type "maybe" using 
org-link-set-parameters with an :export function that pulls out the real 
link transcoder from the backend and calls it, but then implements my 
desired behavior if that transcoder throws an error. This allows you to 
prefix any link's path with "maybe:" to have it magically become plain 
text if it can't be resolved during export. Here's the implementation:



(org-link-set-parameters
 "maybe"
 :follow
 (lambda (path prefix)
   (condition-case err
   (org-link-open-from-string (format "[[%s]]" path))
 (error (message "Failed to open maybe link %S" path
 ;; This must be a lambda so it is self-contained
 :export
 (lambda (path desc backend  info)
   (when (symbolp backend)
 (setq backend (org-export-get-backend backend)))
   ;; Generate the non-maybe version of the link, and call the
   ;; backend's appropriate transcoder on it, but catch any error
   ;; thrown and just replace the link with its text instead.
   (let* ((real-link
   (with-temp-buffer
     (save-excursion (insert "[[" path "][" desc "]]"))
     (org-element-link-parser)))
  (real-link-transcoder (cdr (assoc 'link 
(org-export-get-all-transcoders backend)

 (condition-case err
 (funcall real-link-transcoder real-link desc info)
   (error
    (message "Skipping error during maybe link transcoding: %S" err)
    (or desc path))


Using the above code, the following org file can be successfully 
exported to HTML, with the broken/invalid links converted to just plain 
text.



* First heading
:PROPERTIES:
:CUSTOM_ID: heading1
:END:
- [[maybe:maybe:maybe:https://google.com][Maybe google]]
- [[maybe:#heading1][Link to first heading]]
- [[maybe:#heading2][Link to second heading]]
- [[maybe:#heading3][Link to third(?) heading]]
- [[maybe:blarg:notalink][This is an invalid link]]
* Second heading
:PROPERTIES:
:CUSTOM_ID: heading2
:END:


So, this isn't an ideal solution, since it requires me to prefix any 
potential offending links with "maybe:". But it's good enough for me.



Regards,

Ryan

Re: Feature request: kill-buffer for org-capture-finalize

[Eduardo Suarez]

On Sat, Sep 09, 2023 at 09:18:27AM +, Ihor Radchenko wrote:
> For personal use-case, you can utilize
> `org-capture-after-finalize-hook', checking `current-prefix-arg' and
> killing the target org buffer according to the prefix argument passed.
> Then, for example, you can make C-u C-u C-c C-c unconditionally kill the
> target org buffer.

I have tried something simple like

 (defun my-org-capture-kill-buffer ()
   (when (equal current-prefix-arg '(16))
 (kill-buffer)))

as an after-finalize hook. It seems to recognize the 'current-prefix-arg'
variable.

However,

1. it looks to me that org-capture-finalize jumps to the captured item if there
are any number greater than zero of preffix arguments,

2. the code above tries to kill the buffer I was working before invoking the
capture process.

Any hint?

Re: Feature request: kill-buffer for org-capture-finalize

[Ihor Radchenko]

Eduardo Suarez-Santana  writes:

>> Or do you mean that you sometimes want to kill the target org buffer and
>> sometimes not?
>
> Yes, I mean that I sometimes want to kill the target org buffer and sometimes
> not. I don't want to kill the target buffer as the default behavior of my
> capture template.

I see what you want.
I am not sure if it is something commonly needed.

Unless more people are interested, I do not find this feature as useful
for inclusion to Org mode.

For personal use-case, you can utilize
`org-capture-after-finalize-hook', checking `current-prefix-arg' and
killing the target org buffer according to the prefix argument passed.
Then, for example, you can make C-u C-u C-c C-c unconditionally kill the
target org buffer.

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

Re: Feature request: kill-buffer for org-capture-finalize

[Eduardo Suarez-Santana]

On Fri, Sep 08, 2023 at 12:38:07PM +, Ihor Radchenko wrote:
> Did you consider :kill-buffer property in `org-capture-templates'?
> 
>  :kill-bufferIf the target file was not yet visited by a buffer when
>  capture was invoked, kill the buffer again after capture
>  is finalized.
> 
> Or do you mean that you sometimes want to kill the target org buffer and
> sometimes not?

Yes, I mean that I sometimes want to kill the target org buffer and sometimes
not. I don't want to kill the target buffer as the default behavior of my
capture template.

Re: Feature request: kill-buffer for org-capture-finalize

[Ihor Radchenko]

Eduardo Suarez-Santana  writes:

>> May you explain a bit more about the problem you are trying to solve?
>> Isn't the temporary capture buffer killed after capture already?
>> Or do you refer to the org buffer where the capture is recorded?
>
> Sorry about that. I refer to the org buffer where the capture is recorded. I
> meant:
>
> "This would be useful to avoid having to kill the target buffer manually."
>
> I like to keep the target buffer open after the capture is finalized so I can
> review the changes later, but sometimes I'd rather prefer to kill it because I
> already assume that the changes are correct. This helps to keep the buffer 
> list
> clean.

Did you consider :kill-buffer property in `org-capture-templates'?

 :kill-bufferIf the target file was not yet visited by a buffer when
 capture was invoked, kill the buffer again after capture
 is finalized.

Or do you mean that you sometimes want to kill the target org buffer and
sometimes not?

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

Re: Feature request: kill-buffer for org-capture-finalize

[Eduardo Suarez-Santana]

On Fri, Sep 08, 2023 at 12:10:23PM +, Ihor Radchenko wrote:
> Eduardo Suarez  writes:
> 
> > The function org-capture-finalize allows an argument to 'jump-to-capture'. I
> > think it may be a good idea to add a new argument to 'kill-buffer' after the
> > capture is finalized. This would be useful to avoid having to kill the 
> > capture
> > buffer manually. I assume that if ':kill-buffer' is intended as the default
> > behavior, then it would be better to set it in the capture template.
> 
> May you explain a bit more about the problem you are trying to solve?
> Isn't the temporary capture buffer killed after capture already?
> Or do you refer to the org buffer where the capture is recorded?

Sorry about that. I refer to the org buffer where the capture is recorded. I
meant:

"This would be useful to avoid having to kill the target buffer manually."

I like to keep the target buffer open after the capture is finalized so I can
review the changes later, but sometimes I'd rather prefer to kill it because I
already assume that the changes are correct. This helps to keep the buffer list
clean.

Re: Feature request: kill-buffer for org-capture-finalize

[Ihor Radchenko]

Eduardo Suarez  writes:

> The function org-capture-finalize allows an argument to 'jump-to-capture'. I
> think it may be a good idea to add a new argument to 'kill-buffer' after the
> capture is finalized. This would be useful to avoid having to kill the capture
> buffer manually. I assume that if ':kill-buffer' is intended as the default
> behavior, then it would be better to set it in the capture template.

May you explain a bit more about the problem you are trying to solve?
Isn't the temporary capture buffer killed after capture already?
Or do you refer to the org buffer where the capture is recorded?

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

Feature request: kill-buffer for org-capture-finalize

[Eduardo Suarez]

This is a feature request.

The function org-capture-finalize allows an argument to 'jump-to-capture'. I
think it may be a good idea to add a new argument to 'kill-buffer' after the
capture is finalized. This would be useful to avoid having to kill the capture
buffer manually. I assume that if ':kill-buffer' is intended as the default
behavior, then it would be better to set it in the capture template.

I mean something like 'C-u C-u C-c C-c'.

I can't think now of a better way to do it. Any idea is welcome.

Thanks for your work.

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

[Ihor Radchenko]

"M. Pger"  writes:

> I understand better, thanks. Would be a good opportunity for me to (try to) 
> contribute; this weekend I will check carefully the link you've sent. I'll 
> keep you posted, your assistance would be more than welcome :)

It has been a month since the last message in this thread.
If you encountered any difficulties and need help understanding the
code, please let us know.

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

Re: [BUG] feature request: make org-num-mode not count headings that are COMMENTs or have an :ignore: tag [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ilja Kocken]

Ah thanks for the info, I messed up by only looking at C-h f org-num-mode,
and not looking at customize-group. Thank you :)

On Mon, Jul 17, 2023 at 2:35 AM Ihor Radchenko  wrote:

> Ilja Kocken  writes:
>
> > If I have a large org-file with many headings, sometimes it's useful to
> > refer to the heading number that people have commented on in the
> > exported PDF (e.g. for an academic paper). However, when I turn on
> > org-num-mode, this shows a continuous numbering for all the headlines in
> > the file. I have many headings that are not included in my LaTeX export
> > for one reason or another, so the heading numbers don't match.
> >
> > Ideally org-num-mode would not add a number to headings with:
> > * COMMENT heading
> > * heading :nolatex:
> >
> > and perhaps based on whether the ox-extras ignore-headlines is activated
> or not:
> > * heading :ignore:
>
> See `org-num-skip-commented', `org-num-skip-tags', and generally "Org
> Num" staff in M-x customize-group  org-appearance 
>
> Canceled.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <
> https://urldefense.com/v3/__https://orgmode.org/__;!!PvDODwlR4mBZyAb0!XEeAiUVhr0Q9RZmWhARjn77YA5CoMvWp_0cdCN4SZSoWWIvwkhcnL3pWm-LatsWrvi7bI-dium_rKat5o4k$
> >.
> Support Org development at <
> https://urldefense.com/v3/__https://liberapay.com/org-mode__;!!PvDODwlR4mBZyAb0!XEeAiUVhr0Q9RZmWhARjn77YA5CoMvWp_0cdCN4SZSoWWIvwkhcnL3pWm-LatsWrvi7bI-dium_rRQ4SYCU$
> >,
> or support my work at <
> https://urldefense.com/v3/__https://liberapay.com/yantar92__;!!PvDODwlR4mBZyAb0!XEeAiUVhr0Q9RZmWhARjn77YA5CoMvWp_0cdCN4SZSoWWIvwkhcnL3pWm-LatsWrvi7bI-dium_rXK24r_s$
> >
>

Re: [BUG] feature request: make org-num-mode not count headings that are COMMENTs or have an :ignore: tag [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Ilja Kocken  writes:

> If I have a large org-file with many headings, sometimes it's useful to
> refer to the heading number that people have commented on in the
> exported PDF (e.g. for an academic paper). However, when I turn on
> org-num-mode, this shows a continuous numbering for all the headlines in
> the file. I have many headings that are not included in my LaTeX export
> for one reason or another, so the heading numbers don't match.
>
> Ideally org-num-mode would not add a number to headings with:
> * COMMENT heading
> * heading :nolatex:
>
> and perhaps based on whether the ox-extras ignore-headlines is activated or 
> not:
> * heading :ignore:

See `org-num-skip-commented', `org-num-skip-tags', and generally "Org
Num" staff in M-x customize-group  org-appearance 

Canceled.

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

[BUG] feature request: make org-num-mode not count headings that are COMMENTs or have an :ignore: tag [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ilja Kocken]

Hi!

If I have a large org-file with many headings, sometimes it's useful to
refer to the heading number that people have commented on in the
exported PDF (e.g. for an academic paper). However, when I turn on
org-num-mode, this shows a continuous numbering for all the headlines in
the file. I have many headings that are not included in my LaTeX export
for one reason or another, so the heading numbers don't match.

Ideally org-num-mode would not add a number to headings with:
* COMMENT heading
* heading :nolatex:

and perhaps based on whether the ox-extras ignore-headlines is activated or not:
* heading :ignore:

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8)
 of 2023-06-05
Package: Org mode version 9.6.6 (release_9.6.6 @
/usr/share/emacs/30.0.50/lisp/org/)


-- 
Dr. Ilja J. Kocken | Postdoc Researcher at SOEST | University of
Hawaii at Mānoa | 1000 Pope Road | MSB 504 | Honolulu, HI 96822, USA

Re: [BUG] feature request: make org-num-mode not count headings that are COMMENTs or have an :ignore: tag [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ilja Kocken]

I think in the above I may have forgotten that at the bottom of [[
https://github.com/japhir/ArchConfigs/blob/master/myinit.org#reset-gc-cons-threshold][my
config]] I had not uncommented the line that sets the gconf-threshold :O


On Thu, Jul 13, 2023 at 3:43 PM Ilja Kocken  wrote:

> Hi!
>
> If I have a large org-file with many headings, sometimes it's useful to
> refer to the heading number that people have commented on in the
> exported PDF (e.g. for an academic paper). However, when I turn on
> org-num-mode, this shows a continuous numbering for all the headlines in
> the file. I have many headings that are not included in my LaTeX export
> for one reason or another, so the heading numbers don't match.
>
> Ideally org-num-mode would not add a number to headings with:
> * COMMENT heading
> * heading :nolatex:
>
> and perhaps based on whether the ox-extras ignore-headlines is activated
> or not:
> * heading :ignore:
>
> Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.38, cairo version 1.17.8)
>  of 2023-06-05
> Package: Org mode version 9.6.6 (release_9.6.6 @
> /usr/share/emacs/30.0.50/lisp/org/)
>
>
> --
> Dr. Ilja J. Kocken | Postdoc Researcher at SOEST | University of
> Hawaii at Mānoa | 1000 Pope Road | MSB 504 | Honolulu, HI 96822, USA
>

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

[M. Pger]

Hi,

I understand better, thanks. Would be a good opportunity for me to (try to) 
contribute; this weekend I will check carefully the link you've sent. I'll keep 
you posted, your assistance would be more than welcome :)

Best,

MP




Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, July 11th, 2023 at 10:14 PM, Ihor Radchenko  
wrote:


> "M. Pger" mp...@protonmail.com writes:
> 
> > Sorry for the possibly silly question, but by '+1', can I understand that 
> > you will implement this feature because you think it is worth it?
> 
> 
> No, it just means that I think that this feature makes sense to be
> implemented. Basically, upvote.
> 
> Whether I am going to implement it myself depends on other users.
> 
> I usually do not put agenda features high in my todo list because
> org-agenda.el is a pain to work with due to obsolete code. But, I will
> re-consider if other people also say that they want this feature.
> 
> [ For context, I currently have 500 feature requests and ideas recorded in
> my notes. And there are also bugs and general maintenance tasks... I have
> to prioritize. ]
> 
> Or maybe someone motivated enough can try to implement it and submit a
> patch (see https://orgmode.org/worg/org-contribute.html). I will then
> provide assistance. (Helping new and returning contributors is certainly
> high in my todo list ;])
> 
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at https://orgmode.org/.
> 
> Support Org development at https://liberapay.com/org-mode,
> 
> or support my work at https://liberapay.com/yantar92

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

[Ihor Radchenko]

"M. Pger"  writes:

> Sorry for the possibly silly question, but by '+1', can I understand that you 
> will implement this feature because you think it is worth it?

No, it just means that I think that this feature makes sense to be
implemented. Basically, upvote.

Whether I am going to implement it myself depends on other users.

I usually do not put agenda features high in my todo list because
org-agenda.el is a pain to work with due to obsolete code. But, I will
re-consider if other people also say that they want this feature.

[ For context, I currently have 500 feature requests and ideas recorded in
my notes. And there are also bugs and general maintenance tasks... I have
to prioritize. ]

Or maybe someone motivated enough can try to implement it and submit a
patch (see https://orgmode.org/worg/org-contribute.html). I will then
provide assistance. (Helping new and returning contributors is certainly
high in my todo list ;])

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

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

[M. Pger]

Hi,

Sorry for the possibly silly question, but by '+1', can I understand that you 
will implement this feature because you think it is worth it?

If this is case, thank you very much; if not, thank you anyway for your work 
with Org-mode!

Note that I was suggesting setting an upper bound, but being able to truncate 
breadcrumbs from both sides would be even nicer^^

Best,

MP

--- Original Message ---
On Tuesday, July 11th, 2023 at 11:30 AM, Ihor Radchenko  
wrote:


> "M. Pger" mp...@protonmail.com writes:
> 
> > Feature request: adjust ~org-agenda-format-item~ to let the user choose the 
> > first level included in breadcrumbs
> 
> 
> +1
> 
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at https://orgmode.org/.
> 
> Support Org development at https://liberapay.com/org-mode,
> 
> or support my work at https://liberapay.com/yantar92

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

[Ihor Radchenko]

"M. Pger"  writes:

> Feature request: adjust ~org-agenda-format-item~ to let the user choose the 
> first level included in breadcrumbs

+1

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

[M. Pger]

Dear All,

Including "%b" in the org agenda prefix formats (org-agenda-prefix-format​) 
allows to display entries' outline paths, which is super useful to get 
project-oriented agenda views/todo-list.

Consider a project 'Foobar Report'. In the agenda view/todo-list, it would look 
like the following:
```
PROJECT Foobar Report
Foobar Report->TODO Task1
Foobar Report->Task1->TODO Subtask1.1
Foobar Report->Task1->TODO Subtask1.2
Foobar Report->TODO Task2
Foobar Report->Task2-> TODO Subtask2.1
Foobar Report->Task2-> TODO Subtask2.2
```

In such a setting, having 'Foobar Report' at the beginning of each line is not 
really useful and can impair readability. To tell Org to only print breadcrumbs 
starting at e.g. level 2 (i.e. skipping the 'Foobar Report' part of the 
breadcrumbs), I followed the first part of 
https://list.orgmode.org/CAGEgU=hgnxj7tsgv6pvdsewfwp_ivwe8wru+uh8hjh_7nnr...@mail.gmail.com/
 and modified the following part of org-agenda-format-item​:
```
(when org-prefix-has-breadcrumbs
(setq breadcrumbs
(org-with-point-at (org-get-at-bol 'org-marker)
(let ((s (org-format-outline-path (org-get-outline-path)
(1- (frame-width))
nil org-agenda-breadcrumbs-separator)))
(if (eq "" s) "" (concat s org-agenda-breadcrumbs-separator))
```
by replacing (org-get-outline-path) with
​```
(nthcdr (1- org-agenda-breadcrumbs-start-level)
(org-get-outline-path))

​```
while setting a custom variable org-agenda-breadcrumbs-start-level​ to 2. It 
works well.

Would the Org devs/active contributors be willing to implement such 
modification (maybe a cleaner version, with a better custom variable name?) in 
the next release of Org?

Best,

MP

PS: Note that I tried to implement the same using advice-add​, but miserably 
failed and decided to go for a complete redefinition of org-agenda-format-item 
(more lines, but less pain).

​

Re: [FEATURE Request] inherit headline directory for `org-attach' in `org-add-note' etc temp buffers

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> I press [C-c C-z] `org-add-note` to add logbook note. It will open a new
> temporary buffer. I want to execute command [C-c C-a m] `org-attach-mv`
> to attach a file. But it will prompt me for org-attach directory. I
> think commands like `org-add-note`, `org-clock` add log, `org-todo`
> change TODO state add log, etc should auto inherit this org-attach
> directory. So that user can do `org-attach` in the temporary log buffer.
>
> WDYT?

Makes sense, but `org-add-log-note` implementation is not great. We
should ideally re-use capture, which will give the right context without
extra efforts.

Patches welcome!

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

[FEATURE Request] inherit headline directory for `org-attach' in `org-add-note' etc temp buffers

[Christopher M. Miles]

For example, I have Org content like this:

#+begin_src org
,* TODO Refrigerator
DEADLINE: <2023-04-06 Thu>
:PROPERTIES:
:ID:   e1824d15-35cb-4105-a617-5f7ecd6a1049
:END:
#+end_src

I press [C-c C-z] `org-add-note` to add logbook note. It will open a new
temporary buffer. I want to execute command [C-c C-a m] `org-attach-mv`
to attach a file. But it will prompt me for org-attach directory. I
think commands like `org-add-note`, `org-clock` add log, `org-todo`
change TODO state add log, etc should auto inherit this org-attach
directory. So that user can do `org-attach` in the temporary log buffer.

WDYT?

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: Feature request: Allow export to convert broken links to plain text

[Ihor Radchenko]

Janek Fischer  writes:

> I am looking for exactly the feature in 
> https://lists.gnu.org/r/emacs-orgmode/2019-01/msg00203.html:
> I have a note with many links, but would like to export that note as landing 
> page as text stripped of links.
>
> Has there been any progress in the last 4 years on this,
> or any hint on how to get this now?

For example, you can make all the code throwing 'org-link-broken return
a list of (PATH LINK) instead of just PATH. Then, `org-export-data' and
`org-export-with-broken-links' may be modified to optionally do
something with the LINK object itself.

Patches welcome!

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

Re: Feature request: Allow export to convert broken links to plain text

[Hanno Perrey]

Hej Janek,

> I have a note with many links, but would like to export that note as
> landing page as text stripped of links.

I have had a similar need recently where I wanted to export a document
filled with inks to org-roam nodes and other org headlines via id links.
I was able to strip the links on export for just this type while
preserving other link types:

#+begin_src emacs-lisp
(defun my-link-remover (link contents info) contents)
(org-link-set-parameters "id" :export 'my-link-remover)
#+end_src

This could of course be extended to actually check the link and only
remove it if it points to nowhere.

Hope this points you in a useful direction!

Best wishes,

Hanno



--
Hanno Perrey
https://hoowl.se

Feature request: Allow export to convert broken links to plain text

[Janek Fischer]

I am looking for exactly the feature in 
https://lists.gnu.org/r/emacs-orgmode/2019-01/msg00203.html:
I have a note with many links, but would like to export that note as landing 
page as text stripped of links.

Has there been any progress in the last 4 years on this,
or any hint on how to get this now?

Regards
Janek

---
CTO https://forensicdiscovery.de and https://software-challenge.deSoftware 
Engineering Student @ https://code.berlin

Re: [RFC] Limit inline image width by default (was: feature request: easy embedding of images)

[Ihor Radchenko]

Ihor Radchenko  writes:

> But we can try to improve the defaults for wide images.
>
> See the tentative patch.
>
> From 180e322c2c79ea88d87f908299a5c0e69c47a7b2 Mon Sep 17 00:00:00 2001
> Message-Id: 
> <180e322c2c79ea88d87f908299a5c0e69c47a7b2.1679581960.git.yanta...@posteo.net>
> From: Ihor Radchenko 
> Date: Thu, 23 Mar 2023 15:31:33 +0100
> Subject: [PATCH] lisp/org.el: Allow limiting inline image width

Applied, onto main. Fixing the spotted typo and replacing
`pixel-fill-width' with `frame-char-width' that is available in Emacs
26.

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

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

Re: [RFC] Limit inline image width by default (was: feature request: easy embedding of images)

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> See the tentative patch.

This looks fantastic!  +1 for using the Fill Column by default.

Rudy
-- 
"The introduction of suitable abstractions is our only mental aid to
organize and master complexity."
-- Edsger Wybe Dijkstra, 1930-2002

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: feature request: easy embedding of images

[Ihor Radchenko]

Alexis Gallagher  writes:

>   •   you can still scroll the window one line height unit at a time, 
> without the entire image being scrolled as if it were one giant line, 
> breaking scrolling, as seems to happen on my emacs (version 28.x on Linux)

Emacs will actually scroll partially when the image is taller than
window height. But not otherwise.
Changing this is not trivial.
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62048#17

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

Re: [RFC] Limit inline image width by default (was: feature request: easy embedding of images)

[Christopher M. Miles]

This is an acceptable solution for large width image. I propose this RFC too.

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: [RFC] Limit inline image width by default (was: feature request: easy embedding of images)

[General discussions about Org-mode.]

Small nit, in case you are about to install it.

> +It the actual width is too wide, limit it according to
> +~org-image-max-width~.

"It" -> "If".

--
Best,


RY

[RFC] Limit inline image width by default (was: feature request: easy embedding of images)

[Ihor Radchenko]

Alexis Gallagher  writes:

>   •   the image is automatically resized to maintain aspect ratio and 
> fit horizontally with a civilized margin, so that I can resize my emacs 
> window without the image disappearing or swamping the other content. 

We cannot automatically resize images in Elisp. At least, I know no good
way to do it reliably.

But we can try to improve the defaults for wide images.

See the tentative patch.

>From 180e322c2c79ea88d87f908299a5c0e69c47a7b2 Mon Sep 17 00:00:00 2001
Message-Id: <180e322c2c79ea88d87f908299a5c0e69c47a7b2.1679581960.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Thu, 23 Mar 2023 15:31:33 +0100
Subject: [PATCH] lisp/org.el: Allow limiting inline image width

* lisp/org.el (org-image-max-width): New custom variable controlling
max inline image width.
(org--create-inline-image): Use the new variable.
* doc/org-manual.org (Images):
* etc/ORG-NEWS (New customization ~org-image-max-width~ limiting the
displayed inline image width): Document the new variable.
---
 doc/org-manual.org | 20 +---
 etc/ORG-NEWS   | 15 +++
 lisp/org.el| 29 -
 3 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 37fd3df14..3d729bdf6 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11495,14 +11495,19 @@ ** Images
 
 
   #+vindex: org-image-actual-width
+  #+vindex: org-image-max-width
   #+cindex: @samp{ORG-IMAGE-ACTUAL-WIDTH}, property
   By default, Org mode displays inline images according to their
-  actual width.  You can customize the displayed image width using
+  actual width, but no wider than ~fill-column~ characters.
+
+  You can customize the displayed image width using
   ~org-image-actual-width~ variable (globally) or
   =ORG-IMAGE-ACTUAL-WIDTH= property (subtree-level)[fn:: The width can
   be customized in Emacs >= 24.1, built with imagemagick support.].
   Their value can be the following:
   - (default) Non-nil, use the actual width of images when inlining them.
+It the actual width is too wide, limit it according to
+~org-image-max-width~.
   - When set to a number, use imagemagick (when available) to set the
 image's width to this value.
   - When set to a number in a list, try to get the width from any
@@ -11512,8 +11517,17 @@ ** Images
 #+end_example
 and fall back on that number if none is found.
   - When set to nil, try to get the width from an =#+ATTR.*= keyword
-and fall back on the original width if none is found.
-
+and fall back on the original width or ~org-image-max-width~ if
+none is found.
+
+  ~org-image-max-width~ limits the maximum displayed image width, but
+  only when the image width is not set explicitly.  Possible maximum
+  width can be set to:
+  - (default) ~fill-column~, limit width to ~fill-column~ number of
+characters.
+  - ~window~, limit width to current window width.
+  - integer number, limit width that specified number of pixels.
+  - nil, do not limit the width.
 
 #+vindex: org-cycle-inline-images-display
 Inline images can also be displayed when cycling the folding state.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 4d45e6507..2611cc570 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -24,6 +24,21 @@ consider [[https://gitlab.com/jackkamm/ob-python-mode-mode][ob-python-mode-mode]
 has been ported to.
 
 ** New and changed options
+*** New customization ~org-image-max-width~ limiting the displayed inline image width
+
+New custom variable ~org-image-max-width~ limits the maximum inline
+image width, but only when the inline image width is not explicitly
+set via ~org-image-actual-width~, =ORG-IMAGE-ACTUAL-WIDTH= property,
+or =#+ATTR*= keyword.
+
+By default, when ~org-image-actual-width~ is set to t,
+~org-image-max-width~ takes effect.  Its default value is set to
+~fill-column~, limiting the image previews to ~fill-column~ number of
+characters.
+
+To fall back to previous defaults, where the inline image width is not
+constrained, set ~org-image-max-width~ to nil.
+
 *** New ~org-cite-natbib-export-bibliography~ option defining fallback bibliography style
 
 ~natbib~ citation export processor now uses
diff --git a/lisp/org.el b/lisp/org.el
index 20e6ea6d9..43d659536 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15096,6 +15096,24 @@ (defcustom org-image-actual-width t
 	  (list :tag "Use #+ATTR* or a number of pixels" (integer))
 	  (const :tag "Use #+ATTR* or don't resize" nil)))
 
+(defcustom org-image-max-width 'fill-column
+  "When non-nil, limit the displayed image width.
+This setting only takes effect when `org-image-actual-width' is set to
+t or when #+ATTR* is set to t.
+
+Possible values:
+- `fill-column' :: limit width to `fill-column'
+- `window'  :: limit width to window width
+- number:: limit width to number in pixels
+- nil :: do not limit image width"
+  :group 'org-appearance
+  :package-version '(Org . "9.7")

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:

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.


RFC-5545 specifies a machine readable format. Org files are for humans 
even in raw text format. Decisions suitable for iCalendar are not always 
applicable for Org.


The timestamp in the examples follows ISO-8601 and I have no idea why it 
is confusing.


Offsets for RFC5545 means
- More code for parsing (negligible amount though)
- Due to wide spread confusions, an implementer may pretend that 
timezones are supported just because offsets are saved despite missed 
IANA TZ ID.


In respect to Org offsets and time zone identifiers are discussed in 
this thread in details. As a format for humans it should be more 
permissible and convenient for direct typing. There is no reason to 
insist on UTC where timestamps with fixed offsets are equally valid.

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:

> Where you Ihor responded with this message:
> https://lists.gnu.org/archive/html/emacs-orgmode/2023-02/msg00018.html
>
>> [2022-11-12 14:00 @UTC+2]
>> [2022-11-12 14:00 @UTC-2:30]
>
>> are also fine within the proposed format.
>
> I am not sure what did you intend to show, did you intend to tell
> that:
>
> - 2022-11-12 14:00 @UTC+2 means 2022-11-12 12:00 @UTC ?
>
> In my understanding "@UTC" means "UTC time zone". From above first
> examples it is very confusing to use "UTC" as designation plus
> positive or negative prefix.
>
> It is not common to represent it that way. As if there is any
> designation for UTC, like "UTC" or "@UTC" or "Z", then there is no
> prefix shown, or if any, there will be zero.
>
> And I said, representing time that way by mixing word "UTC" with
> prefix would be confusing, as that practically creates new type of
> time representation that is not ordinarily used.

I mostly wanted to refer to TZ POSIX variable format, which allows
"ABBREVIATION+OFFSET" format. "UTC" is actually ignored there.

Further discussion revealed that UTC+2 is, in fact, even confusing. For
you and also because POSIX uses reversed symbol convention with +2 in TZ
referring to "time 2 hours __before__ UTC time".

@UTC+2 is not something we will recommend. It will be technically
POSIX-complaint, just as @BLAH-1 would be. Either one does not make
much sense.

-- 
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:

> Discussion started from something like this:
>
> 2022-11-12 12:00+02 @UTC
>
> and that is different case, where Ihor was suggesting that: 2022-11-12
> 12:00 is UTC time, not local time, where by +02 is offset (I say not
> UTC offset) to be added or deducted on that time.

No, I did not mean that. It looks like the main reason why we
misunderstand each other.

I also do not recall providing such example.

-- 
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)

[Jean Louis]

* Ihor Radchenko  [2023-03-08 16:29]:
> > The UTC offset is property of the time zone. The future time zone
> > definition will know what is it's UTC offset.
> 
> UTC offset is indeed a property of the time zone.
> However, UTC offset may be a subject of change in some time zones.

Yes, and that is what I was stating. What we were arguing about is
rather notation.

> I am referring to "fixed" offsets to be specified by users and will
> never change. 

"Fixed" offset is IMHO wrong designation. What you want to say is "UTC
time". Don't use any offsets with UTC time as not to confuse
people. Use local time representation of UTC timestamps. For UTC
timestamp there is no problem to be in future or in past.

> These offsets are convenient to protect timestamp from regulatory
> changes in time zones.

UTC time is convenient.

But if you intend to represent time with time stamps, fixing some "UTC
offsets" to get "UTC time" representation, I do not see how it is
convenient for anybody.

> Effectively, they are simply another, sometimes convenient, way to
> represent UTC time.

Just use UTC time to tell what "fixed" time, and do not use "UTC
offsets" as they are by convention changeable.

> Consider that you need to put a timestamp exactly 1 year from now, even
> if time zone rules change. You are in +04 time zone at
> [2023-03-08 14:00 @Asia/Istanbul].

No matter in which time zone I am, one year from now depends on how
year is calculated

If current timestamp at UTC time is:
2023-03-10 01:08:07
then one year from now is:
2024-03-10 01:08:07

> You can write [2024-03-08 11:00 @Z] or you can write
> [2024-03-08 14:00 @+03]. The latter is nothing but former, written
> without a need to mentally convert back to UTC from your current wall
> clock.

I understand and I do not agree to that notation for reason that it is
confusing, but you please do how you wish.

UTC offset is shown to user in many applications depending on user's
time zone, while time that is fixed is static designation.

I would agree to such notation only if UTC time is written in Org
file, but you provide representation of UTC time showing the UTC
offset.

I see now use of providing "UTC time" with "UTC offset" as that is
beyond conventions.

Then we are speaking out of the reality of what people agreed on this
planet, and people agreed not to use any offsets with UTC time. It is
either UTC time without offset or offset zero, or no offset at all.

But of course Org can be the playground to do what one wish and want.

> > You can introduce something new in Org and say "This is fixed UTC
> > offset in time zone @ABC" but that way you are confusing yourself and
> > future programmer and users, as it does not comply to already accepted
> > international standards.
> >
> > iCalendar proposes different way of representation of time in future,haw
> > that is, it could be UTC time in future, or it could be date, time and
> > time zone. Using UTC offset for future is redundant, as in present
> > time when you are writing future time stamp, you cannot know the
> > future UTC offset.
> 
> iCalendar provides just two options: time zone name and UTC. It is ok
> when the timestamps are written programmatically, but not ok when the
> format should be writable by humans manually. I do not see why we should
> force the users to convert to UTC manually in the above scenario.

While I cannot see the context of the above statement, I have never
had any idea of letting user convert some timestamps manually, that is
why computers are there to provide timestamps. I don't do that manually.

> >> 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.
> >
> > How about finding reasons why iCalendar specifies it that way?
> >
> > And then deciding if those reasons, not specification literally,
> > should be followed?
> 
> Feel free to share the underlying logic if you are aware about it.

Which indicates you did not do the homework.

> >> > 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?
> >
> > The sign "!" is telling "use time, not offset as authoritative". I do
> > not say you should implement it this way, but I am saying it is wrong
> > putting both the time and offset for future time, while you will not
> > know the future offset with certainty.
> 
> Ok. I see the problem you referred to. We should then better stick to
> the TEC's proposal here:
> 
> ┌
> │ [2022-11-12 12:00 @+07,Asia/Singapore]  # warn when mismatch
> │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07
> │ [2022-11-12 

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:

>> > 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.
>
> Your answer is not related any more to @UTC time you were mentioning
> as now you are using "familiar time zone". I said, there is no offset
> representation with UTC time but +00. But it can be with other time
> zones.
>
> However, when you say "fix the offset for future" that does not
> work. If you do specify time zone, you are fixing it by time zone, and
> not by UTC offset, because it is less likely that the time zone
> definition changes, but UTC offset can change easier.
>
> The UTC offset is property of the time zone. The future time zone
> definition will know what is it's UTC offset.

UTC offset is indeed a property of the time zone.
However, UTC offset may be a subject of change in some time zones.
I am referring to "fixed" offsets to be specified by users and will
never change. These offsets are convenient to protect timestamp from
regulatory changes in time zones. Effectively, they are simply another,
sometimes convenient, way to represent UTC time.

Consider that you need to put a timestamp exactly 1 year from now, even
if time zone rules change. You are in +04 time zone at
[2023-03-08 14:00 @Asia/Istanbul].

You can write [2024-03-08 11:00 @Z] or you can write
[2024-03-08 14:00 @+03]. The latter is nothing but former, written
without a need to mentally convert back to UTC from your current wall
clock.

> You can introduce something new in Org and say "This is fixed UTC
> offset in time zone @ABC" but that way you are confusing yourself and
> future programmer and users, as it does not comply to already accepted
> international standards.
>
> iCalendar proposes different way of representation of time in future,haw
> that is, it could be UTC time in future, or it could be date, time and
> time zone. Using UTC offset for future is redundant, as in present
> time when you are writing future time stamp, you cannot know the
> future UTC offset.

iCalendar provides just two options: time zone name and UTC. It is ok
when the timestamps are written programmatically, but not ok when the
format should be writable by humans manually. I do not see why we should
force the users to convert to UTC manually in the above scenario.

>> 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.
>
> How about finding reasons why iCalendar specifies it that way?
>
> And then deciding if those reasons, not specification literally,
> should be followed?

Feel free to share the underlying logic if you are aware about it.
 
>> 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/
>
> ...
> Conclusion is that your reference is only partially relevant, as you
> may use it as guide for past timestamps, but not as guide for future
> time representation.

The cited document explicitly talks about timestamps in future. See 3.4.
Inconsistent time-offset/Time-Zone Information

> In my opinion people should be given the extended timestamp function
> in Org where they may choose the time zone.
>
> - no C-u prefix, interactive selection: <2023-02-12 Sun>
>
> - with C-u prefix, interactive, with time: <2023-02-12 Sun 11:09>
>
> - with double, C-u C-u, prefix, non-interactive with time: <2023-02-12 Sun 
> 11:10>
>
> - but then I do not know what with 3 times C-u, some of those prefixes
>   could be used to let user choose the time zone

Sure, though I had a slightly different interface in mind. In any case,
it is too early to talk about interfaces. Let's finalize the syntax
first.

>> > 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?
>
> The sign "!" is telling "use time, not offset as authoritative". I do
> not say you should implement it this way, but I am saying it is wrong
> putting both the time and offset for future time, while you will not
> know the future offset with certainty.

Ok. I see the problem you referred to. We should then better stick to
the TEC's proposal here:

┌
│ [2022-11-12 12:00 @+07,Asia/Singapore]  # warn when mismatch
│ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07
│ [2022-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore
└

Re: [SOLVED] Re: [FEATURE request] hope `org-agenda-custom-commands` can support propertiezed-text.

[General discussions about Org-mode.]

stardiviner  writes:

> [...]
>>  Does `("c" ,(format ...) ...) work?
>
> This macro-style expanded string works. I'm curious why have to be expanded?

The reason is that org does not expect to run arbitrary sexp (in your
case, the (format ...) expression); instead with the backtick and
unquote, you are passing in a propertized string to org, which org can
understand and make use of.

--
Best,


RY

[SOLVED] Re: [FEATURE request] hope `org-agenda-custom-commands` can support propertiezed-text.

[stardiviner]

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/


On Tue, Mar 7, 2023 at 9:59 PM Ihor Radchenko  wrote:

> stardiviner  writes:
>
> > But I can't do similar in `org-agenda-custom-commands` description part
> > like this:
> > ```elisp
> > (add-to-list
> >'org-agenda-custom-commands
> >'("c" (format "%s Today [c]locked tasks." (all-the-icons-faicon
> > "hourglass-start"))
> >  ((agenda ""
> >   ((org-agenda-ndays 1)
> >(org-agenda-span-1)
> >(org-agenda-use-time-grid t)
> >(org-agenda-include-diary nil)
> >(org-agenda-show-log (quote clockcheck))
> >(org-agenda-clockreport t))
> > ```
> > This upper code will report error.
>
> Does `("c" ,(format ...) ...) work?
>
>
This macro-style expanded string works. I'm curious why have to be expanded?



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

Re: [FEATURE request] hope `org-agenda-custom-commands` can support propertiezed-text.

[Ihor Radchenko]

stardiviner  writes:

> But I can't do similar in `org-agenda-custom-commands` description part
> like this:
> ```elisp
> (add-to-list
>'org-agenda-custom-commands
>'("c" (format "%s Today [c]locked tasks." (all-the-icons-faicon
> "hourglass-start"))
>  ((agenda ""
>   ((org-agenda-ndays 1)
>(org-agenda-span-1)
>(org-agenda-use-time-grid t)
>(org-agenda-include-diary nil)
>(org-agenda-show-log (quote clockcheck))
>(org-agenda-clockreport t))
> ```
> This upper code will report error.

Does `("c" ,(format ...) ...) work?

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

[FEATURE request] hope `org-agenda-custom-commands` can support propertiezed-text.

[stardiviner]

I want to display text icon using "all-the-icons" package to beautify
org-mode commands interface.

In `org-capture-templates`, I can set description text with propertied text
like this:

```elisp
(setq org-capture-templates
  `(("c" ,(format "%s\tsticky note" (all-the-icons-faicon
"sticky-note-o" :face 'all-the-icons-green :v-adjust 0.01))
 entry (file "")
 ;; select todo keyword interactively from `org-todo-keywords'.
 ;; The `org-todo-keywords-for-agenda' variable is fullfilled with
value AFTER generated Agenda.
 "* %(completing-read \"Todo keyword: \"
org-todo-keywords-for-agenda nil t) %^{Capture} [/] \n:PROPERTIES:\n:TIME:
%U\n:END: \n%i\n%a\n\n%?\n"
 ;; :time-prompt t
 :empty-lines 1 :jump-to-captured t))
```

But I can't do similar in `org-agenda-custom-commands` description part
like this:
```elisp
(add-to-list
   'org-agenda-custom-commands
   '("c" (format "%s Today [c]locked tasks." (all-the-icons-faicon
"hourglass-start"))
 ((agenda ""
  ((org-agenda-ndays 1)
   (org-agenda-span-1)
   (org-agenda-use-time-grid t)
   (org-agenda-include-diary nil)
   (org-agenda-show-log (quote clockcheck))
   (org-agenda-clockreport t))
```
This upper code will report error.

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/

Re: feature request: easy embedding of images

[Daniel Fleischer]

Jude DaShiell [2023-02-20 Mon 16:24] wrote:

> To help accessibility it would be useful when an image was dragged into
> org-mode if the user got prompted for an image description that gets
> associated with the image in org-mode.  Some images are art work and those
> should get alt="" tags if a user fails to provide a description but only
> after asking if this image is art work or something that needs a
> description.  If a description is provided that should go between the
> quotes in the alt="" tag.

In org-download you can specify html attributes for the attached image,
see link

https://github.com/abo-abo/org-download/blob/master/org-download.el#L178-L184

It's not a prompt, it's a template and you can fill the alt description.

-- 
Daniel Fleischer

Re: feature request: easy embedding of images

[Jude DaShiell]

To help accessibility it would be useful when an image was dragged into
org-mode if the user got prompted for an image description that gets
associated with the image in org-mode.  Some images are art work and those
should get alt="" tags if a user fails to provide a description but only
after asking if this image is art work or something that needs a
description.  If a description is provided that should go between the
quotes in the alt="" tag.



Jude  "There are four boxes to be used in
defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Mon, 20 Feb 2023, Russell Adams wrote:

> On Sat, Feb 18, 2023 at 04:22:33PM -0800, Alexis Gallagher wrote:
> > Hello, my fellow org-mode lovers,
> >
> > This is a feature request ? or failing that, a request for advice on
> > a settings configuration which could produce this functionality now.
>
> Have you looked at org-attach-screenshot?
>
> https://github.com/dfeich/org-screenshot
>
> It uses org-attach and calls out to take a screenshot.
>
> I do the same with some local function's I wrote a while ago. It works
> very well for me. I run M-x my/org-screenshot, and after 3 seconds it
> will use Imagemagick's "import" command to allow me to select a region
> to screenshot and saves it to a filename I prepared.
>
> I do this daily, many times each day.
>
> > I wish org-mode had the ability to attach images to notes, display
> > them inline, and have that work well. By ?work well? I mean a few
> > specific things:
> >
> > ?   the image is automatically resized to maintain aspect ratio and
> > ?   fit horizontally with a civilized margin, so that I can resize
> > ?   my emacs window without the image disappearing or swamping the
> > ?   other content.
>
> This is Emacs, not Org. Perhaps someone knows how to adjust that.
>
> > ?   you can still scroll the window one line height unit at a time,
> > ?   without the entire image being scrolled as if it were one giant
> > ?   line, breaking scrolling, as seems to happen on my emacs
> > ?   (version 28.x on Linux)
>
> Mine jumps too, but again that's Emacs, not Org.
>
> > ?   drag and drop, so I can add the image by dragging it in, for
> > ?   instance from a screenshot tool or from an image on a web page.
>
> I can't answer that. Drag and drop functions depend on your
> platform. Does anything else in Emacs use drag and drop?
>
> > ?   sensible defaults for storing the images bundled with notes and
> > ?   keeping the two associated, so that I don't subsequently live in
> > ?   fear of ever moving my org files
>
> I do save all of mine to the same directory as my org file in
> .org/Filename.org.screenshotMMDDHHMMSS.png. It means I can easily
> know what files below to my org document.
>
> > Why is this valuable, to me at least? I use org to take notes all
> > day, during meetings, on reading matter, in the development of my
> > own thoughts. Embedding images would let me collect every kind of
> > resource I can't reproduce by typing or copy and pasting text ?
> > photos of slides during presentations, photos of whiteboard, key
> > snippets from websites, handwritten notes and equations, etc..
>
> Of course it's valuable, and already implemented. I think you're
> asking more about refining how you use it.
>
> --
> Russell Adamsrlad...@adamsinfoserv.com
> https://www.adamsinfoserv.com/
>
>

Re: feature request: easy embedding of images

[Daniel Fleischer]

Alexis Gallagher [2023-02-18 Sat 16:22] wrote:

> This is a feature request — or failing that, a request for advice on a 
> settings configuration which could produce this
> functionality now. 

Russell mentioned a package and pointed to the image issues related to
Emacs, not Org.

I want to suggest the package https://github.com/abo-abo/org-download
which I use all time, for dragging and dropping images and for taking
screeshots. 

-- 
Daniel Fleischer

Re: feature request: easy embedding of images

[Russell Adams]

On Sat, Feb 18, 2023 at 04:22:33PM -0800, Alexis Gallagher wrote:
> Hello, my fellow org-mode lovers,
>
> This is a feature request — or failing that, a request for advice on
> a settings configuration which could produce this functionality now.

Have you looked at org-attach-screenshot?

https://github.com/dfeich/org-screenshot

It uses org-attach and calls out to take a screenshot.

I do the same with some local function's I wrote a while ago. It works
very well for me. I run M-x my/org-screenshot, and after 3 seconds it
will use Imagemagick's "import" command to allow me to select a region
to screenshot and saves it to a filename I prepared.

I do this daily, many times each day.

> I wish org-mode had the ability to attach images to notes, display
> them inline, and have that work well. By “work well” I mean a few
> specific things:
>
>   •   the image is automatically resized to maintain aspect ratio and
>   •   fit horizontally with a civilized margin, so that I can resize
>   •   my emacs window without the image disappearing or swamping the
>   •   other content.

This is Emacs, not Org. Perhaps someone knows how to adjust that.

>   •   you can still scroll the window one line height unit at a time,
>   •   without the entire image being scrolled as if it were one giant
>   •   line, breaking scrolling, as seems to happen on my emacs
>   •   (version 28.x on Linux)

Mine jumps too, but again that's Emacs, not Org.

>   •   drag and drop, so I can add the image by dragging it in, for
>   •   instance from a screenshot tool or from an image on a web page.

I can't answer that. Drag and drop functions depend on your
platform. Does anything else in Emacs use drag and drop?

>   •   sensible defaults for storing the images bundled with notes and
>   •   keeping the two associated, so that I don't subsequently live in
>   •   fear of ever moving my org files

I do save all of mine to the same directory as my org file in
.org/Filename.org.screenshotMMDDHHMMSS.png. It means I can easily
know what files below to my org document.

> Why is this valuable, to me at least? I use org to take notes all
> day, during meetings, on reading matter, in the development of my
> own thoughts. Embedding images would let me collect every kind of
> resource I can't reproduce by typing or copy and pasting text —
> photos of slides during presentations, photos of whiteboard, key
> snippets from websites, handwritten notes and equations, etc..

Of course it's valuable, and already implemented. I think you're
asking more about refining how you use it.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

feature request: easy embedding of images

[Alexis Gallagher]

Hello, my fellow org-mode lovers,

This is a feature request — or failing that, a request for advice on a settings 
configuration which could produce this functionality now. 

I wish org-mode had the ability to attach images to notes, display them inline, 
and have that work well. By “work well” I mean a few specific things:

•   the image is automatically resized to maintain aspect ratio and 
fit horizontally with a civilized margin, so that I can resize my emacs window 
without the image disappearing or swamping the other content. 
•   you can still scroll the window one line height unit at a time, 
without the entire image being scrolled as if it were one giant line, breaking 
scrolling, as seems to happen on my emacs (version 28.x on Linux)
•   drag and drop, so I can add the image by dragging it in, for 
instance from a screenshot tool or from an image on a web page.
•   sensible defaults for storing the images bundled with notes and 
keeping the two associated, so that I don't subsequently live in fear of ever 
moving my org files

Why is this valuable, to me at least? I use org to take notes all day, during 
meetings, on reading matter, in the development of my own thoughts. Embedding 
images would let me collect every kind of resource I can't reproduce by typing 
or copy and pasting text — photos of slides during presentations, photos of 
whiteboard,  key snippets from websites, handwritten notes and equations, etc..

Alexis

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

[Jean Louis]

* Ihor Radchenko  [2023-02-15 18:17]:
> Jean Louis  writes:
> 
> > That is not same case as Ihor, when he designated it as 
> >
> > 2030-02-09 12:00 -0800 @UTC
> > because there are no offsets @UTC time zone.
> 
> I do not recall providing such example. May you point me to the message
> where you saw me writing -0800 @UTC?

Discussion on "@UTC" stated with this message by Christian:
https://lists.gnu.org/archive/html/emacs-orgmode/2023-02/msg00016.html

Theses were examples shown:

>Examples:
>2022-11-12 12:00+02 # 12:00 UTC+2
>2022-11-12 14:00+0230 # 14:00 UTC+2:30
>2022-11-12 14:00-0230 # 14:00 UTC-2:30
>2022-11-12 14:00Z # 14:00 UTC

Those examples are correct but there is comment "#" which was talking
about prefixes, only for understanding.

Examples without comments are:

>2022-11-12 12:00+02
>2022-11-12 14:00+0230 
>2022-11-12 14:00-0230 
>2022-11-12 14:00Z 

As you can see there is "Z" as designation for UTC time. When there is
designation for UTC time, no prefix is mentined.

You may observe that UTC prefixes in those examples are mentioned with
positive or negative prefixes, but there is no designation for "UTC",
as that would become confusing.

Which is what I was speaking about.

Where you Ihor responded with this message:
https://lists.gnu.org/archive/html/emacs-orgmode/2023-02/msg00018.html

> [2022-11-12 14:00 @UTC+2]
> [2022-11-12 14:00 @UTC-2:30]

> are also fine within the proposed format.

I am not sure what did you intend to show, did you intend to tell
that:

- 2022-11-12 14:00 @UTC+2 means 2022-11-12 12:00 @UTC ?

In my understanding "@UTC" means "UTC time zone". From above first
examples it is very confusing to use "UTC" as designation plus
positive or negative prefix.

It is not common to represent it that way. As if there is any
designation for UTC, like "UTC" or "@UTC" or "Z", then there is no
prefix shown, or if any, there will be zero.

And I said, representing time that way by mixing word "UTC" with
prefix would be confusing, as that practically creates new type of
time representation that is not ordinarily used.

-- 
Jean

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

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

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

[Jean Louis]

* Thomas S. Dye  [2023-02-14 19:50]:
> > What Ihor proposed is time stamp like:
> > 
> >  2023-02-14 Tue 12:00:00 +0800 @UTC
> > 
> > Though I just say when we put "UTC" that means normally "UTC time
> > zone" and such has no prefix that is positive or negative, can be
> > zero.
> 
> Sigh.  UTC is not a time zone.

I cannot know what you mean and in which context.

I can tell you to look here:
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

which is the context for computer time, or TZ database time zones,
where you may find Etc/UTC as time zone.

I can tell that in the context of the PostgreSQL database, "UTC" is
time zone, as following works well:

SELECT current_timestamp AT TIME ZONE 'UTC';

  timezone  

 2023-02-16 14:13:37.837977
(1 row)

SELECT CURRENT_TIMESTAMP;

   CURRENT_timestamp   
---
 2023-02-16 17:13:42.709239+03

There are differen time zones' categories:
https://en.wikipedia.org/wiki/Lists_of_time_zones

In military context:
https://en.wikipedia.org/wiki/List_of_military_time_zones

It is called "Zulu Time Zone" or "Z"

Then in this context:
https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations

There is abbreviation "UTC" if you look there.

So, yes I do agree that UTC is "not time zone", but I do not know in
which context you mean. As in many common contexts the UTC is the time
zone.


-- 
Jean

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

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

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:

> That is not same case as Ihor, when he designated it as 
>
> 2030-02-09 12:00 -0800 @UTC
> because there are no offsets @UTC time zone.

I do not recall providing such example. May you point me to the message
where you saw me writing -0800 @UTC?

-- 
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)

[Max Nikulin]

On 14/02/2023 22:59, Jean Louis wrote:

What Ihor proposed is time stamp like:

  2023-02-14 Tue 12:00:00 +0800 @UTC


I am not sure that combination of +0800 and UTC was intentional. The 
following is redundant, but there is nothing wrong while offset and time 
zone identifier are in agreement:


2023-02-14 Tue 12:00:00 +0800 @Asia/Singapore

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

[Thomas S. Dye]

Jean Louis  writes:


* Max Nikulin  [2023-02-14 14:45]:

On 14/02/2023 16:45, to...@tuxteam.de wrote:
> On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler 
> wrote:

> > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00:
> > > Then just representation must be clear: @UTC is unclear 
> > > in those

> > > cases, but @RELTOUTC would be clear.
> > 
> > @RELTOUTC seems unfortunate, as it states only the obvious. 
> > If at all,
> > it should be @AHEADUTC or @BEHINDUTC or some abbreviation 
> > of it, but as

> > said above, it seems not necessary to me.
> 
> That's what the "+" and "-" do, anyway.


TZ=Etc/GMT-8 date '+%F %a %T %z %Z'
2023-02-14 Tue 19:37:01 +0800 +08

TZ=Etc/GMT+8 date '+%F %a %T %z %Z'
2023-02-14 Tue 03:38:24 -0800 -08

Notice sign in time zone identifier is opposite to time offset. 
However I am
against RELTOUTC/AHEADUTC/BEHINDUTC. From my point of view 
+0800/-0800 is

clear enough.

P.S. Last +08/-08 are really time zone abbreviations, not 
offset, however

unlike "BST" & Co. they are acceptable to specify offset
unambiguously.


That is different use case Max. 

For this use case I am in full agreement, that is what is used 
anyway

worldwide.

What Ihor proposed is time stamp like:

 2023-02-14 Tue 12:00:00 +0800 @UTC

Though I just say when we put "UTC" that means normally "UTC 
time
zone" and such has no prefix that is positive or negative, can 
be

zero.


Sigh.  UTC is not a time zone.

All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye

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

[Jean Louis]

* Max Nikulin  [2023-02-14 14:45]:
> On 14/02/2023 16:45, to...@tuxteam.de wrote:
> > On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote:
> > > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00:
> > > > Then just representation must be clear: @UTC is unclear in those
> > > > cases, but @RELTOUTC would be clear.
> > > 
> > > @RELTOUTC seems unfortunate, as it states only the obvious. If at all,
> > > it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as
> > > said above, it seems not necessary to me.
> > 
> > That's what the "+" and "-" do, anyway.
> 
> TZ=Etc/GMT-8 date '+%F %a %T %z %Z'
> 2023-02-14 Tue 19:37:01 +0800 +08
> 
> TZ=Etc/GMT+8 date '+%F %a %T %z %Z'
> 2023-02-14 Tue 03:38:24 -0800 -08
> 
> Notice sign in time zone identifier is opposite to time offset. However I am
> against RELTOUTC/AHEADUTC/BEHINDUTC. From my point of view +0800/-0800 is
> clear enough.
> 
> P.S. Last +08/-08 are really time zone abbreviations, not offset, however
> unlike "BST" & Co. they are acceptable to specify offset
> unambiguously.

That is different use case Max. 

For this use case I am in full agreement, that is what is used anyway
worldwide.

What Ihor proposed is time stamp like:

 2023-02-14 Tue 12:00:00 +0800 @UTC

Though I just say when we put "UTC" that means normally "UTC time
zone" and such has no prefix that is positive or negative, can be
zero.

-- 
Jean

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

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

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

[tomas]

On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote:
> Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00:

[...]

> > Then just representation must be clear: @UTC is unclear in those
> > cases, but @RELTOUTC would be clear.
> > 
> 
> @RELTOUTC seems unfortunate, as it states only the obvious. If at all,
> it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as
> said above, it seems not necessary to me.

That's what the "+" and "-" do, anyway.

Cheers
-- 
t


signature.asc
Description: PGP signature

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

[Jean Louis]

* Heinz Tuechler  [2023-02-14 12:44]:
> Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00:
> > * to...@tuxteam.de  [2023-02-12 16:50]:
> > > On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:
> > > > * Ihor Radchenko  [2023-02-10 13:48]:
> > > > > 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.
> > > > 
> > > > - did you say you wish to represent time with UTC time zone by using
> > > >   UTC offset?
> > > > 
> > > > - and I said, UTC time is always without offset, and if any is
> > > >   represented then it must be +00
> > > > 
> > > > - and now you say that ISO8601 defines offsets... sorry, you are
> > > >   confusing me and readers.
> > > 
> > > It is not about "the offset OF UTC". It is about "the offset
> > > RELATIVE TO UTC".
> > 
> > Yes, surely is clear to me personally.
> 
> If 2022-11-12 12:00+02 # 12:00 UTC+2 should mean that local time is
> 2022-11-12 12:00 and that it is 2 hours _ahead_ of UTC, then it seems
> intuitively clear to me. I would assume that holds for many others
> as well.

Exactly that. Never said anything different.

Discussion started from something like this:

2022-11-12 12:00+02 @UTC

and that is different case, where Ihor was suggesting that: 2022-11-12
12:00 is UTC time, not local time, where by +02 is offset (I say not
UTC offset) to be added or deducted on that time.

> > That we got for sure.
> > 
> > Then just representation must be clear: @UTC is unclear in those
> > cases, but @RELTOUTC would be clear.
> > 
> 
> @RELTOUTC seems unfortunate, as it states only the obvious. If at all,
> it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as
> said above, it seems not necessary to me.

As idea I understand Ihor and other person on Internet.

But as implementation by using @UTC or by using date time
representation as UTC time with offset (not UTC offset), I think it
will be confusing for people, unless there is new tag invented to make
sure of it.

Any idea is fine:

2022-11-12 12:00+02 @UTC-SUM
2022-11-12 12:00+02 @UTC-TO
2022-11-12 12:00+02 @TO-UTC

but not

2022-11-12 12:00+02 @UTC

As that would be confusing.

-- 
Jean

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

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

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 14/02/2023 16:45, to...@tuxteam.de wrote:

On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote:

Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00:

Then just representation must be clear: @UTC is unclear in those
cases, but @RELTOUTC would be clear.


@RELTOUTC seems unfortunate, as it states only the obvious. If at all,
it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as
said above, it seems not necessary to me.


That's what the "+" and "-" do, anyway.


TZ=Etc/GMT-8 date '+%F %a %T %z %Z'
2023-02-14 Tue 19:37:01 +0800 +08

TZ=Etc/GMT+8 date '+%F %a %T %z %Z'
2023-02-14 Tue 03:38:24 -0800 -08

Notice sign in time zone identifier is opposite to time offset. However 
I am against RELTOUTC/AHEADUTC/BEHINDUTC. From my point of view 
+0800/-0800 is clear enough.


P.S. Last +08/-08 are really time zone abbreviations, not offset, 
however unlike "BST" & Co. they are acceptable to specify offset 
unambiguously.

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

[Heinz Tuechler]

Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00:

* to...@tuxteam.de  [2023-02-12 16:50]:

On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:

* Ihor Radchenko  [2023-02-10 13:48]:

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.


- did you say you wish to represent time with UTC time zone by using
  UTC offset?

- and I said, UTC time is always without offset, and if any is
  represented then it must be +00

- and now you say that ISO8601 defines offsets... sorry, you are
  confusing me and readers.


It is not about "the offset OF UTC". It is about "the offset
RELATIVE TO UTC".


Yes, surely is clear to me personally.


If 2022-11-12 12:00+02 # 12:00 UTC+2 should mean that local time is
2022-11-12 12:00 and that it is 2 hours _ahead_ of UTC, then it seems
intuitively clear to me. I would assume that holds for many others as well.



That we got for sure.

Then just representation must be clear: @UTC is unclear in those
cases, but @RELTOUTC would be clear.



@RELTOUTC seems unfortunate, as it states only the obvious. If at all,
it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as
said above, it seems not necessary to me.

Heinz

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

[Jean Louis]

* to...@tuxteam.de  [2023-02-12 16:50]:
> On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:
> > * Ihor Radchenko  [2023-02-10 13:48]:
> > > 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.
> > 
> > - did you say you wish to represent time with UTC time zone by using
> >   UTC offset?
> > 
> > - and I said, UTC time is always without offset, and if any is
> >   represented then it must be +00
> > 
> > - and now you say that ISO8601 defines offsets... sorry, you are
> >   confusing me and readers.
> 
> It is not about "the offset OF UTC". It is about "the offset
> RELATIVE TO UTC".

Yes, surely is clear to me personally. 

That we got for sure.

Then just representation must be clear: @UTC is unclear in those
cases, but @RELTOUTC would be clear.

-- 
Jean

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

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