Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Jean Louis]

* Max Nikulin  [2023-01-24 20:12]:
> On 22/01/2023 14:48, Tim Cross wrote:
> > Timestamp for a log
> > record I would probably want  or one of the
> > variants because the most common way I use those types of timestamp is
> > in diagnosing problems and comparing revords from various locations
> > where I don't care about the local time where the record was generated,
> > but with when it occurred in relation to other log recores.
> 
> I agree that it is more convenient to have uniform offset in such case,
> especially in the case of multiple files having their specific timezone.
> During trips I do not expect so much changes of timezone to make comparison
> of timestamps significantly harder.
> 
> > I would argue that all depends on how you use the information. My org
> > files are consumed by me (reading) and by scripts, elisp and other
> > programs.
> 
> For scripts given offset should not be an issue at all. And it is up to you
> if you prefer to have UTC instead of local time offset in you files.

Surely I understand your point of view, but offset does not provide to
people their local time, that would just make confusion.

-- 
Jean

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

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

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Jean Louis]

* Max Nikulin  [2023-01-24 07:51]:
> On 24/01/2023 09:44, Thomas S. Dye wrote:
> > Max Nikulin writes:
> > > 
> > > I believed that [2023-01-22 Sun 08:29@+1100] unambiguously suggests
> > > offset from UTC.
> > 
> > Not for a casual programmer like me. The timestamp alone might easily be
> > read as 11 hours ahead of local time. Nevertheless, Org is certainly
> > free to interpret it as relative to UTC.
> 
> My primary concern is that I might be wrong assuming that format like
> [2023-01-22 Sun 08:29@+1100] with offset in respect to UTC is reciprocal
> identity  mapping to UTC.

ISO 8601 is international standard on which you should make decisions.

https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC
https://en.wikipedia.org/wiki/UTC_offset

,
| The UTC offset (or time offset) is an amount of time subtracted from
| or added to Coordinated Universal Time (UTC) time to specify the local
| solar time (which may not be the current civil time, whether it is
| standard time or daylight saving time). 
`

I hope your concern clarifies itself.

-- 
Jean

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

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

[BUG] HTML-export citation suffix rendering with CSL [9.6 (9.6-??-bed47b437 @ /home/romeo/.emacs.d/.local/straight/build-28.2.50/org/)]

[Romeo Valentin]

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

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

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


Dear maintainers,
attached is an org file which contains citations that are processed
through the CSL citation processor, and a .bib file for completeness.
The files are also included at the end of the email text.

I am trying to export the org file to HTML and point out a specific
theorem, however including a suffix in the citation breaks the HTML
rendering in two ways, as demonstrated in the files.

To reproduce, please download the .org and .bib file (place .bib in
/tmp), run org-html-export-to-html, and open the file e.g. with a browser.
Notice that the citations, in particular the suffixes, are rendered 
incorrectly.


Kind regards,
Romeo Valentin

PS: Recall the citation syntax from here [1] or here [2].
[1]: https://orgmode.org/manual/Citations.html
[2]: https://blog.tecosaur.com/tmio/2021-07-31-citations.html

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

 of 2023-01-07
Package: Org mode version 9.6 (9.6-??-bed47b437 @ 
/home/romeo/.emacs.d/.local/straight/build-28.2.50/org/)



*citeproc-bugreport.org:*
#+title: Citeproc Bugreport
#+bibliography: /tmp/citeproc-bugreport-references.bib
#+cite_export: csl

* Problem 1: textcite plus suffix
- Normal citation with suffix: 
[cite:@abnarQuantifyingAttentionFlow2020a, Thm. one]
- Broken (text)citation with suffix: 
[cite/t:@abnarQuantifyingAttentionFlow2020a, Thm. one]

  *This doesn't display correctly*

* Problem 2: citation with suffix and number
- Broken citation with suffix: 
[cite:@abnarQuantifyingAttentionFlow2020a, Thm. 1]

  *This doesn't display correctly*
- Notice that here a number comes last. I assume that the number is 
trying to be matched to a "locator", however there is no locator for 
"theorem".


#+print_bibliography:

*/tmp/citeproc-bugreport-references.bib:
*@article{abdarReviewUncertaintyQuantification2021,
  title = {A {{Review}} of {{Uncertainty Quantification}} in {{Deep 
Learning}}: {{Techniques}}, {{Applications}} and {{Challenges}}},
  shorttitle = {A {{Review}} of {{Uncertainty Quantification}} in 
{{Deep Learning}}},
  author = {Abdar, Moloud and Pourpanah, Farhad and Hussain, Sadiq and 
Rezazadegan, Dana and Liu, Li and Ghavamzadeh, Mohammad and Fieguth, 
Paul and Cao, Xiaochun and Khosravi, Abbas and Acharya, U. Rajendra and 
Makarenkov, Vladimir and Nahavandi, Saeid},

  date = {2021-12},
  journaltitle = {Information Fusion},
  eprint = {2011.06225},
  eprinttype = {arxiv},
  archiveprefix = {arXiv},
  keywords = {Computer Science - Artificial Intelligence,Computer 
Science - Computer Vision and Pattern Recognition,Computer Science - 
Machine Learning},

}

**#+title: Citeproc Bugreport
#+bibliography: /tmp/citeproc-bugreport-references.bib
#+cite_export: csl

* Problem 1: textcite plus suffix
- Normal citation with suffix: [cite:@abnarQuantifyingAttentionFlow2020a, Thm. one]
- Broken (text)citation with suffix: [cite/t:@abnarQuantifyingAttentionFlow2020a, Thm. one]
  *This doesn't display correctly*

* Problem 2: citation with suffix and number
- Broken citation with suffix: [cite:@abnarQuantifyingAttentionFlow2020a, Thm. 1]
  *This doesn't display correctly*
- Notice that here a number comes last. I assume that the number is trying to be matched to a "locator", however there is no locator for "theorem".

#+print_bibliography:
@article{abdarReviewUncertaintyQuantification2021,
  title = {A {{Review}} of {{Uncertainty Quantification}} in {{Deep Learning}}: {{Techniques}}, {{Applications}} and {{Challenges}}},
  shorttitle = {A {{Review}} of {{Uncertainty Quantification}} in {{Deep Learning}}},
  author = {Abdar, Moloud and Pourpanah, Farhad and Hussain, Sadiq and Rezazadegan, Dana and Liu, Li and Ghavamzadeh, Mohammad and Fieguth, Paul and Cao, Xiaochun and Khosravi, Abbas and Acharya, U. Rajendra and Makarenkov, Vladimir and Nahavandi, Saeid},
  date = {2021-12},
  journaltitle = {Information Fusion},
  shortjournal = {Information Fusion},
  eprint = {2011.06225},
  eprinttype = {arxiv},
  issn = {15662535},
  doi = {10.1016/j.inffus.2021.05.008},
  archiveprefix = {arXiv},
  keywords = {Computer Science - Artificial Intelligence,Computer Science - Computer Vision and Pattern Recognition,Computer Science - Machine Learning},
  file = {/home/romeo/Zotero/storage/3SA9DLUL/Abdar et al. - 2021 - A Review of Uncertainty Quantification in Deep Lea.pdf;/home/romeo/Zotero/storage/W8AUG4IY/Abdar et al. - 2021 - A Review of Uncertainty Quantification in Deep Lea.pdf;/home/romeo/Zotero/storage/V7MHDX4H/2011.html}
}
Title: Citeproc Bugreport






Citeproc Bugreport

Table of Contents


1. Problem 1: textcite plus suffix
2. Problem 2: citation with 

[PATCH] Fix one remaining emacs-30 byte-compile warning

[Arash Esbati]

Hi all,

Robert sent a patch[1] which pacifies emacs-30 compiler warning.  He
missed one which is fixed by the patch below.  It is against org-mode
master (6b15897a56).

Footnotes:
[1]  https://lists.gnu.org/archive/html/emacs-orgmode/2023-01/msg00743.html

Best, Arash

--8<---cut here---start->8---
diff --git a/lisp/ox.el b/lisp/ox.el
index ebf89bb..4c84686 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -6683,14 +6683,14 @@ see.
 Optional argument POST-PROCESS is a function which should accept
 no argument.  It is always called within the current process,
 from BUFFER, with point at its beginning.  Export back-ends can
-use it to set a major mode there, e.g,
+use it to set a major mode there, e.g.,

   (defun org-latex-export-as-latex
 ( async subtreep visible-only body-only ext-plist)
 (interactive)
 (org-export-to-buffer \\='latex \"*Org LATEX Export*\"
   async subtreep visible-only body-only ext-plist
-  #'LaTeX-mode))
+  #\\='LaTeX-mode))

 When expressed as an anonymous function, using `lambda',
 POST-PROCESS needs to be quoted.
