[BUG] icalendar export fails with SCHEDULED/DEADLINE entries [9.5.2 (9.5.2-gbc8c3e @ /home/eliza/.emacs.d/straight/build/org/)]

[Eliza Velasquez]

Hello,

It seems like `org-icalendar-export-to-ics' fails to consider the
SCHEDULED and DEADLINE properties. Consider the following org file
`foo.org':

* foo
SCHEDULED: <2022-02-15 Tue>

When invoking `org-icalendar-export-to-ics', we get the following
`foo.ics' file.

BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:test
PRODID:-//Eliza Velasquez//Emacs with Org mode//EN
X-WR-TIMEZONE:PST
X-WR-CALDESC:
CALSCALE:GREGORIAN
END:VCALENDAR

As you can see, there is no entry for `foo'. Changing the file so that
the timestamp is in the body rather than the SCHEDULED property (though
I'm not sure "property" is the correct term here, given that it's not a
PROPERTY)...

* foo
<2022-02-15 Tue>

...exports as expected.

BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:test
PRODID:-//Eliza Velasquez//Emacs with Org mode//EN
X-WR-TIMEZONE:PST
X-WR-CALDESC:
CALSCALE:GREGORIAN
BEGIN:VEVENT
DTSTAMP:20220215T074144Z
UID:TS1-3d9795cd-8430-49dd-97d7-f1fcc10d814d
DTSTART;VALUE=DATE:20220215
DTEND;VALUE=DATE:20220216
SUMMARY:foo
DESCRIPTION:<2022-02-15 Tue>
CATEGORIES:test
END:VEVENT
END:VCALENDAR

I noticed this when trying to use org-caldav, and it seems some others
have run into this issue as well. At least, I'm pretty sure the two bugs
are caused by the same issue.


Emacs  : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, 
cairo version 1.16.0)
Package: Org mode version 9.5.2 (9.5.2-gbc8c3e @ 
/home/eliza/.emacs.d/straight/build/org/)
--
Eliza

[PATCH] org-agenda: fix `org-agenda-new-marker`

[Hu Lucius]

In some cases, `org-agenda-buffer` is killed while the symbol itself
is still non-nil. `org-agena-new-marker` and anything that calls it would
end in a message of "Selecting deleted buffer".

This commit simply added an additional test that

(buffer-live-p org-agenda-buffer)

should also be true.

P.S. I've sent another patch with the same subject a few days earlier.
But that contains an error. Please dismiss that one.

Signed-off-by: Lucius Hu 
---
 lisp/org-agenda.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 9bc44a56e..cc7f01758 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4225,7 +4225,7 @@ Marker is at point, or at POS if non-nil.  Org mode
keeps a list
 of these markers and resets them when they are no longer in use."
   (let ((m (copy-marker (or pos (point)) t)))
 (setq org-agenda-last-marker-time (float-time))
-(if org-agenda-buffer
+(if (and org-agenda-buffer (buffer-live-p org-agenda-buffer))
  (with-current-buffer org-agenda-buffer
   (push m org-agenda-markers))
   (push m org-agenda-markers))
--
2.35.1

[BUG] S- Overridden by windmove.el [9.5.2 (release_9.5.2-3-geb9f34 @ /usr/local/share/emacs/28.0.91/lisp/org/)]

[Yingnan Cui]

Hi all,

It seems that org-mode's S- is overriden by windmove.el even
though I'm adding the following configurations according to the org
manual:
```emacs-lisp
;; Make windmove work in Org mode:
(add-hook 'org-shiftup-final-hook 'windmove-up)
(add-hook 'org-shiftleft-final-hook 'windmove-left)
(add-hook 'org-shiftdown-final-hook 'windmove-down)
(add-hook 'org-shiftright-final-hook 'windmove-right)
```

Emacs  : GNU Emacs 28.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.24, cairo version 1.16.0)
 of 2022-02-02
Package: Org mode version 9.5.2 (release_9.5.2-3-geb9f34 @
/usr/local/share/emacs/28.0.91/lisp/org/)

Thanks,
Gin

Re: org-persist uses Emacs 28+ buffer-local-boundp

[Ihor Radchenko]

Kyle Meyer  writes:

> Could you update org-persist-write:elisp to be compatible with older
> Emacs versions (e.g., by inlining the short definition and adding a
> comment about why buffer-local-boundp isn't used)?

Done in 0cb076020. Thanks for the heads up!

Best,
Ihor

[PATCH v3] Fix FAQ entry about mailto links.

[Max Nikulin]

On 11/02/2022 00:42, Robert Goldman wrote:


There are a couple of minor issues in the patch you sent (including a 
couple of grammatical errors), so attached is a revision.


Great. Thank you, Robert, it exact reason why I asked for a review.

I am sending the updated patch and a diff to your edits to highlight my 
latest changes.



From e7f0f2c51950b3c0f181191c5210ea26cafc03f4 Mon Sep 17 00:00:00 2001
From: "Robert P. Goldman" 
Date: Thu, 10 Feb 2022 11:20:36 -0600
Subject: [PATCH 2/4] Revert "Fix FAQ entry about mailto links."

This reverts commit b8158af7a839a751e6976cd95d18a5d5f199024a.


Would you like to have you original version in git history? For me it is 
not a problem to make my patch updating yours one without reverting the 
original commit (create another branch, cherry-pick commits, resolve 
conflict to the latest state).  Otherwise you can avoid unnecessary 
commits in your local repository by either applying my patch to a new 
branch or using "git rebase -i master" to drop unnecessary commits.



+If you prefer an external application that is /not/ the one configured
+in your desktop environment,


What is bothering me a bit is the entry title "Org-mode is not opening 
mailto links in my *default* mail client". The updated variant mostly 
discusses changing of defaults.



+**side comment:** the above paragraph is hard to understand. Would it be
+possible to add pointers to the discussion of these issues?


I do not follow Emacs development. The source is git commit history and 
commit messages rarely have links to discussion or references to bug 
tracker.



Also what
+is meant by "~browse-url-xdg-open~ was evolving to similar code in
+2011."  Finally, it's not /generally/ true that subprocess
+applications can't inform Emacs of failures.


The reality is that failures of xdg-open are confusingly quiet. Often 
nil is specified as the buffer for standard error (application may spam 
with warnings and failed assert). For `start-process' or `make-process' 
it is necessary to create a handler that displays message on process 
failure. `call-process' with 0 as DESTINATION signals error only if it 
can not find the executable otherwise only desktop environment may 
notify user about an error.



I believe that what is
+meant here is something more like "Notice that applications invoked
+through =browse-url-= have no way to notify Emacs if they fail."
+This makes sense, because browsers don't exit with a bad exit status
+if they fail to open a URL as expected. -- rpg


It is another sort of errors and browser may show an error page. Notice 
that executable may just send a command to an already running process 
and to exit almost instantly.



+which reached the strange conclusion that it is a bug in Gnome utility:


I would not say "reached". The statement appeared in the middle of 
discussion and the problem was not fixed that time.



+**Side comment:** The above paragraph is also difficult to parse.
+Confusion about what?  Lack of error report?  What does it mean "has
+not resulted in changing of code"? I have cut that.  Also, which Gnome
+utility do you mean here? Or did you just mean "a bug in the Gnome
+desktop"?  **End**


Confusion whether nohup wrapper is necessary. It was removed a bit 
earlier by a participant of the discussion of the bug 9779 and I believe
that the change was correct since dropping of nohup was accompanied by 
other changes. I do not remember what was the name of the gnome utility 
that time, maybe gnome-open, currently it is "gio open" but for most of 
people it is anyway hidden behind xdg-open and namely xdg-open usually 
becomes the target to blame.


> On 7 Feb 2022, at 10:59, Max Nikulin wrote:


+#+begin_comment
+Recurring source of pain is interaction of Emacs function with


Notice that comment is dropped during export, it is visible only to 
contributors who will decide to update the entry.  I am unsure where 
such note should be placed: separate worg page, emacswiki site, etc. 
Even Org has several files with quite similar problems with launching of 
viewers.



+[[elisp:(customize-variable 'org-link-parameters)][=M-x customize-variable RET 
org-link-parameters RET=]], e.g. for
Actually I am unsure if customization of `org-link-parameters' should be 
recommended. The interface contains a lot of entries actually added by 
org packages. Maybe it is better to suggest


  (with-eval-after-load 'ol
(org-link-set-parameters
;; ...


+#+begin_src elisp :results none
+("mailto"
+ :follow (lambda (path)
+  (let ((url (concat "mailto:"; path)))
+;; platform-specific choice of function
+(start-process (concat "open " url) nil
+   "open" "-a" "Thunderbird" "--args" url

   ^^^

Notice this addition, I can not test if it really works.


 #+end_srcFrom 8eeb353a45521ab34cced37971e4455f870671c9 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Mon,