Re: Remove old WORG page with Org Syntax (draft) in favour of new syntax page by Timothy

[Timothy]

Hi Ihor,

> I am in favour of removing the old version completely and putting the
> new document at the old address
> 
>
> The old version will remain accessible via git logs if absolutely
> necessary.

That sounds good to me.

All the best,
Timothy

Re: org-agenda todos list sorted by earliest deadline first

[Ihor Radchenko]

Sébastien Gendre  writes:

> If I evaluate the same setq and define the same tasks, my result withe 
> org-agenda tasks list are:
>
> Global list of TODO items of type: ALL
> Press ‘N r’ (e.g. ‘0 r’) to search again: (0)[A$
>   (1)TODO (2)DONE
>   test:   TODO test1
>   test:   TODO test2
>   test:   TODO test3
>   test:   TODO test4
>
> I tested at this moment with Org version 9.5.2 on Emacs version 27.2

I am unable to reproduce using Emacs 27.2 + latest Org main or bugfix.
Can you try to reproduce starting from emacs -Q?
See https://orgmode.org/manual/Feedback.html or
https://open.tube/videos/watch/4d819114-43bf-42df-af94-f94fc53dd0d9 for
detailed instructions.

Best,
Ihor

Re: org-agenda todos list sorted by earliest deadline first

[Sébastien Gendre]

Tested with "emacs -q", I got the same result.



Le 5 avril 2022 09:14:43 GMT+02:00, Ihor Radchenko  a écrit 
:
>Sébastien Gendre  writes:
>
>> If I evaluate the same setq and define the same tasks, my result withe 
>> org-agenda tasks list are:
>>
>> Global list of TODO items of type: ALL
>> Press ‘N r’ (e.g. ‘0 r’) to search again: (0)[A$
>>   (1)TODO (2)DONE
>>   test:   TODO test1
>>   test:   TODO test2
>>   test:   TODO test3
>>   test:   TODO test4
>>
>> I tested at this moment with Org version 9.5.2 on Emacs version 27.2
>
>I am unable to reproduce using Emacs 27.2 + latest Org main or bugfix.
>Can you try to reproduce starting from emacs -Q?
>See https://orgmode.org/manual/Feedback.html or
>https://open.tube/videos/watch/4d819114-43bf-42df-af94-f94fc53dd0d9 for
>detailed instructions.
>
>Best,
>Ihor

Re: Remove old WORG page with Org Syntax (draft) in favour of new syntax page by Timothy

[Ihor Radchenko]

Timothy  writes:

>> I am in favour of removing the old version completely and putting the
>> new document at the old address
>> 
>>
>> The old version will remain accessible via git logs if absolutely
>> necessary.
>
> That sounds good to me.

Note that I don't have write access to WORG. I guess you or Nicolas can
commit the change.

P.S. Christian also mentioned his confusion that both org-syntax and Org
manual contain syntax descriptions and it is unclear which document to
use. We may add a paragraph to org-syntax document mentioning that it
is very technical and aims for developers + reference Org manual for
ordinary users.

Best,
Ihor

Re: Remove old WORG page with Org Syntax (draft) in favour of new syntax page by Timothy

[Timothy]

Hi Ihor,

> Note that I don’t have write access to WORG. I guess you or Nicolas can
> commit the change.

Done

> P.S. Christian also mentioned his confusion that both org-syntax and Org
> manual contain syntax descriptions and it is unclear which document to
> use. We may add a paragraph to org-syntax document mentioning that it
> is very technical and aims for developers + reference Org manual for
> ordinary users.

I’ve added:

  This is intended as a technical document for developers and
  those particularly interested in the syntax. Most users will be better
  served by [the Org manual].

to the intro.

All the best,
Timothy


[the Org manual] 

Agenda without todos only if there is no other timestamp

[Karl Voit]

Hi,

I've got following custom agenda for exporting:

| ("n" "no TODO events +180d"
|  ((agenda "no TODO events +180d"
|   ((org-agenda-span 180)
|(org-agenda-time-grid nil)
|(org-agenda-entry-types '(:timestamp :sexp))
|(org-agenda-skip-function
| '(or
|   (org-agenda-skip-entry-if 'todo 'any);; skip if any TODO state 
is found
|   (org-agenda-skip-entry-if 'category "errors");; skip if any 
TODO state is found
|   (my-skip-tag "lp")
|   )
|  nil (,(concat my-org-files-path "agenda_180d_filtered_raw.html")))

(don't mind the stupid name - I may fix this as it is misleading
here)

This results in an HTML file that contains my appointments without the tasks.

Unfortunately, I sometimes seem to schedule appointments within open todos such 
as:

| * NEXT talk with Steve about the project X
| SCHEDULED: <2022-04-05 Tue>
| 
| - [X] ask him for a time-slot
| - we settled for: <2022-04-05 Tue 14:00-15:00>

Of course, those appointments are lost in my agenda export as
specified above. This is a bummer and I want to fix this somehow.

Tasks should be omitted only if there is no other time-stamp than
deadline or scheduled.

org-agenda-skip-if lists:
| scheduled Check if there is a scheduled cookie
| notscheduled  Check if there is no scheduled cookie
| deadline  Check if there is a deadline
| notdeadline   Check if there is no deadline
| timestamp Check if there is a timestamp (also deadline or scheduled)
| nottimestamp  Check if there is no timestamp (also deadline or scheduled)
| regexpCheck if regexp matches
| notregexp Check if regexp does not match.
| todo  Check if TODO keyword matches
| nottodo   Check if TODO keyword does not match

How is it possible to accomplish this? I think this would require
something like "Check if there is a timestamp (except deadline or
scheduled)" which isn't available yet.

Any ideas on that one?

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: problem with diary sexps

[Christian Stuermer]

Hello!

Eric S Fraga writes:


I updated org today and now get

Bad sexp at line 461 in /home/ucecesf/s/notes/diary.org:
(let ((entry ) (date '(4 19 2022))) (diary-float t 2 3))

for a line that looks like

<%%(diary-float t 2 3)>

This has been in my diary for a very long time with no error.  I wonder
if this has anything to do with the changes to the use of advice?
Nothing else in the recent changes in the git log seem to be relevant.



I've had the same problem after updating org from git with entries like

%%(org-anniversary 2000 4 4) X is %d years old


The commit introducing it is
https://github.com/bzg/org-mode/commit/6d73cd34a07796c33f9435bfc8c9a19e67656c7a

And the problem is gone, after reverting

 (result (if calendar-debug-sexp (eval sexp t)
   (condition-case nil
   (eval sexp t)

back to

 (result (if calendar-debug-sexp (eval sexp)
   (condition-case nil
   (eval sexp)

in org-diary-sexp-entry in org.el.

I wrote about in on Reddit:
https://www.reddit.com/r/orgmode/comments/tvwxv0/the_commit_on_apr_1_2022_broke_organniversary_for/

Kind regards,
Christian

[BUG] Exporting italic link with bang inside to html fails to parse the link [9.5.2 (N/A @ /gnu/store/89yvbijwnvsbpa5h33mvbgh1gy9w30n2-emacs-org-9.5.2/share/emacs/site-lisp/org-9.5.2/)]

[Dr. Arne Babenhauserheide]

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.


To reproduce:

- create an org-file with the following content:
/Foo [[https://taz.de/!5843294/][link with a bang]]/
- M-x org-html-export-to-html

Expected: The HTML-file contains an italic link named "link with a bang".

Actual: The HTML-file contains a broken link with only the domain:
Foo [[https://taz.de";>https://taz.de!5843294/][link with a 
bang]]/

Best wishes,
Arne

Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, 
cairo version 1.16.0)
Package: Org mode version 9.5.2 (N/A @ 
/gnu/store/89yvbijwnvsbpa5h33mvbgh1gy9w30n2-emacs-org-9.5.2/share/emacs/site-lisp/org-9.5.2/)
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: problem with diary sexps

[Eric S Fraga]

On Tuesday,  5 Apr 2022 at 12:28, Christian Stuermer wrote:
> I've had the same problem after updating org from git with entries like
> The commit introducing it is
> https://github.com/bzg/org-mode/commit/6d73cd34a07796c33f9435bfc8c9a19e67656c7a
>
> And the problem is gone, after reverting
>
> (result (if calendar-debug-sexp (eval sexp t)
>   (condition-case nil
>   (eval sexp t)
>
> back to
>
> (result (if calendar-debug-sexp (eval sexp)
>   (condition-case nil
>   (eval sexp)
>
> in org-diary-sexp-entry in org.el.

Confirmed.  Reverting this particular change makes diary sexps work
again properly (i.e. without complaint).

Thank you,
eric

-- 
: Eric S Fraga, with org release_9.5.2-423-g6d73cd in Emacs 29.0.50

Re: problem with diary sexps

[Ihor Radchenko]

Christian Stuermer  writes:

> And the problem is gone, after reverting
>
>(result (if calendar-debug-sexp (eval sexp t)
>  (condition-case nil
>  (eval sexp t)
>
> back to
>
>(result (if calendar-debug-sexp (eval sexp)
>  (condition-case nil
>  (eval sexp)
>
> in org-diary-sexp-entry in org.el.

More accurate error can be found after setting calendar-debug-sexp to t.
I got the following backtrace clearly indicating lexical scope issue:

Debugger entered--Lisp error: (void-variable entry)
  (diary-float t 2 1)
  (let ((entry "") (date '(4 5 2022))) (diary-float t 2 1))
  (eval (let ((entry "") (date '(4 5 2022))) (diary-float t 2 1)) t)

Best,
Ihor

Re: problem with diary sexps

[Eric S Fraga]

On Tuesday,  5 Apr 2022 at 19:22, Ihor Radchenko wrote:
> More accurate error can be found after setting calendar-debug-sexp to t.
> I got the following backtrace clearly indicating lexical scope issue:

Which makes sense.  The diary code does use entry and date as global
variables so really needs updating...

-- 
: Eric S Fraga, with org release_9.5.2-423-g6d73cd in Emacs 29.0.50

[PATCH] Document custom org agenda functions

[thecashewtrader]

---
 org-tutorials/org-custom-agenda-commands.org | 40 +++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/org-tutorials/org-custom-agenda-commands.org 
b/org-tutorials/org-custom-agenda-commands.org
index e54bcef3..5b55ebb5 100644
--- a/org-tutorials/org-custom-agenda-commands.org
+++ b/org-tutorials/org-custom-agenda-commands.org
@@ -64,7 +64,7 @@ command is a list consisting of the following:
 (optional).
 - 3) Type of search :: The desired agenda display/search. The options
  include agenda, todo, search, tags, alltodo, tags-todo,
- todo-tree, tags-tree, occur-tree, or a user-defined function.
+ todo-tree, tags-tree, occur-tree, or a [[*User Defined 
Functions][user-defined function]].
 - 4) Search term :: Depending on the type of search, this will be a
 TODO keyword, a tag (or property), a word, or a
 regular expression.
@@ -372,6 +372,44 @@ deadlines and nothing else.
 Tip: if you want to exclude all agenda entry types, just set
 =org-agenda-entry-types= to nil.
 
+* User Defined Functions
+** Function Signature
+User defined functions should:
+
+- Optionally accept one parameter i.e. the =match= variable. The Org agenda 
dispatch function will call the user-defined function with one parameter 
representing the =match= component from the agenda definition. In other words, 
~(udf/test "Hello")~ in =org-agenda-custom-commands= will result in a function 
call of ~udf/test~ with an argument of ="Hello"=.
+
+- Prepare a buffer to write the agenda information to using 
~org-agenda-prepare~.
+
+- Handle setting a unique buffer name for the cases where =org-agenda-sticky= 
has a value of =t=.
+
+- Honor the setting of =org-agenda-overriding-header= and insert that text 
into the agenda buffer. This can be done using the macro 
~org-agenda--insert-overriding-header~.
+
+- Insert into the buffer the desired contents, accounting for also setting 
text properties.
+
+- Call ~org-agenda-finalize~ and ~(setq buffer-read-only t)~
+
+** Example
+This is a simple function to insert notes into the Agenda.
+
+*NOTE: This example is not fully complete as it doesn't respect 
=org-agenda-sticky=.*
+
+#+begin_src emacs-lisp
+
+(defun udf/org-agenda-notes (&optional arg)
+  (org-agenda-prepare "Notes")
+  (org-agenda--insert-overriding-header "Notes")
+  (let ((org-agenda-notes
+ (list "Note 1"
+   "Note 2"
+   "Note 3")))
+(dolist (note org-agenda-notes)
+  (insert (format "- %s\n" note
+  (org-agenda-finalize)
+  (setq buffer-read-only t))
+
+#+end_src
+
+
 * Other configuration ideas
 
 This section is for additional ideas for configuring
-- 
2.35.1

Re: org-cite styles don't allow * in them

[Bruce D'Arcus]

On Sun, Apr 3, 2022 at 5:07 PM John Kitchin  wrote:
>
> I was looking into using latex commands as styles in org-cite, e.g.
>
> [cite/citet:@key]. That example works fine, but [cite/citet*:@key] is not 
> allowed. Could that be allowed?

I have no insight into the restriction, but I hope it can be removed.

It occurs to me in that scenario it should be easy to write a function
that allows users to toggle between the two sets of styles: the direct
latex ones, and the more general default org-cite ones.

Bruce

Re: problem with diary sexps

[Max Nikulin]

On 05/04/2022 18:22, Ihor Radchenko wrote:

Christian Stuermer writes:


And the problem is gone, after reverting

 (result (if calendar-debug-sexp (eval sexp t)
   (condition-case nil
   (eval sexp t)

back to

 (result (if calendar-debug-sexp (eval sexp)
   (condition-case nil
   (eval sexp)

in org-diary-sexp-entry in org.el.


More accurate error can be found after setting calendar-debug-sexp to t.
I got the following backtrace clearly indicating lexical scope issue:

Debugger entered--Lisp error: (void-variable entry)
   (diary-float t 2 1)
   (let ((entry "") (date '(4 5 2022))) (diary-float t 2 1))
   (eval (let ((entry "") (date '(4 5 2022))) (diary-float t 2 1)) t)


It looks like the source of the problem with unit tests that I faced 
yesterday trying to look closer at the bug with daylight saving time in 
agenda.


Bad sexp at line 25 in /home/ubuntu/src/org-mode/testing/examples
/agenda-file.org: (let ((entry ) (date '(3 25 2022))) (diary-date 3 25 
2022))


 ((should
   (= 3
  (count-lines ... ...)))
  :form

   FAILED  255/900  test-org-agenda/property-timestamp (2.018120 sec)

Emacs-27.3

Re: org-cite styles don't allow * in them

[John Kitchin]

Would you find it suitable to use [cite/command:pre @key post] in general?
For portability, I suppose there could be a defcustom mapping if one wanted
to leverage the oc-csl library with pretty minimal effort.

I think two things need to be addressed to fix that. First is allowing a *
in the style/variant section; there are probably 17 or so of these commands
in natbib/biblatex. Second is fixing org-activate-link so that link
activation functions don't get called on something like [cite/citet:@key].
This is necessary for org-ref and org-cite to co-exist, but also other
packages or users might also define links like cite:.


John

---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Tue, Apr 5, 2022 at 11:56 AM Bruce D'Arcus  wrote:

> On Sun, Apr 3, 2022 at 5:07 PM John Kitchin 
> wrote:
> >
> > I was looking into using latex commands as styles in org-cite, e.g.
> >
> > [cite/citet:@key]. That example works fine, but [cite/citet*:@key] is
> not allowed. Could that be allowed?
>
> I have no insight into the restriction, but I hope it can be removed.
>
> It occurs to me in that scenario it should be easy to write a function
> that allows users to toggle between the two sets of styles: the direct
> latex ones, and the more general default org-cite ones.
>
> Bruce
>

bug#54731: Please, revert part of dd0727e1ec1 related to Org mode (`encode-time')

[Max Nikulin]

Recently a bug with daylight saving time has been reported to the Org 
mode mail list:


https://list.orgmode.org/paxpr06mb7760238f410cbe3203f78ee0c6...@paxpr06mb7760.eurprd06.prod.outlook.com
Ignacio Casso. [BUG] org-agenda thinks timestamps after 23:00 correspond 
to the next day. Tue, 29 Mar 2022 15:09:10 +0200.


It can be reproduced only with the Org version bundled with Emacs-29. 
The code from the Org git repository works correctly. Due to Emacs 
commit dd0727e1ec1

   Paul Eggert Thu Dec 16 09:40:21 2021 -0800 encode-time simplifications
code of Org in the Emacs and the Org repositories diverged. Changes can 
not be just committed to Org since Org as a standalone package is 
compatible with Emacs-26 and even still with Emacs-25 where new style of 
`encode-time' arguments are not supported.


Moreover daylight saving time flag is ignored when timestamp components 
are passed as separate arguments and some Org code uses nil value (no 
DST) instead of -1 (ignore DST).


Even within Emacs both old and new calling styles of `encode-time' are 
used, so partial revert of the change does not reduce code consistency 
significantly enough.


On the Org side it is necessary to update at least the 
`org-parse-time-string' function and to introduce a compatibility 
wrapper that will use old calling convention when running under old 
Emacs versions. Such changes should finally land in the Emacs repository 
as well.


Please, revert changes from dd0727e1ec1 related to Org to fix the 
daylight saving time and to mitigate merge conflicts during porting of 
future fixes in Org.


Notice, this bug is namely for Emacs, not for Org mode as debbugs packages.

Linking by Message-ID

[Max Nikulin]

On 05/04/2022 13:14, Ihor Radchenko wrote:

Karl Fogel writes:


   From: Ihor Radchenko
   Subject: Re: Removing obsolete function
   `org-truely-invisible-p'.
   To: Karl Fogel
   Cc: Org Mode
   Date: Sun, 19 Dec 2021 17:14:32 +0800
   Message-ID: <87h7b5rm6f.fsf@localhost>


I usually just leave an ML link in such cases:
https://orgmode.org/list/87h7b5rm6f.fsf@localhost


As long as the ML link contains the Message-ID, as appears to be
the case here, yeah.  Mailing list archives can move, which causes
links to suddenly stop working.  But if the Message-ID is in the
link, then (with a little extra work) one can always find the
message in the new archive.

(The reason I typically include more is to make things as easy as
possible for those who are searching in a local archive using
their regular mailreader.  But I can switch to the above way if
you'd prefer.)


FYI, I do not know an easy way to search mailing list archives by
Message-ID. Message-ID itself does not even provide information which
mailing list it is referring to (maybe it is e.g. Emacs devel).
That's why I prefer links - they can often be found using archive.org if
nothing.

On the other hand, extra information would not heart. In addition to
link.


A link to a message in the local storage of a regular mail reader should 
have mid: scheme, e.g. mid:87h7b5rm6f.fsf@localhost

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

Unfortunately the only way to specify mail list is the text around the link.

Mail-archive promises Message-ID resolver 
https://mid.mail-archive.com/... but it does not work for emacs-orgmode. 
Gmane has the org mail list archive and allows access using Message-ID 
from an arbitrary mail list:


w3m -m 'nntp://news.gmane.io/87h7b5rm6f.fsf@localhost'

However I consider https://list.orgmode.org/MID links as more friendly 
for users unaware of possible ways to obtain some message using its 
Message-ID.

Re: org-cite styles don't allow * in them

[Bruce D'Arcus]

On Tue, Apr 5, 2022 at 12:11 PM John Kitchin  wrote:
>
> Would you find it suitable to use [cite/command:pre @key post] in general?

I think it's a reasonable approach that would appeal to some users who
would treat org as a front-end to LaTeX primarily, and obviously
previous org-ref users, and that it's better than supporting this in a
parallel but incompatible syntax.

> For portability, I suppose there could be a defcustom mapping if one wanted 
> to leverage the oc-csl library with pretty minimal effort.

Right.

I'm not sure what the precise right solution is, where, but something like that.

oc-biblatex, for example, has the new org-cite-biblatex-styles
defcustom, whose list entries look like:

("author"   "caps"  "Citeauthor*" nil nil)

So with that, a oc-biblatex user can already do this presumably.

("Citeauthor*"   nil  "Citeauthor*" nil nil)

But could also have a new org-ref processor with a simpler defcustom like:

("Citeauthor*" . "author/caps")

> I think two things need to be addressed to fix that. First is allowing a * in 
> the style/variant section; there are probably 17 or so of these commands in 
> natbib/biblatex. Second is fixing org-activate-link so that link activation 
> functions don't get called on something like [cite/citet:@key]. This is 
> necessary for org-ref and org-cite to co-exist, but also other packages or 
> users might also define links like cite:.

+1

Bruce

Re: Removing obsolete function `org-truely-invisible-p'.

[Karl Fogel]

On 05 Apr 2022, Ihor Radchenko wrote: 
Sorry for not being clear. I was referring to the commit message 
- it is

what you commonly see in git log.

Having something like


commit-hash Mark function obsolete & fix spelling of its name


in git log is confusing because it is unclear what the commit is
changing. If you look at
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/log/
then you can see that we generally follow certain style of the
commit messages: changed-file-or-library: What is changed
Also see 
https://orgmode.org/worg/org-contribute.html#commit-messages


Oh, it was clear you were referring to the commit message -- what 
I now realize is that you were referring to the first line of the 
commit message (the summary line).


Unfortunately, the 'CONTRIBUTE' file at the top level of the Org 
Mode source tree gives incomplete guidance on commit messages (it 
just says to follow what Emacs does, so I did that).  I didn't 
realize that 
https://orgmode.org/worg/org-contribute.html#commit-messages has 
further, slightly different guidance.


Thanks.  I'm happy to adhere to the local standards, once I figure 
out what they are :-).



I think we have a misunderstanding here. Unused functions are not
necessarily obsolete. For example, we have org-list-to-texinfo, 
which is
not used anywhere in the codebase, but could be useful for 
developers.


org-compat.el contains functions that are planned for removal in 
future
(and obsolete for the time being), obsolete function/variable 
names, and

compatibility functions.

As I mentioned in my previous email, I am slightly reluctant to 
remove
org-truely-invisible-p. It means that it should remain available 
and no
plans to remove it should be made (unless there are multiple 
devs/users
who prefer removal). Hence, the function should stay in 
org-macs.el.
org-macs.el is meant to store general-purpose functions that can 
be

useful for development of the whole Org mode ecosystem.

If we decide that org-truely-invisible-p stays in org-macs, we 
should

fix the issue with its name. Renaming requires creating obsolete
function name alias in org-compat.el to make sure that nothing 
gets
broken unexpectedly for people who use org-truely-invisible-p 
with its

current name.

Hope I clarified my logic.


You did!


FYI, I do not know an easy way to search mailing list archives by
Message-ID. Message-ID itself does not even provide information 
which

mailing list it is referring to (maybe it is e.g. Emacs devel).
That's why I prefer links - they can often be found using 
archive.org if

nothing.

On the other hand, extra information would not heart. In addition 
to

link.


Makes sense, yup.  Actually, I usually include the link -- I just 
didn't think of it in this case because I rarely visit the Org 
Mode mailing list archives (unlike the Emacs Devel archives, which 
I often do visit, and therefore my commits in Emacs always include 
the link when referring to a mailing list post).


A revised patch is attached.  Now it's so simple that I think the 
commit message doesn't need to point to the mailing list 
discussion anyway.  Review welcome.


Best regards,
-Karl

>From 2cef1fdbe2b2aa40a2bb081eab4b2e2808000670 Mon Sep 17 00:00:00 2001
From: Karl Fogel 
Date: Thu, 31 Mar 2022 19:02:38 -0500
Subject: [PATCH] lisp/org-macs.el: Fix spelling of `org-truly-invisible-p'

* lisp/org-macs.el (org-truly-invisible-p): Fix spelling of name.
* lisp/org-compat.el (org-truely-invisible-p): Add compatibility
  alias for the old name.
---
 lisp/org-compat.el | 4 
 lisp/org-macs.el   | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git lisp/org-compat.el lisp/org-compat.el
index 38d330de6..00716ae13 100644
--- lisp/org-compat.el
+++ lisp/org-compat.el
@@ -752,6 +752,10 @@ context.  See the individual commands for more 
information."
 
 (define-obsolete-function-alias 'org-get-last-sibling 
'org-get-previous-sibling "9.4")
 
+(define-obsolete-function-alias 'org-truely-invisible-p
+  'org-truly-invisible-p "9.6"
+  "Compatibility alias for legacy misspelling of `org-truly-invisible-p'.")
+
  Obsolete link types
 
 (eval-after-load 'ol
diff --git lisp/org-macs.el lisp/org-macs.el
index b39af9103..a09115e7c 100644
--- lisp/org-macs.el
+++ lisp/org-macs.el
@@ -1151,7 +1151,7 @@ fontification."
  (folding-only (memq value '(org-hide-block outline)))
  (t value
 
-(defun org-truely-invisible-p ()
+(defun org-truly-invisible-p ()
   "Check if point is at a character currently not visible.
 This version does not only check the character property, but also
 `visible-mode'."
-- 
2.35.1

[PATCH v2] ol.el: add description format parameter to org-link-parameters

[Hugo Heagren]

* ol.el (org-link-parameters): add parameter `:default-description', a
string or a function.
* (org-insert-link): if no description is provided (pre-existing or as
an argument), next option is to use the `:default-description' (if
non-nil) parameter to generate one.

Default descriptions are predictable within a link type, but because
link types are quite diverse, are NOT predictable across many types. A
type-parameter is thus a good place to store information on the
default description.
---

I've added the condition-case back to the check on
`org-link-make-description', and added a new one to the check for the
`:default-description' parameter, as Ihor suggested. I've also
modified the handling of that parameter, to reflect
`org-link-make-description', and updated the docstring accordingly.

Apologies if the subject formatting is not correct, I'm still getting
the hang of git-send-email.

Hugo

 lisp/ol.el | 43 ---
 1 file changed, 36 insertions(+), 7 deletions(-)

diff --git a/lisp/ol.el b/lisp/ol.el
index 1b2bb9a9a..e74ef8dda 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -140,6 +140,15 @@ link.
   Function that inserts a link with completion.  The function
   takes one optional prefix argument.
 
+`:default-description'
+
+  String or function used as a default when prompting users for a
+  link's description. A string is used as-is, a function is
+  called with two arguments: the full link text, and the
+  description generated by `org-insert-linke'. It should return
+  the description to use (this reflects the behaviour of
+  `org-link-make-description-function').
+
 `:display'
 
   Value for `invisible' text property on the hidden parts of the
@@ -1761,11 +1770,14 @@ prefix negates `org-link-keep-stored-after-insertion'.
 If the LINK-LOCATION parameter is non-nil, this value will be used as
 the link location instead of reading one interactively.
 
-If the DESCRIPTION parameter is non-nil, this value will be used as the
-default description.  Otherwise, if `org-link-make-description-function'
-is non-nil, this function will be called with the link target, and the
-result will be the default link description.  When called non-interactively,
-don't allow to edit the default description."
+If the DESCRIPTION parameter is non-nil, this value will be used
+as the default description.  If not, and the chosen link type has
+a non-nil `:default-description' parameter, that is used to
+generate a description as described in `org-link-parameters'
+docstring. Otherwise, if `org-link-make-description-function' is
+non-nil, this function will be called with the link target, and
+the result will be the default link description.  When called
+non-interactively, don't allow to edit the default description."
   (interactive "P")
   (let* ((wcf (current-window-configuration))
 (origbuf (current-buffer))
@@ -1775,7 +1787,7 @@ don't allow to edit the default description."
 (desc region)
 (link link-location)
 (abbrevs org-link-abbrev-alist-local)
-entry all-prefixes auto-desc)
+entry all-prefixes auto-desc type)
 (cond
  (link-location) ; specified by arg, just use it.
  ((org-in-regexp org-link-bracket-re 1)
@@ -1842,6 +1854,7 @@ Use TAB to complete link prefixes, then RET for 
type-specific completion support
  (and (equal ":" (substring link -1))
   (member (substring link 0 -1) all-prefixes)
   (setq link (substring link 0 -1
+  (setq type link)
  (setq link (with-current-buffer origbuf
   (org-link--try-special-completion link)
(set-window-configuration wcf)
@@ -1918,7 +1931,23 @@ Use TAB to complete link prefixes, then RET for 
type-specific completion support
   (let ((initial-input
 (cond
  (description)
- ((not org-link-make-description-function) desc)
+  (desc)
+  ((org-link-get-parameter
+type
+:default-description)
+   (condition-case nil
+   (let ((def (org-link-get-parameter
+   type
+   :default-description)))
+ (cond
+  ((stringp def) def)
+  ((functionp def)
+   (funcall def link desc
+ (error
+  (message "Can't get link description from %S"
+  (symbol-name def))
+ (sit-for 2)
+  nil)))
  (t (condition-case nil
 (funcall org-link-make-description-function link desc)
   (error
-- 
2.20.1

Re: bug#54731: Please, revert part of dd0727e1ec1 related to Org mode (`encode-time')

[Paul Eggert]

On 4/5/22 09:43, Max Nikulin wrote:

Please, revert changes from dd0727e1ec1 related to Org to fix the 
daylight saving time and to mitigate merge conflicts during porting of 
future fixes in Org.


Thanks for mentioning the problem. I installed the attached, which I 
hope suffices.


This patch does keep two of the Org-related parts of dd0727e1ec1; these 
parts should work OK with Emacs 25 and so can be merged into Org before 
it starts assuming Emacs 27.From 9e07ec56c7e58ee1eb5598dfdd1b772a690daa24 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 5 Apr 2022 17:48:05 -0700
Subject: [PATCH] Port Org encode-time usage back to Emacs 25
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org/ol.el (org-store-link):
* lisp/org/org-clock.el (org-clock-sum)
(org-clock-update-time-maybe):
* lisp/org/org-colview.el (org-colview-construct-allowed-dates):
* lisp/org/org-macro.el (org-macro--vc-modified-time):
* lisp/org/org-macs.el (org-2ft, org-matcher-time):
* lisp/org/org-table.el (org-table-eval-formula):
* lisp/org/org.el (org-read-date, org-display-custom-time)
(org-time-string-to-time, org-timestamp-change):
Don’t assume Emacs 27 encode-time, since standalone Org still
works with Emacs 25 and it’s easier if we minimize differences
from standalone Org.  Problem reported by Max Nikulin (Bug#54731).
This reverts much of 2021-12-16T17:40:21Z!egg...@cs.ucla.edu.
---
 lisp/org/ol.el  | 2 +-
 lisp/org/org-clock.el   | 8 
 lisp/org/org-colview.el | 2 +-
 lisp/org/org-macro.el   | 2 +-
 lisp/org/org-macs.el| 4 ++--
 lisp/org/org-table.el   | 2 +-
 lisp/org/org.el | 8 
 7 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/lisp/org/ol.el b/lisp/org/ol.el
index 905e491f4a..a03d85f618 100644
--- a/lisp/org/ol.el
+++ b/lisp/org/ol.el
@@ -1575,7 +1575,7 @@ org-store-link
 	  (setq link
 		(format-time-string
 		 (car org-time-stamp-formats)
-		 (encode-time
+		 (apply 'encode-time
 			(list 0 0 0 (nth 1 cd) (nth 0 cd) (nth 2 cd)
 			  nil nil nil
 	  (org-link-store-props :type "calendar" :date cd)))
diff --git a/lisp/org/org-clock.el b/lisp/org/org-clock.el
index dce5d9d4c0..7395669109 100644
--- a/lisp/org/org-clock.el
+++ b/lisp/org/org-clock.el
@@ -1904,11 +1904,11 @@ org-clock-sum
 	   ((match-end 2)
 	;; Two time stamps.
 	(let* ((ts (float-time
-			(encode-time
+			(apply #'encode-time
 			   (save-match-data
  (org-parse-time-string (match-string 2))
 		   (te (float-time
-			(encode-time
+			(apply #'encode-time
 			   (org-parse-time-string (match-string 3)
 		   (dt (- (if tend (min te tend) te)
 			  (if tstart (max ts tstart) ts
@@ -3042,9 +3042,9 @@ org-clock-update-time-maybe
 	  (setq ts (match-string 1)
 		te (match-string 3))
 	  (setq s (- (float-time
-		  (encode-time (org-parse-time-string te)))
+		  (apply #'encode-time (org-parse-time-string te)))
 		 (float-time
-		  (encode-time (org-parse-time-string ts
+		  (apply #'encode-time (org-parse-time-string ts
 		neg (< s 0)
 		s (abs s)
 		h (floor (/ s 3600))
diff --git a/lisp/org/org-colview.el b/lisp/org/org-colview.el
index 371889432d..829fcbbe3f 100644
--- a/lisp/org/org-colview.el
+++ b/lisp/org/org-colview.el
@@ -782,7 +782,7 @@ org-colview-construct-allowed-dates
   (setq time-after (copy-sequence time))
   (setf (nth 3 time-before) (1- (nth 3 time)))
   (setf (nth 3 time-after) (1+ (nth 3 time)))
-  (mapcar (lambda (x) (format-time-string fmt (encode-time x)))
+  (mapcar (lambda (x) (format-time-string fmt (apply #'encode-time x)))
 	  (list time-before time time-after)
 
 (defun org-columns-open-link (&optional arg)
diff --git a/lisp/org/org-macro.el b/lisp/org/org-macro.el
index bb8a95065b..0921f3aa27 100644
--- a/lisp/org/org-macro.el
+++ b/lisp/org/org-macro.el
@@ -378,7 +378,7 @@ org-macro--vc-modified-time
   (buffer-substring
    (point) (line-end-position)
 		   (when (cl-some #'identity time)
-			 (setq date (encode-time time
+			 (setq date (apply #'encode-time time
 	  (let ((proc (get-buffer-process buf)))
 		(while (and proc (accept-process-output proc .5 nil t)
 	  (kill-buffer buf))
diff --git a/lisp/org/org-macs.el b/lisp/org/org-macs.el
index 6f038f026b..b10725bd52 100644
--- a/lisp/org/org-macs.el
+++ b/lisp/org/org-macs.el
@@ -1185,7 +1185,7 @@ org-2ft
((numberp s) s)
((stringp s)
 (condition-case nil
-	(float-time (encode-time (org-parse-time-string s)))
+	(float-time (apply #'encode-time (org-parse-time-string s)))
   (error 0)))
(t 0)))
 
@@ -1252,7 +1252,7 @@ org-matcher-time
 \"\", and \"\".
 
 Return 0. if S is not recognized as a valid value."
-  (let ((today (float-time (encode-time
+  (let ((today (float-time (apply #'encode-time
   (append '(0 0 0) (nthcdr 3 (decode-time)))
 (save-match-data
   (cond
diff --git a/lisp/org/org-table.el b/lisp/org/or

Re: Agenda without todos only if there is no other timestamp

[TRS-80]

On 2022-04-05 04:48, Karl Voit wrote:

Hi,

I've got following custom agenda for exporting:

| ("n" "no TODO events +180d"
|  ((agenda "no TODO events +180d"
|   ((org-agenda-span 180)
|(org-agenda-time-grid nil)
|(org-agenda-entry-types '(:timestamp :sexp))
|(org-agenda-skip-function
| '(or
|   (org-agenda-skip-entry-if 'todo 'any);; skip if any
TODO state is found
|   (org-agenda-skip-entry-if 'category "errors");; skip
if any TODO state is found
|   (my-skip-tag "lp")
|   )
|  nil (,(concat my-org-files-path "agenda_180d_filtered_raw.html")))

(don't mind the stupid name - I may fix this as it is misleading
here)

This results in an HTML file that contains my appointments without the 
tasks.


Unfortunately, I sometimes seem to schedule appointments within open
todos such as:

| * NEXT talk with Steve about the project X
| SCHEDULED: <2022-04-05 Tue>
|
| - [X] ask him for a time-slot
| - we settled for: <2022-04-05 Tue 14:00-15:00>

Of course, those appointments are lost in my agenda export as
specified above. This is a bummer and I want to fix this somehow.

Tasks should be omitted only if there is no other time-stamp than
deadline or scheduled.

org-agenda-skip-if lists:
| scheduled Check if there is a scheduled cookie
| notscheduled  Check if there is no scheduled cookie
| deadline  Check if there is a deadline
| notdeadline   Check if there is no deadline
| timestamp Check if there is a timestamp (also deadline or 
scheduled)
| nottimestamp  Check if there is no timestamp (also deadline or 
scheduled)

| regexpCheck if regexp matches
| notregexp Check if regexp does not match.
| todo  Check if TODO keyword matches
| nottodo   Check if TODO keyword does not match

How is it possible to accomplish this? I think this would require
something like "Check if there is a timestamp (except deadline or
scheduled)" which isn't available yet.

Any ideas on that one?


I think you will need to write a custom ~org-agenda-skip-function~.

It's late and I am too tired, but if you are still floundering about 
after some days, send another mail and I will see what I can do to help. 
 :)


Cheers,
TRS-80

Re: Ethical problems with MathJax as default - Was: Faulty SVG width

[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. ]]]

In general, being free software does not automatically assure that the
program has no malicious features.

What it does is assure that the users can check the source code for
any malicious features, and fix any that are spotted.

  > I understand the problem, however I do not see why LibreJS could not
  > whitelist MathJax. It is a technical limitation of current LibreJS
  > implementation, not the problem of software freedom.

Perhaps it should do that.

I think we could use more help to maintain LibreJS.
Anyone who would like to help, please write to maintain...@gnu.org.

-- 
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: Ethical problems with MathJax as default - Was: Faulty SVG width

[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. ]]]

  > On the other hand, I think it is more preferable and more
  > privacy-conscious to forbid loading from Cloudflare and use a local copy
  > of MathJax embedded in LibreJS instead:

I agree.  Perhaps GNU/Linux distros should start packaging MathJax
for local installation, so that the local copy will be used instead.

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

Inline src org block element with containing inside item does not get exported when it contains a newline (was: Inline src block element not parsed correctly for export when in a list item)

[Ihor Radchenko]

Confirmed.

Interestingly, I cannot reproduce the bug using my personal branch at
https://github.com/yantar92/org. The fix should be lurking somewhere
close...

Kaushal Modi  writes:

> I believe I have come across a corner case issue where the inline src
> block element doesn't get parsed as one, if:

The element actually does get parsed. Once can check it by running M-:
(org-element-context) with point at the problematic inline src block.
However, the export is somehow broken.

> * Doesn't export correctly if inline src block is in a wrapped list
> - abcdefg abcdefg abcdefg abcdefg src_org[:exports code]{[[abc
>   def][bar]]}.

One observation is that export is again correct if I remove a '[' in the
link inside inline source block.

Best,
Ihor