--8<---cut here---end--->8---

CSL export not using local #+bibliography:

[Britt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I reported the following as an issue to citeproc, but was advised by the
library maintainer to report it here instead.

The problem is summarized in the subject line.

I set ~org-cite-global-biography~ in my init.el.

I then write a file for export with ~org-publish~ to html and where the
org file has in the header ~#+bibliography:
"path-to-different-bib-file.bib"~ I can C-c C-c and am told that the
local environment has been updated, but when I export with
~org-publish-project~ the bib file being used is still the global one.
I have to manually ~setq~ the global bib to get the correct file used at
export.

-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAnBQJjz98YCZAwMVHgg5k1RxYhBNNYE9hwe4A6OqjHzDAxUeCD
mTVHAABUigf8C7gc3Q3wqrVytPs7FCZ4qKojqM48+tJn6HVbXWGKEiGx5f78
Shiry+wTlIvKGFIVf5Hw8Vgqh6YnBiFMyUkiHoUGbv0bqET2b6cODaCZHXiy
OTAPUoa/nqsRewmL9PZ8JlPhIkD2+iBYMNqPHUKVYqPDeNybF+qpvxFFZuVV
stj15N0InMMUY2CO0eknu2oF5+kFZ0P+bOFuQwUS90nWpsIXtq36b1n0aikb
wA+52Kl5E2NOAadQGya5RoQeslIkfjVVxtk+OkBqvJ4GWzrxj4dGlRkftmCH
gUVQYfc3iMZNss5Tvi+fqhtDk4ro/KQMEeV3xjRuqTVlZn4DS4Ky0A==
=f9TP
-END PGP SIGNATURE-


publickey - brittanderson@protonmail.com - d35813d8.asc
Description: application/pgp-keys


publickey - brittanderson@protonmail.com - d35813d8.asc.sig
Description: PGP signature

[BUG] Org citations do not render in tables [9.5.5 (9.5.5-g8ef620 @ /home/stas/.emacs.d/straight/build/org/)]

[Stanislav Vlasov]

Dear org community,

It seems that there is a bug (or a thing that was not yet implemented) with 
rendering tables that contain org-mode citations (i.e., [cite:@paper]) from 
source block results. Here is an example:

#+BEGIN_SRC emacs-lisp :results table replace
"Prior research [cite:@paper] suggests that..."
#+END_SRC

#+RESULTS:
| Prior research suggests that... |

The expected outcome should be:

#+RESULTS:
| Prior research [cite:@paper] suggests that... |

It seems that this does not depend on src language (I have also tried with R 
and got the same issue).

I have already asked it on StackExchange 
(https://emacs.stackexchange.com/questions/75270) and user 'Simka' pointed out 
that the cause of this issue is somewhere in `orgtbl-to-generic' and it is 
about undefined export backend for citations.


Kind regards,
Stas




Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, 
cairo version 1.17.6)
 of 2022-09-12
Package: Org mode version 9.5.5 (9.5.5-g8ef620 @ 
/home/stas/.emacs.d/straight/build/org/)

[BUG] updates.orgmode.org returns 502 Bad Gateway

[emacs]

Hi all, I'm trying to find the RSS feed for org-mode, which I expect to
live in updates.orgmode.org (as mentioned in the first line of [1]).
Unfortunately, the nginx server is misconfigured (or something) and
returns a "502 Bad Gateway" error.

This is not a software bug, but I'm not sure where else to report this.

[1]: https://orgmode.org/Changes.html



Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 
1.16.0, Xaw3d scroll bars)
Package: Org mode version N/A (N/A @ 
/nix/store/c6mwhd9s55myn00h0c5z97qbjlb6rcx3-emacs-packages-deps/share/emacs/site-lisp/org-9.6.1-20230116/)

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Would someone please tell me more concretely what kind of "support"
  > > this is?

  > You can find interactive support in `sql' library, functions such as:

  > M-x sql-oracle 

  > which supports proprietary Oracle Database:

This raises two questions.

1. For this purpose, what kind of thing is "the Oracle Database"?
a. A library to link with?
b. A program to run in a subprocess?
c. A server running SaaSS?

2. How does Emacs communicate with that thing?
a. By function calls within a process?
b. Via shared memory?
c. Via a pty or pipe?
d. Via sockets?

The answers are crucial for thinking about what our moral ideas and
policies say about this case.

  > (sql-ms  BUFFER)

  > Run osql by Microsoft as an inferior process.

This suggests an answer to the first question.
More precisely, it suggests that the answer is b
_at least some of the time_.

  > > Are they nonfree programs, or are they SaaSS?

  > They are proprietary programs that may be also SaaSS.

Does the Emacs support offer to talk with a remote web server?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Feature request: "task table" (similar to clock table)

[Max Nikulin]

On 25/01/2023 03:09, Marcin Borkowski wrote:

https://mbork.pl/2023-01-09_TODO_stats_table


Sorry for a too late response. The feature is documented in the manual, 
see info "(org) Dynamic Blocks" 
https://orgmode.org/manual/Dynamic-Blocks.html


Perhaps a close feature that might allow to return list that is 
converted to table by org-babel is "#+call:", see info "(org) Evaluating 
Code Blocks" https://orgmode.org/manual/Evaluating-Code-Blocks.html

Re: oeg-agenda-entry-text-mode

[David Masterson]

David Masterson  writes:

> I've just discovered the E key in Agenda Commands and I'd like to use
> it.  The drawback is that it shows Log entries (I don't use a Drawer for
> Logs -- yet).  This means that the original description can be hidden if
> the logs use up more than org-agenda-entry-text-maxlines.
>
> Is there someway to toggle logs in org-agenda-entry-text-mode?  Also, if
> I create a drawer for logs, is there someway to move current logs to the
> drawer?

Ooh!  Found org-agenda-entry-text-exclude-regexp!  It's so close to what
I want.  With it, I can delete everything on a line that I don't want to
be displayed with org-agenda-entry-text-mode.  But I can't get rid of
the line, so I wind up with blank lines where the log would've been.

Any other options?  Or a secret to the regexp for getting rid of blank
lines?  Or embedding a newline in the regexp to exclude the line?

-- 
David Masterson

oeg-agenda-entry-text-mode

[David Masterson]

I've just discovered the E key in Agenda Commands and I'd like to use
it.  The drawback is that it shows Log entries (I don't use a Drawer for
Logs -- yet).  This means that the original description can be hidden if
the logs use up more than org-agenda-entry-text-maxlines.

Is there someway to toggle logs in org-agenda-entry-text-mode?  Also, if
I create a drawer for logs, is there someway to move current logs to the
drawer?

-- 
David Masterson

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Tim Cross]

Max Nikulin  writes:

> On 22/01/2023 14:48, Tim Cross wrote:
>> Timestamp for a log
>> record I would probably want  or one of the
>> variants because the most common way I use those types of timestamp is
>> in diagnosing problems and comparing revords from various locations
>> where I don't care about the local time where the record was generated,
>> but with when it occurred in relation to other log recores.
>
> I agree that it is more convenient to have uniform offset in such case, 
> especially in the
> case of multiple files having their specific timezone. During trips I do not 
> expect so
> much changes of timezone to make comparison of timestamps significantly 
> harder.
>
>> I would argue that all depends on how you use the information. My org
>> files are consumed by me (reading) and by scripts, elisp and other
>> programs.
>
> For scripts given offset should not be an issue at all. And it is up to you 
> if you prefer
> to have UTC instead of local time offset in you files.
>
>> My preference is for a timestamp syntax which lets the user select the
>> format they want and not attempt to restrict it more than that.
>
> I do not mind to provide a user option for preferred storage format used for 
> clock entries
> and similar stuff.
>
>> Provided
>> you can specify timestamp with and without TZ information and you
>> support full and abbreviated time zone names as well as UTC, I don't
>> think it mattters - let the user choose what suits them best.
>
> Concerning time zone abbreviations, I would discourage them as much as 
> possible for
> storage format. They may be added to overlay though. Perhaps US residents 
> would be unhappy
> by such decision, but there are enough examples of the same abbreviation for 
> completely
> unrelated locations. Abbreviation may be useful in addition to timezone ID to 
> disambiguate
> local time close to a backward time jump.
>
> Tim, in your last messages I do not see statements causing my objections any 
> more. It
> seems we came to agreement: flexible enough storage format and configurable 
> display format
> for overlays. Have I forgot anything?

No, I think you have covered everything.

I think most of your remaining concerns can be adequately covered via
some updated documentation and with some luck, people will add some use
case workflows to worg showing how using different storage formats and
display overlays can address various scenarios.  

Re: cgit and merge commit

[Ihor Radchenko]

Max Nikulin  writes:

>> Should we then report a bug to cgit mailing list?
>
> I do not have particular opinion. I rarely use web UI for git and mostly 
> for blame. I prefer to do it with local clone. I have never read cgit 
> docs. Perhaps it may be more apparent that it is a merge commit.
>
> Anyway at first I would ask the savannah team. E.g. vanilla debbugs 
> instance is significantly more convenient than the GNU ones and the 
> changes in the latter are intentional. Mhonarc (list archive) at 
> lists.debian.org has better configuration than at lists.gnu.org as well. 
> So there might be specific of particular instance.

I asked savannah people, and they pointed out that the commits where, in
fact, listed in the logs. Just at their original creating dates - much
earlier than the merge commit date and further down into the logs.

So, it was mostly my oversight from the very beginning - nothing was
lost during the merge process.

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

Re: Feature request: "task table" (similar to clock table)

[Marcin Borkowski]

On 2023-01-24, at 10:59, Ihor Radchenko  wrote:

> Marcin Borkowski  writes:
>
>> https://mbork.pl/2023-01-09_TODO_stats_table
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7ad77965467602ced2cb8f3cded023882dc229a2

Thanks!

-- 
Marcin Borkowski
http://mbork.pl

Re: [ANN] orgtbl-fit

[Ihor Radchenko]

tbanelwebmin  writes:

> The new orgtbl-fit package has just been released on Melpa. It
> does regression fitting on Org Mode tables.
>
> Example. We suspect that `obs' depends on `x' and `y'.
> ...
>
> Let us put the cursor on the `obs' column, and type
> M-x orgtbl-fit
>
> Two columns are added
> - predicted obs column
> - difference between obs and predicted
>
> |  x | y |  obs | Best Fit | Fit Diff |
> |+---+--+--+--|
> | 32 | 7 | 38.3 | 38.2 | -0.1 |
> | 18 | 3 | 11.4 | 11.6 |  0.2 |
> | 43 | 9 | 47.3 | 47.2 | -0.1 |
> | 11 | 2 |  8.9 |  8.7 | -0.2 |
> | 35 | 8 | 45.1 | 45.3 |  0.2 |
> #+TBLFM: $4=-0.289267886829 - 1.06613976706*$1 + 10.3668885192*$2; 
> %.1f::$5=$4-$3; %.1f

Are there situations when this package is actually useful for data
analysis? (I am usually using gnuplot for fitting)

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

Re: org-sort no ts

[Ihor Radchenko]

Samuel Wales  writes:

> with org-sort, by analogy with org-agenda-sort-notime-is-late, is it
> possible to sort T, i.e. by ts with most recent first, with entries
> that have no ts at the bottom?

It is currently hard-coded to consider notime as `current-time' when sorting.

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Ihor Radchenko  [2023-01-24 14:19]:
> mid: if a known standard, as Max pointed in the earlier message:
> 
> RFC 2392 - Content-ID and Message-ID Uniform Resource Locators. 1998
> https://tools.ietf.org/html/rfc2392

It is "proposed standard" and far from any ordinary use.

> It makes more sense than arbitrary ideas not known to anyone, even
> if they sound better for some users.

Not that I can agree as heavy user of e-mails.

mid: -- shall support IMAP, mbox, Maildir, file location in first
place.

Please think of 1998, that is year where majority of people used mbox,
which meaning was that all e-mails were (mostly) in single file. 

And even with that single file, users were to open that file to
request "mid". 

This implies that e-mail program had to know which file to open.

That is missing argument to that proposed standard, practically no
standard at all, laughable to say it is "standard".

mu, notmuch and Thunderbird all use index to search for Message-ID,
including online web clients.

But location is missing part as on user's computer there may be too
many mbox, Maildir files, mh, what else, and messages may be on IMAP
server. 

I cannot provide to myself "mid:" hyperlink without providing location
of Maildir file, if I am to use Mutt as e-mail client or any e-mail
program that does not have indexing built-in.

I have to specify file plus Message-ID.

That would mean something like 

mid:///home/data1/protected/Maildir/yanta...@posteo.net&87mtz84om9.fsf@localhost

because yanta...@posteo.net would be either mbox, Maildir or other
format.

I don't care for useless and never adopted standards from 1998. 

It is 2023.

-- 
Jean

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

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Ihor Radchenko  [2023-01-24 12:41]:
> > This is weird since ever. I've been talking to some collegues and everybody 
> > has his/her own special approach. Mostly producing a PDF from the E-Mail 
> > and 
> > saving this and its attachments somewhere. That's a thing that bothered me 
> > for 
> > decades. 
> 
> Well. The more widely used standard is Maildir - downloading emails from
> server to local machine. Emails are just files there that can be indexed
> by variety of mail client software.

I have to give some corrections according to my knowledge.

Maildir is less used format, not widely used. Not even in GNU/Linux,
it is simply not default. I guess mbox format is much more used.

https://en.wikipedia.org/wiki/Mbox

And it is not related to how people download or not download
e-mails. And how server uses mail boxes is also independent of how
users use mailboxes.

E-mails are not "just files", they are pieces of informaton and if
they are stored as files depends of software. When e-mail is on
server, it may run different software storing e-mails in the databases
where database objects are not independent files for each e-mail, and
can't be manipulated as such.

And retrieving e-mails, while mostly in form of files, may be also in
form of a database objects. 

There is server side and client side software, they work independent
of each other and decide how to store e-mails. Or not store it at all
at client's computer.

To understand what is widely used e-mail file format, one has to see
what are widely used e-mail clients. 

Maybe this picture may help:
https://d27jswm5an3efw.cloudfront.net/app/uploads/2021/04/most-popular-email-clients-graph.jpeg

or this one:

https://www.oberlo.com/media/1673256706-most-used-email-clients-worldwide.png?fit=max=webp=1800

Those are by majority all web software clients.

No matter if statistics are right or wrong, not even Thunderbird is
there, and Thunderbird has Maildir only as experimental option.

And regarding indexing, many e-mail programs do not support indexing,
it is not at all their main purpose. They may retrieve e-mail, read,
reply, sort, delete, but indexing is often forgotten feature.

> The main question is which email clients actually support mid: links.
> notmuch does, but in non-standard way, without doing it system-wide.

notmuch is more indexing system, and programs working with notmuch may
be considered email clients.

Another e-mail indexing program is "mu" and I am sure it can search by
Message-ID: https://www.djcbsoftware.nl/code/mu/ as notmuch never
worked on my computer. 

I can't verify it as I did not use index, being very efficient without
it due to method of sorting all e-mails per Maildir representing the
e-mail address.

Sadly mid: appear not to be supported by many software, just as many
software not supporting various URLs when they should. 

Let us not forget there are universal URL launchers, such as:

- exo-open from XFce

- xdg-open - opens a file or URL in the user's preferred application
  (Free Desktop

- kde-open from KDE

- rox -U -- may launch any type of URI handlers by user customization:
  https://rox.sourceforge.net/desktop/book/export/html/163.html

And there are others, including browsers being mainly used to launch
any types of URI schemes.

Maybe you can see the pattern that there various launchers for URI
schemes and all of them allow users to specify which software to use,
and there are many browsers, majority of browsers follow the pattern
to allow users to specify how to open which URI scheme.

By seeing the pattern, you may see why is it useful. I hope so.

And then I hope you will not keep URI handlers hard coded, but allow
Org users to decide which launcher, browser, or what to use on Org
hyperlinks.

When I think of "mid:" I think of "Message-ID: " and that is generally
not hard to find in various e-mail formats.

In Emacs, for mbox files, it would be something as:
(search-forward "87y2e2bgzh@example.com") followed by extracting
and displaying of the found e-mail.

With Maildirs it would be `grep' search on Maildir folder, it is
almost instant on hundreds of e-mails.

Of course scalability is a problem when using `grep' as with too many
e-mails, it would last long.

That is why both for mh, mbox, Maildir and other folders, one shall
always specify the folder location.

Without folder location mid:123 alone would require indexer to find
the Message-ID.

That is why it would not be for Org to specify how mid links are
opened but for user to customize it.

As user may have mid:// format or only mid: or maybe
mid://file/message-id format, depending of the software.

That Thunderbird uses only mid:message-id format is definitely unique
and not ordinary as generally e-mail clients do not support it.

Additionally, mid: need not specify only local file, it could specify
IMAP as well mid:imaps://example.com/INBOX

-- 
Jean

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

In 

Re: [PATCH] lisp/org-agenda.el: Fix void-function string-pad in Emacs <28.1

[Aaron Zeng]

Much obliged :)

On Tue, Jan 24, 2023 at 1:20 PM Ihor Radchenko  wrote:

> Aaron Zeng  writes:
>
> > Hi Ihor, I just noticed that this patch only fixes one of the lines
> calling
> > `string-pad'.  There is another callsite below which needs to be removed.
>
> Oops. Now, should be good.
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=20ee7b85ebc0e3e08805b1e9e3e824f50347340e
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [PATCH] lisp/org-agenda.el: Fix void-function string-pad in Emacs <28.1

[Ihor Radchenko]

Aaron Zeng  writes:

> Hi Ihor, I just noticed that this patch only fixes one of the lines calling
> `string-pad'.  There is another callsite below which needs to be removed.

Oops. Now, should be good.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=20ee7b85ebc0e3e08805b1e9e3e824f50347340e

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Max Nikulin  [2023-01-24 20:25]:
> On 24/01/2023 01:37, Jean Louis wrote:
> > 
> > All URLs defined by Emacs that are to be run by browse-url in Org
> > shall be allowed by org, to let the Emacs settings pass through.
> > 
> > And not to hard code it in Org.
> 
> It reminds be complains by some person that Org must be able to recognize
> any URL in free-form plain text just because there is a RFC describing
> format of URL.

That person did not really propose to Org to do it, but to have Emacs
EWW to be customizable, so that any content type could be opened by
user's settings. You missed the point of it.

> Try to think from position of a developer.

>From position of developer, developers shall ideally think of users,
and users think of the assistance of computer to users. 

Users appreciate developers who make their life easier.

> An entry may be added to `browse-url-handlers' after loading of ol.
> 
> org-link and browse-url are so flexible that it would be hard to reliably
> match their entries taking into account different set of supported features.
> The former allows e.g. fuzzy search links, the latter something similar to
> Android deep links.

That means Org authors missed to use Emacs built-ins. 

> I have no idea which way you configured mid: links in Org, but this thread
> contains 5 lines that successfully works for me.

When goto-mode works with mid: by me setting up browse-url-handlers,
then I have expected Org to work as well. 

But I do not rely on Org mode to use browse-url, rather I rely on Org
using elisp: links.

That is not really "mid:" but it will work for long time and be
independent of Org developers' decisions.

-- 
Jean

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

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Bruno Barbier  [2023-01-24 20:31]:
> > [[elisp:(my-handler "I am ok here")][my handler]]
> 
> Org also allows the user to define his own link types:
> 
>  (info "(org) Adding Hyperlink Types")

I understand. 

You see, Org is part of Emacs, me I expect that when I follow Emacs
Instructions that Org will be using Emacs settings, but it follows
it's own settings.

I mean these settings:

browse-url-handlers is a variable defined in ‘browse-url.el’.

Its value is
(("gemini:" . elpher-go)
 ("gopher:" . elpher-handler-go)
 ("about:" . hyperscope-about)
 ("mid:" . my-handler)
 ("hyperscope:" . hyperscope-url)
 ("e2dk://" . amule-handler))
Original value was nil

An alist with elements of the form (REGEXP-OR-PREDICATE . HANDLER).
Each REGEXP-OR-PREDICATE is matched against the URL to be opened
in turn and the first match’s HANDLER is invoked with the URL.

A HANDLER must be a function with the same arguments as
‘browse-url’.

If no REGEXP-OR-PREDICATE matches, the same procedure is
performed with the value of ‘browse-url-default-handlers’.  If
there is also no match, the URL is opened using the value of
‘browse-url-browser-function’.

  This variable was introduced, or its default value was changed, in
  version 28.1 of Emacs.
  You can customize this variable.

-- 
Jean

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

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Max Nikulin  [2023-01-24 18:52]:
> > I am mostly concerned that channelling mid: links to browse-url will not
> > work (open empty page in browser) in most cases. This is more confusing
> > than not having mid: link handler at all.
> 
> For me it may be a reason to not enable to enable "mid:" links by default,
> but I am still considering `browse-url' as the proper handler.

You should neither enable, neither disable opening of any links on the
Org level except maybe Emacs Lisp links.

Otherwise let users enable or disable what they want.

> Code to determine handler is platform-specific, e.g. for Linux
> 
> xdg-mime query default x-scheme-handler/mid
> xdg-settings get default-url-scheme-handler mid
> 
> The latter actually calls the former. I would avoid both variants during
> load time.
> 
> If you get browser fallback then you are advanced enough user to avoid a DE.
> Gnome shows application selection dialog, KDE throws an error
> window.

Let users open Hyperlinks with any browser or function how they want.

I am aware that Org has that mixed hyperlink types as explained in:

(info "(org) External Links") 

and when I say "mixed" it does not support the expected standard of
URI Schemes (https://en.wikipedia.org/wiki/List_of_URI_schemes) as it
introduces various Org related hyperlinks.

At this point, after so many years, nobody recognizes that such
capricious single user decision does not scale well for broad public.

And now because all the users are entangled using non-standard URI
schemes, it is very hard to switch, as it would break compatibility.

-- 
Jean

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

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* Ihor Radchenko  [2023-01-24 12:43]:
> Max Nikulin  writes:
> 
> > On 23/01/2023 17:40, Ihor Radchenko wrote:
> >> I am not even sure if we need to make Org open mid: links via
> >> `browse-url'. Maybe it should be something else? IDK.
> >
> > Do you know an alternative? Org already uses this package to open some 
> > types of links. It allows to have the same handler for all Emacs 
> > packages. I do not think that Org-specific handler would be better.
> 
> I am mostly concerned that channelling mid: links to browse-url will not
> work (open empty page in browser) in most cases. This is more confusing
> than not having mid: link handler at all.

Thanks.

It does not mean that browse-url "will not work" but that user did not
customize content types.

You need not think what users will customize neither you can't know what future 
brings.

Do you see that any browser could have the same strategy to maybe
forbid various URLs, but browsers mostly adopted the strategy to let
user customize how to open some URL.

>From Org side that is all, you do not hard code how to open various
links, but there shall be customization for users to decide how to
open content types.

That is what other browsers do as well.

You don't need to think of it, as you cannot control other program
from Org. 

Please allow users to set URL handlers how they want. That is
customary for decades.

Other program must know how to handle hyperlinks, if to report error,
or to warn user or to ask user how to open such URLs.

For example Elinks with

$ elinks mid:123

"This URL contains a protocol not yet known by ELinks. You can
configure an external handler for it through the options system."

or for example Firefox:

"Firefox doesn’t know how to open this address, because one of the
following protocols (mid) isn’t associated with any program or is not
allowed in this context.

You might need to install other software to open this address."

It is for me as user to set it, and not for Org to think how user is
to customize or use other software.

-- 
Jean

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

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

Re: [PATCH] lisp/ob-octave.el, was [PATCH] rfc: using ert-deftest with side-effects

[Leo Butler]

On Mon, Jan 23 2023, Ihor Radchenko  wrote:

> Ihor Radchenko  writes:
>
>> Ihor Radchenko  writes:
>>
>>> So, the test failure is real.
>>
>> The error buffer contents when the test fails is the following:
>>
>> warning: using the gnuplot graphics toolkit is discouraged
>> ...
>> [ Babel evaluation exited with code 0 ]
>>
>> Exit code is 0, so octave does finish.
>>
>> Hence, test assertion that
>> (should-not (buffer-live-p (get-buffer "*Org-Babel Error Output*")))
>> does not appear to be accurate.
>>
>> Leo, should we simply remove the assertion?
>
> I decided to remove the assertion from the tests.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=59228e51345ab522d9db611c8e73caa078d86d2f
>
> While there could be a value in making sure that ob-octave calls octave
> without generating errors, it is not strictly what the test is checking
> for.
>
> Moreover, we currently have no reliable way to disambiguate mere
> warnings from non-zero exit code.

Yes, as I said in a previous email, I can live with that.

The origin of the errors that you documented is not, I believe, due to
either of the causes suggested by either Max or you. But, investigating
obscure test failures like this is probably not the best expenditure of
time and effort.

Best regards,
Leo

Re: [Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Ihor Radchenko]

Philipp Kiefer  writes:

> * =problem 1: (repeatedly press C-c C-p starting at the bottom of the file 
> until you get up here -> point jumps up towards 'Export options' before it 
> reaches this line - or the line below. Seems to be caused by the emphasis 
> used on this line plus the fact that this heading has subitems)=

I was unable to reproduce on main doing the following:

1. Put necessary config into /tmp/bug.el

(setq org-emphasis-alist   
(quote (
("*" bold)
("/" org-verbatim)
; ("/" italic)
; ("_" underline)
("_" (:strike-through t))
("~" org-code)
; ("~" org-code verbatim)
("=" (:foreground "white" :background "dimgray"))
("+" (:foreground "white" :background "darkslateblue"))
; ("+" (:strike-through t))
)))

2. cd /path/to/Org/git/main/branch
3. make repro REPRO_ARGS="-l /tmp/bug.el"
4. Open bugs illustrated and explained.org
5. Follow the instructions

Using Emacs from master branch.

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

Re: [Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Ihor Radchenko]

Philipp Kiefer  writes:

>> You set 'invisible text property to nil, which tells Emacs - make the
>> text visible. Emacs obeys.
>
> Well, with Orgmode version 9.5, Emacs was never *this* obedient, i. e. 
> this problem only began after I updated Orgmode to 9.6, which is why I 
> considered it a bug in the first place. I am aware I have set the 
> keywords to be visible but would not expect them to appear at the end of 
> the parent heading for a folded subtree! (see the screenshots and the 
> explanatory .org file). Showing them there does not make any sense in my 
> opinion. I would expect Orgmode to hide these keywords when they are in 
> a collapsed subtree, regardless of the 'invisible text' setting, which 
> is how it was handled pre 9.6 unless I'm much mistaken.

Org may or may not do it, depending on the implementation details.
What you are seeing is because we changed the way Org is folding text to
use text properties instead of overlays (see
https://orgmode.org/Changes.html).

You may get the old behavior back by (1) Setting
`org-fold-core--optimise-for-huge-buffers' to '(grab-invisible); (2)
Setting `org-fold-core-style' to 'overlays before loading Org.

I do not consider what you report as a bug. There were ways to break Org
folding in the past (for example, by using overlays with high priority).
Actually, I am not sure why you even need to set 'invisible to nil in
your font-lock-keywords.


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

Re: [PATCH] lisp/org-agenda.el: Fix void-function string-pad in Emacs <28.1

[Aaron Zeng]

Hi Ihor, I just noticed that this patch only fixes one of the lines calling
`string-pad'.  There is another callsite below which needs to be removed.

On Tue, Jan 24, 2023 at 11:30 AM Aaron Zeng  wrote:

> Thanks for the quick response, Ihor!
>
> On Tue, Jan 24, 2023 at 4:23 AM Ihor Radchenko 
> wrote:
>
>> "Aaron L. Zeng"  writes:
>>
>> > * org-compat.el (org-string-pad): Add compatibility function
>> > `org-string-pad' for `string-pad', introduced in Emacs 28.1.
>> >
>> > * org-agenda.el (org-fix-agenda-info): Use `org-string-pad' rather
>> > than `string-pad'.
>> >
>> > Since this is more-or-less just copying string-pad's definition from
>> > subr-x.el, I think this qualifies for TINYCHANGE.
>>
>> Thanks!
>> This issue has not been caught by byte-compilation.
>>
>> I applied an alternative fix not using `string-pad' at all.
>> Canceled.
>>
>>
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5bbb97f3df9788646b8d48d60e8b8ea06566e05f
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at .
>> Support Org development at ,
>> or support my work at 
>>
>

Re: [Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Philipp Kiefer]

On 24.01.2023 12:34, Ihor Radchenko wrote:

Philipp Kiefer  writes:


Org mode version 9.6.1, GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)

Please see the two screenshots here for illustration:

https://imgur.com/a/7EuUi0J  

(I'm assuming it's not a good idea - or not even possible - to send
e-mail attachments to the list?)

Quite the opposite - attachments are preferred when they do not have
large size. With attachments, the thread can be understood by the
readers years later, when whichever image hosting you use dwindles.


Great, attaching the screenshots in question. Also attaching an .org 
file illustrating the previously reported bug plus another related (and 
more serious as it impedes org functionality) one.




This is the relevant code from my init.el that seems to be causing this
issue:

(require 'org-habit nil t) ; relevant?
(defun org-add-my-extra-fonts ()
    "Add alert and overdue fonts."
    (add-to-list 'org-font-lock-extra-keywords
'("\\(³\\)\\([^\n\r\t]+\\)\\(³\\)" (1 '(face org-habit-alert-face
invisible nil)) (2 'org-habit-alert-face t) (3 '(face
org-habit-alert-face invisible nil))) t)

You set 'invisible text property to nil, which tells Emacs - make the
text visible. Emacs obeys.


Well, with Orgmode version 9.5, Emacs was never *this* obedient, i. e. 
this problem only began after I updated Orgmode to 9.6, which is why I 
considered it a bug in the first place. I am aware I have set the 
keywords to be visible but would not expect them to appear at the end of 
the parent heading for a folded subtree! (see the screenshots and the 
explanatory .org file). Showing them there does not make any sense in my 
opinion. I would expect Orgmode to hide these keywords when they are in 
a collapsed subtree, regardless of the 'invisible text' setting, which 
is how it was handled pre 9.6 unless I'm much mistaken.


The other bug illustrated in the .org file (also requiring specific 
settings, see the init.el section in the file) breaks 
'|org-previous-visible-heading' and probably some other upwards motion 
commands||in connection with parent items having  emphasis markers as 
well as subitems.

|
* 
* Export options: (ignore - but necessary to show problem 1)
#+title: En-GK 12
#+options: ':t *:t -:t ::t <:t H:0 \n:nil ^:nil arch:headline
#+options: author:nil broken-links:nil c:nil creator:nil
#+options: d:(not "LOGBOOK") date:nil e:t email:nil f:nil inline:t num:0
#+options: p:nil pri:nil prop:nil stat:t tags:t tasks:t tex:t
#+options: timestamp:nil title:t toc:nil todo:nil |:nil html-postamble:nil
#+HTML_HEAD_EXTRA: *{font-family: Garamond !important}
#+HTML_HEAD_EXTRA: *{font-size: medium;}
#+EXCLUDE_TAGS: NE
;; [[https://www.w3schools.com/cssref/pr_font_font-size.asp][CSS font-size 
property]]* 
* 
* =problem 1: (repeatedly press C-c C-p starting at the bottom of the file 
until you get up here -> point jumps up towards 'Export options' before it 
reaches this line - or the line below. Seems to be caused by the emphasis used 
on this line plus the fact that this heading has subitems)=
** top child 1
* +top+
** top child 1
* 
* 
* 
* problem 2: the keywords appear at the end of the parent heading when the 
subtree is folded under the parent.
** ³one child with font lock extra keyword³
** @another child with further font lock extra keyword@
* 
* 
* 
* init.el code causing *problem 1*:
(setq org-emphasis-alist   
(quote (
("*" bold)
("/" org-verbatim)
; ("/" italic)
; ("_" underline)
("_" (:strike-through t))
("~" org-code)
; ("~" org-code verbatim)
("=" (:foreground "white" :background "dimgray"))
("+" (:foreground "white" :background "darkslateblue"))
; ("+" (:strike-through t))
)))
* 
* init.el code causing *problem 2*:

(defun org-add-my-extra-fonts ()
  "Add alert and overdue fonts."
  (add-to-list 'org-font-lock-extra-keywords '("\\(³\\)\\([^\n\r\t]+\\)\\(³\\)" 
(1 '(face org-habit-alert-face invisible nil)) (2 'org-habit-alert-face t) (3 
'(face org-habit-alert-face invisible nil))) t)
  (add-to-list 'org-font-lock-extra-keywords '("\\(§\\)\\([^\n\r\t]+\\)\\(§\\)" 
(1 '(face org-habit-overdue-face invisible nil)) (2 'org-habit-overdue-face t) 
(3 '(face org-habit-overdue-face invisible nil))) t)
  (add-to-list 'org-font-lock-extra-keywords '("\\(@\\)\\([^\n\r\t]+\\)\\(@\\)" 
(1 '(face org-habit-clear-face invisible nil)) (2 'org-habit-clear-face t) (3 
'(face org-habit-clear-face invisible nil))) t))
(add-hook 'org-font-lock-set-keywords-hook #'org-add-my-extra-fonts)
* 
* 

Re: [Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Philipp Kiefer]

On 24.01.2023 04:52, Ruijie Yu wrote:

Philipp Kiefer  writes:


Org mode version 9.6.1, GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)

Please see the two screenshots here for illustration:

https://imgur.com/a/7EuUi0J

(I'm assuming it's not a good idea - or not even possible - to send e-mail 
attachments to the list?)

This is the relevant code from my init.el that seems to be causing this issue:

(require 'org-habit nil t) ; relevant?
(defun org-add-my-extra-fonts ()
   "Add alert and overdue fonts."
   (add-to-list 'org-font-lock-extra-keywords 
'("\\(³\\)\\([^\n\r\t]+\\)\\(³\\)" (1 '(face org-habit-alert-face invisible 
nil)) (2 'org-habit-alert-face t) (3 '(face
org-habit-alert-face invisible nil))) t)
   (add-to-list 'org-font-lock-extra-keywords 
'("\\(§\\)\\([^\n\r\t]+\\)\\(§\\)" (1 '(face org-habit-overdue-face invisible 
nil)) (2 'org-habit-overdue-face t) (3
'(face org-habit-overdue-face invisible nil))) t)
   (add-to-list 'org-font-lock-extra-keywords 
'("\\(@\\)\\([^\n\r\t]+\\)\\(@\\)" (1 '(face org-habit-clear-face invisible 
nil)) (2 'org-habit-clear-face t) (3 '(face
org-habit-clear-face invisible nil))) t))
(add-hook 'org-font-lock-set-keywords-hook #'org-add-my-extra-fonts)

Can you reproduce it?

Thanks!

I am in a region where imgur is unavailable -- can you attach a minimal
org file where the issue manifests, and briefly describe what happens
and should happen?

Sorry, will attach such an org file in my reply to Ihor later.

Also, while looking into your init code, I noticed that
`org-font-lock-extra-keywords' seems to be public-facing (as there is no
double-dashes in the name), but has no docstring.  Either this variable
was intended to be private, or someone forgot to put a docstring to this
variable.


Thanks for making me realize that much of what is in my init.el is miles 
from 'best practice'. At the time I cobbled it together, I was just 
happy when things eventually worked the way I wanted them to and did not 
bother overmuch with proper procedure. No surprise then that it is 
coming back to bite me.


Will put in a 'defvar' statement with a docstring and rename all my 
private functions from 'org-xxx' to 'org--xxx'.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Bruno Barbier]

Jean Louis  writes:

> And not to hard code it in Org.
>
> To circumvent hard coding in Org, one can always use elisp: type of links:
>
> (defun my-handler (mid)
>  (message mid))
>
> [[elisp:(my-handler "I am ok here")][my handler]]

Org also allows the user to define his own link types:

 (info "(org) Adding Hyperlink Types")


Bruno

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Bruno Barbier]

Max Nikulin  writes:

> Thunderbird allows to save messages as an .eml file and to open it by
> thunderbird /tmp/test.eml

I'm using an extension for Thunderbird that allows to copy a direct link to a
message. I then paste it into a org file so that I can reopen the
message in one click:

   https://camiel.bouchier.be/en/cb_thunderlink


Bruno

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 24/01/2023 01:37, Jean Louis wrote:


All URLs defined by Emacs that are to be run by browse-url in Org
shall be allowed by org, to let the Emacs settings pass through.

And not to hard code it in Org.


It reminds be complains by some person that Org must be able to 
recognize any URL in free-form plain text just because there is a RFC 
describing format of URL.


Try to think from position of a developer.

An entry may be added to `browse-url-handlers' after loading of ol.

org-link and browse-url are so flexible that it would be hard to 
reliably match their entries taking into account different set of 
supported features. The former allows e.g. fuzzy search links, the 
latter something similar to Android deep links.



Configuring of "mid:" links requires just a few lines in init.el and they
are quite usual for custom links.


I have configured it, it does not work in Org


I have no idea which way you configured mid: links in Org, but this 
thread contains 5 lines that successfully works for me.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Dirk-Jan C. Binnema]

On Tuesday Jan 24 2023, Ihor Radchenko wrote:

>> To make it work through browse-url (is that useful?) shouldn't be too
>> hard to configure `browse-url-default-handlers' for that. For mu4e that
>> could simply use `mu4e-org-open', except that mu4e uses `msgid' (a
>> better name imho) rather than `mid'.
>
> mid: if a known standard, as Max pointed in the earlier message:
>
> RFC 2392 - Content-ID and Message-ID Uniform Resource Locators. 1998
> https://tools.ietf.org/html/rfc2392
>
> It makes more sense than arbitrary ideas not known to anyone, even if
> they sound better for some users.

Thanks, no arguing with that, at least not without involving a
time-machine.

Kind regards,
Dirk.

-- 
Dirk-Jan C. Binnema  Helsinki, Finland
e:d...@djcbsoftware.nl   w:www.djcbsoftware.nl
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Max Nikulin]

On 22/01/2023 14:48, Tim Cross wrote:

Timestamp for a log
record I would probably want  or one of the
variants because the most common way I use those types of timestamp is
in diagnosing problems and comparing revords from various locations
where I don't care about the local time where the record was generated,
but with when it occurred in relation to other log recores.


I agree that it is more convenient to have uniform offset in such case, 
especially in the case of multiple files having their specific timezone. 
During trips I do not expect so much changes of timezone to make 
comparison of timestamps significantly harder.



I would argue that all depends on how you use the information. My org
files are consumed by me (reading) and by scripts, elisp and other
programs.


For scripts given offset should not be an issue at all. And it is up to 
you if you prefer to have UTC instead of local time offset in you files.



My preference is for a timestamp syntax which lets the user select the
format they want and not attempt to restrict it more than that.


I do not mind to provide a user option for preferred storage format used 
for clock entries and similar stuff.



Provided
you can specify timestamp with and without TZ information and you
support full and abbreviated time zone names as well as UTC, I don't
think it mattters - let the user choose what suits them best.


Concerning time zone abbreviations, I would discourage them as much as 
possible for storage format. They may be added to overlay though. 
Perhaps US residents would be unhappy by such decision, but there are 
enough examples of the same abbreviation for completely unrelated 
locations. Abbreviation may be useful in addition to timezone ID to 
disambiguate local time close to a backward time jump.


Tim, in your last messages I do not see statements causing my objections 
any more. It seems we came to agreement: flexible enough storage format 
and configurable display format for overlays. Have I forgot anything?

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Thomas S. Dye]

Aloha Ihor,

Ihor Radchenko  writes:


"Thomas S. Dye"  writes:

I understand above that it is easier understandable when 
reading
[2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I 
guess 
Max)

that user will understand that there is +11 hours ahead.

Yes, the offset here is ambiguous--is it offset from some 
timezone 
or from UTC?


It is not ambiguous if the user is familiar with standard time 
format.

The representation above is derived from
https://en.wikipedia.org/wiki/ISO_8601, which allows the 
following:


Z

If the time is in UTC, add a Z directly after the time 
without a space.
Z is the zone designator for the zero UTC offset. "09:30 
UTC" is
therefore represented as "09:30Z" or "T0930Z". "14:45:15 
UTC" would be

"14:45:15Z" or "T144515Z".

±hh:mm
±hhmm
±hh

The UTC offset is appended to the time in the same way that 
'Z' was

above, in the form ±[hh]:[mm], ±[hh][mm], or ±[hh].

Negative UTC offsets describe a time zone west of UTC±00:00, 
where the
civil time is behind (or earlier) than UTC so the zone 
designator will

look like "−03:00","−0300", or "−03".

Positive UTC offsets describe a time zone at or east of 
UTC±00:00, where
the civil time is the same as or ahead (or later) than UTC 
so the zone

designator will look like "+02:00","+0200", or "+02".



Got it.  Thanks for the full explanation!  The ambiguity I 
mentioned was due to my ignorance of the time standard format 
variants.


Here is a proposal for a terminology of events that honors 
Ramsey's distinction between events and occurrences and hopes 
to 
cover all of Org's use cases.

...
...
The Org user should be able to toggle timestamp representation. 
In the case of a no-host event, user might toggle between UTC 
and 
local time.  In the case of situated or itinerant event, user 
might toggle among UTC, local time, and local time at the event 
site.


Instead of toggling, would it be better to echo the different 
formats

like eldoc does + mouse-echo?


Or both?  Toggling globally and echoing individually, IIUC?

All the best,
Tom

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

Re: [PATCH] lisp/org-agenda.el: Fix void-function string-pad in Emacs <28.1

[Aaron Zeng]

Thanks for the quick response, Ihor!

On Tue, Jan 24, 2023 at 4:23 AM Ihor Radchenko  wrote:

> "Aaron L. Zeng"  writes:
>
> > * org-compat.el (org-string-pad): Add compatibility function
> > `org-string-pad' for `string-pad', introduced in Emacs 28.1.
> >
> > * org-agenda.el (org-fix-agenda-info): Use `org-string-pad' rather
> > than `string-pad'.
> >
> > Since this is more-or-less just copying string-pad's definition from
> > subr-x.el, I think this qualifies for TINYCHANGE.
>
> Thanks!
> This issue has not been caught by byte-compilation.
>
> I applied an alternative fix not using `string-pad' at all.
> Canceled.
>
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5bbb97f3df9788646b8d48d60e8b8ea06566e05f
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 23/01/2023 20:59, AW wrote:

I have done that now without result. But I'll write an E-Mail to the
developers of kmail.


Thank you for filing a feature request.


As long as notmuch, notmuch.el and ol-notmuch are there we have a viable
solution, thanks to this (undocumented) trick with notmuch:id:123abc, after
getting the id by opening the mail with notmuch in emacs and »c I«.


Less than dozen lines of code in init.el (configure mid: links in Org 
and install notmuch handler for `browse-url') should allow referencing 
messages in a MUA agnostic way at least by Message-ID. Emacs mail 
clients allows other queries, but likely there is no standard for them.


This is weird since ever. I've been talking to some collegues and everybody 
has his/her own special approach. Mostly producing a PDF from the E-Mail and 
saving this and its attachments somewhere. That's a thing that bothered me for 
decades. 


Thunderbird allows to save messages as an .eml file and to open it by

thunderbird /tmp/test.eml

Gmail web application allows .eml export as well. In some cases it is an 
alternative to PDF.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 24/01/2023 16:42, Ihor Radchenko wrote:

Max Nikulin writes:


On 23/01/2023 17:40, Ihor Radchenko wrote:

I am not even sure if we need to make Org open mid: links via
`browse-url'. Maybe it should be something else? IDK.


Do you know an alternative?

...

I am mostly concerned that channelling mid: links to browse-url will not
work (open empty page in browser) in most cases. This is more confusing
than not having mid: link handler at all.


For me it may be a reason to not enable to enable "mid:" links by 
default, but I am still considering `browse-url' as the proper handler.


Code to determine handler is platform-specific, e.g. for Linux

xdg-mime query default x-scheme-handler/mid
xdg-settings get default-url-scheme-handler mid

The latter actually calls the former. I would avoid both variants during 
load time.


If you get browser fallback then you are advanced enough user to avoid a 
DE. Gnome shows application selection dialog, KDE throws an error window.

[PATCH] Change default value of org-clock-x11-idle-program-name

[Ihor Radchenko]

Ihor Radchenko  writes:

> What we can do is check if xprintidle executable is available and use
> it. Otherwise, fall back to x11idle to retain backwards compatibility on
> systems that do no have xprintidle installed.

See the attached patch.

>From 6fe58852f30b7bd8d217bf228252dc97abd05153 Mon Sep 17 00:00:00 2001
Message-Id: <6fe58852f30b7bd8d217bf228252dc97abd05153.1674564051.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Tue, 24 Jan 2023 15:38:26 +0300
Subject: [PATCH] org-clock-x11idle-program-name: Prefer "xprintidle", when
 available

* lisp/org-clock.el (org-clock-x11idle-program-name): Change the
default value to "xprintidle" when its executable is available.
Fallback to previous default otherwise.  Update :package-version and
remove :version tags.
* etc/ORG-NEWS (New and changed options):
(~org-clock-x11idle-program-name~ now defaults to =xprintidle=, when available):
Document the change.

Link: https://orgmode.org/list/874jvkn1po.fsf@localhost
---
 etc/ORG-NEWS  | 11 ++-
 lisp/org-clock.el |  7 ---
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 3ef76ec1a..d65592a2b 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -12,7 +12,16 @@ See the end of the file for license conditions.
 Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
-** New options
+** New and changed options
+*** ~org-clock-x11idle-program-name~ now defaults to =xprintidle=, when available
+
+When =xprintidle= executable is available at =org-clock= load time, it
+is used as the default value for ~org-clock-x11idle-program-name~.
+The old =x11idle= default is used as the fallback.
+
+=xprintidle= is available as system package in most Linux
+distributions, unlike ancient =x11idle= that is distributed via WORG.
+
 *** New options for the "csl" citation export processor's LaTeX output
 
 The ~org-cite-csl-latex-label-separator~ and
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 0cd473209..ceb1fc833 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -439,7 +439,9 @@ (defcustom org-clock-frame-title-format '(t org-mode-line-string)
   :group 'org-clock
   :type 'sexp)
 
-(defcustom org-clock-x11idle-program-name "x11idle"
+(defcustom org-clock-x11idle-program-name
+  (if (executable-find "xprintidle")
+  "xprintidle" "x11idle")
   "Name of the program which prints X11 idle time in milliseconds.
 
 you can do \"~$ sudo apt-get install xprintidle\" if you are using
@@ -448,8 +450,7 @@ (defcustom org-clock-x11idle-program-name "x11idle"
 Alternatively, can find x11idle.c in
 https://orgmode.org/worg/code/scripts/x11idle.c;
   :group 'org-clock
-  :version "24.4"
-  :package-version '(Org . "8.0")
+  :package-version '(Org . "9.7")
   :type 'string)
 
 (defcustom org-clock-goto-before-context 2
-- 
2.39.1



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

Re: [Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Ihor Radchenko]

Ruijie Yu via "General discussions about Org-mode."
 writes:

> Also, while looking into your init code, I noticed that
> `org-font-lock-extra-keywords' seems to be public-facing (as there is no
> double-dashes in the name), but has no docstring.  Either this variable
> was intended to be private, or someone forgot to put a docstring to this
> variable.

Rather forgot the docstring. But there is at least one in
`org-font-lock-set-keywords-hook'.

In any case, Org's fontification is going to be rewritten. So, I do not
think that we should fix this now and limit the possible changes
possible in the new fontification code.

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

Re: [Bug] 'org-font-lock-extra-keywords' appear next to the parent heading when its subtree is folded.

[Ihor Radchenko]

Philipp Kiefer  writes:

> Org mode version 9.6.1, GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)
>
> Please see the two screenshots here for illustration:
>
> https://imgur.com/a/7EuUi0J 
>
> (I'm assuming it's not a good idea - or not even possible - to send 
> e-mail attachments to the list?)

Quite the opposite - attachments are preferred when they do not have
large size. With attachments, the thread can be understood by the
readers years later, when whichever image hosting you use dwindles.

> This is the relevant code from my init.el that seems to be causing this 
> issue:
>
> (require 'org-habit nil t) ; relevant?
> (defun org-add-my-extra-fonts ()
>    "Add alert and overdue fonts."
>    (add-to-list 'org-font-lock-extra-keywords 
> '("\\(³\\)\\([^\n\r\t]+\\)\\(³\\)" (1 '(face org-habit-alert-face 
> invisible nil)) (2 'org-habit-alert-face t) (3 '(face 
> org-habit-alert-face invisible nil))) t)

You set 'invisible text property to nil, which tells Emacs - make the
text visible. Emacs obeys.

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Ihor Radchenko]

"Dirk-Jan C. Binnema"  writes:

> Sorry if I'm repeating things earlier mentioned...
>
> mu4e supports message-id links through org-mode, and I *extensively*
> use that my agenda / todo lists. E.g.,
>mu4e:msgid:CACwzTKkeyptMcOA=jq8y23948-fkyfkmtwu...@mail.gmail.com

Ideally, we need not to think which mail client to open the link in.
Be it notmuch or mu4e or some other OS email client outside Emacs.

mu4e: or notmuch: links are more specific in this regard.

> To make it work through browse-url (is that useful?) shouldn't be too
> hard to configure `browse-url-default-handlers' for that. For mu4e that
> could simply use `mu4e-org-open', except that mu4e uses `msgid' (a
> better name imho) rather than `mid'.

mid: if a known standard, as Max pointed in the earlier message:

RFC 2392 - Content-ID and Message-ID Uniform Resource Locators. 1998
https://tools.ietf.org/html/rfc2392

It makes more sense than arbitrary ideas not known to anyone, even if
they sound better for some users.

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Dirk-Jan C. Binnema]

On Tuesday Jan 24 2023, Ihor Radchenko wrote:

> AW  writes:
>
>>> It is not up to Org. Try
>>> 
>>>  (browse-url "mid:3218434.44cspzl...@linux.fritz.box")
>>> 
>>> You will likely see nothing.
>>
>> Well, M-x  (browse-url "mid:3218434.44cspzl...@linux.fritz.box") 
>> produces [No match].
>
> This is not a command.
> You need M-: (...
>
>>> So, while Org may provide some limited help with mid:, as Max suggested,
>>> there is no way to guarantee that mid: links will work for all users
>>> without users hand-customizing how to open emails.
>>> 
>>> I am not even sure if we need to make Org open mid: links via
>>> `browse-url'. Maybe it should be something else? IDK.
>>
>> This is weird since ever. I've been talking to some collegues and everybody 
>> has his/her own special approach. Mostly producing a PDF from the E-Mail and 
>> saving this and its attachments somewhere. That's a thing that bothered me 
>> for 
>> decades. 
>
> Well. The more widely used standard is Maildir - downloading emails from
> server to local machine. Emails are just files there that can be indexed
> by variety of mail client software.
>
> The main question is which email clients actually support mid: links.
> notmuch does, but in non-standard way, without doing it system-wide.

Sorry if I'm repeating things earlier mentioned...

mu4e supports message-id links through org-mode, and I *extensively*
use that my agenda / todo lists. E.g.,
   mu4e:msgid:CACwzTKkeyptMcOA=jq8y23948-fkyfkmtwu...@mail.gmail.com

To make it work through browse-url (is that useful?) shouldn't be too
hard to configure `browse-url-default-handlers' for that. For mu4e that
could simply use `mu4e-org-open', except that mu4e uses `msgid' (a
better name imho) rather than `mid'.

Kind regards,
Dirk.

-- 
Dirk-Jan C. Binnema  Helsinki, Finland
e:d...@djcbsoftware.nl   w:www.djcbsoftware.nl
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036

[BUG] #+cite_export: ... bibstyle citestyle cannot be universally used as global defaults (was: Patch for \usepackage[ ... natbib = true ...]{...biblatex} with org-cite)

[Ihor Radchenko]

Edgar Lux  writes:

> I thought that it would be preferable to have a native Org syntax.
>
>> I do not like passing the options as-is in #+cite_export because not all
>> the possible biblatex \usepackage options are affecting the
>> bibliography. Options like sortcites, maxcitenames, autocite, etc are
>> only affecting the citation style, not the bibliography. And options
>> like bibencoding are totally irrelevant to both citation and
>> bibliography styles.
>
> That's fair, but it can just as well be used as a line to configure biblatex 
> (since it is already being used anyway). Besides, there are many other 
> options which do concern the style or are very needed 
> (hyperref=true,backref=true,url=true,backend=biber,natbib=true). I'm not 
> advocating for my suggestion, just showing my reasoning. As I said, I'm fine 
> with the =#+latex_header:=.

I understand. My takeaway from here is that there is a need to provide
extended global defaults for both bibliography style and citation style.

>> This code is by Nicolas, but does not seem to be consistent with the
>> idea of "BIBLIOGRAPHY STYLE".
>>
>> I am CCing him in cause if there is something I am missing.
>
> The docstring says:
>
> ;; "cite_export" keyword.  If you need to use different styles for 
> bibliography
> ;; and citations, you can separate them with "bibstyle/citestyle" syntax. 
>  E.g.,
> ;;
> ;;   #+cite_export: biblatex authortitle/authortitle-ibid

Which is a questionable design choice. I was referring to higher-level
docstring for `org-cite-export-processors':

  (NAME BIBLIOGRAPHY-STYLE CITATION-STYLE)

There, NAME is the name of a registered citation processor providing export
functionality, as a symbol.  BIBLIOGRAPHY-STYLE (respectively 
CITATION-STYLE)
is the desired default style to use when printing a bibliography 
(respectively
exporting a citation), as a string or nil.  Both BIBLIOGRAPHY-STYLE and
CITATION-STYLE are optional.  NAME is mandatory.

oc-biblatex simply deviates from the global paradigm, making oc-biblatex
special compared to other citation processors. Not ideal.

I think that we have a fundamental design flaw with org-cite:

#+cite_export: processor bibliography-style citation-style

introduces:

 - default bibliography style set document-wide
 - default citation style set individually in every citation via
  low-level commands, BUT NOT GLOBAL DEFAULT CITATION STYLE.

Basically, CITATION_STYLE cannot currently affect document preamble by
design.

That's why awkward workarounds in oc-biblatex, where default citation
style can be set globally, and we have to attach citation style to
BIBLIOGRAPHY_STYLE keyword.

I suggest the following changes to the org-cite:

1. :export-finalizer should accept export processor triplet instead of
   bibliography style as 4th argument. The assumption that only
   bibliography style is required to finalize the export is clearly not
   accurate.

2. Allow passing extra arguments in #+cite_export:

#+cite_export: processor[opt1=val1,opt2=val2,...] bibliography-style[...] 
citation-style[...]

  The options listed within the square brackets will pass extra default options
  to the processor/styles and used as needed by citation processor 
implementations.

WDYT?

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

Re: Feature request: "task table" (similar to clock table)

[Ihor Radchenko]

Marcin Borkowski  writes:

> https://mbork.pl/2023-01-09_TODO_stats_table

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

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Ihor Radchenko]

AW  writes:

> As long as notmuch, notmuch.el and ol-notmuch are there we have a viable 
> solution, thanks to this (undocumented) trick with notmuch:id:123abc

This is not undocumented. ol-notmuch provides notmuch:
links. id:message-id is a valid search term in notmuch. See
https://notmuchmail.org/searching/

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Ihor Radchenko]

Max Nikulin  writes:

> On 23/01/2023 17:40, Ihor Radchenko wrote:
>> I am not even sure if we need to make Org open mid: links via
>> `browse-url'. Maybe it should be something else? IDK.
>
> Do you know an alternative? Org already uses this package to open some 
> types of links. It allows to have the same handler for all Emacs 
> packages. I do not think that Org-specific handler would be better.

I am mostly concerned that channelling mid: links to browse-url will not
work (open empty page in browser) in most cases. This is more confusing
than not having mid: link handler at all.

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Ihor Radchenko]

AW  writes:

>> It is not up to Org. Try
>> 
>>  (browse-url "mid:3218434.44cspzl...@linux.fritz.box")
>> 
>> You will likely see nothing.
>
> Well, M-x  (browse-url "mid:3218434.44cspzl...@linux.fritz.box") 
> produces [No match].

This is not a command.
You need M-: (...

>> So, while Org may provide some limited help with mid:, as Max suggested,
>> there is no way to guarantee that mid: links will work for all users
>> without users hand-customizing how to open emails.
>> 
>> I am not even sure if we need to make Org open mid: links via
>> `browse-url'. Maybe it should be something else? IDK.
>
> This is weird since ever. I've been talking to some collegues and everybody 
> has his/her own special approach. Mostly producing a PDF from the E-Mail and 
> saving this and its attachments somewhere. That's a thing that bothered me 
> for 
> decades. 

Well. The more widely used standard is Maildir - downloading emails from
server to local machine. Emails are just files there that can be indexed
by variety of mail client software.

The main question is which email clients actually support mid: links.
notmuch does, but in non-standard way, without doing it system-wide.

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

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Ihor Radchenko]

"Thomas S. Dye"  writes:

>> I understand above that it is easier understandable when reading
>> [2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I guess 
>> Max)
>> that user will understand that there is +11 hours ahead.
>>
> Yes, the offset here is ambiguous--is it offset from some timezone 
> or from UTC?

It is not ambiguous if the user is familiar with standard time format.
The representation above is derived from
https://en.wikipedia.org/wiki/ISO_8601, which allows the following:

Z

If the time is in UTC, add a Z directly after the time without a space.
Z is the zone designator for the zero UTC offset. "09:30 UTC" is
therefore represented as "09:30Z" or "T0930Z". "14:45:15 UTC" would be
"14:45:15Z" or "T144515Z".

±hh:mm
±hhmm
±hh

The UTC offset is appended to the time in the same way that 'Z' was
above, in the form ±[hh]:[mm], ±[hh][mm], or ±[hh].

Negative UTC offsets describe a time zone west of UTC±00:00, where the
civil time is behind (or earlier) than UTC so the zone designator will
look like "−03:00","−0300", or "−03".

Positive UTC offsets describe a time zone at or east of UTC±00:00, where
the civil time is the same as or ahead (or later) than UTC so the zone
designator will look like "+02:00","+0200", or "+02".

> Here is a proposal for a terminology of events that honors 
> Ramsey's distinction between events and occurrences and hopes to 
> cover all of Org's use cases.
> ...
> ...
> The Org user should be able to toggle timestamp representation. 
> In the case of a no-host event, user might toggle between UTC and 
> local time.  In the case of situated or itinerant event, user 
> might toggle among UTC, local time, and local time at the event 
> site.

Instead of toggling, would it be better to echo the different formats
like eldoc does + mouse-echo?

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

Re: [PATCH] lisp/org-agenda.el: Fix void-function string-pad in Emacs <28.1

[Ihor Radchenko]

"Aaron L. Zeng"  writes:

> * org-compat.el (org-string-pad): Add compatibility function
> `org-string-pad' for `string-pad', introduced in Emacs 28.1.
>
> * org-agenda.el (org-fix-agenda-info): Use `org-string-pad' rather
> than `string-pad'.
>
> Since this is more-or-less just copying string-pad's definition from
> subr-x.el, I think this qualifies for TINYCHANGE.

Thanks!
This issue has not been caught by byte-compilation.

I applied an alternative fix not using `string-pad' at all.
Canceled.

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

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

Re: org-crypt fails if default key is expired while non-default key is to be used

[Ihor Radchenko]

Karl Voit  writes:

>> May I know how exactly did you set `org-crypt-key'? Do you happen to
>> have CRYPTKEY properties somewhere in your buffer?
>
> Sure. My config is on
> https://github.com/novoid/dot-emacs/blob/master/config.org and I've
> set it with:
>
> (setq org-crypt-key "ABC12345")  ;; I may have to mask this online as well ;-)

What is the return value of

(epg-list-keys (epg-make-context nil t t) org-crypt-key)

?

Does it show the right key?

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