Subject: Re: bug#35645: Fix icalendar--add-diary-entry/diary-make-entry interaction

From: Thomas Fitzsimmons <[email-masked]>
Date: Thu, 23 May 2019 22:49:46 -0400

Noam Postavsky <[email-masked]> writes:

> Thomas Fitzsimmons <[email-masked]> writes:
>
>> To keep the code mostly the same (so that I don't need to factor out
>> another function), I've changed the original logic by adding a
>> with-current-buffer wrapper, as shown in simplified form in
>> diary-make-entry-with-current-buffer.patch.  I'm hoping this keeps the
>> default diary-make-entry logic exactly the same, but I'd like
>> confirmation from someone more familiar with the subtleties of window
>> and buffer manipulation.
>
>> -  (let ((pop-up-frames (or pop-up-frames (window-dedicated-p))))
>> -    (find-file-other-window (or file diary-file)))
>> +  (with-current-buffer
>> +      (let ((pop-up-frames (or pop-up-frames (window-dedicated-p))))
>> +        (find-file-other-window (or file diary-file)))
>
> If you're asking whether
>
>     (progn (find-file-other-window (or file diary-file))
>       BODY)
>
> is the same as
>
>     (with-current-buffer (find-file-other-window (or file diary-file))
>       BODY)
>
> Then yes, I'd say you're fine (assuming BODY doesn't change buffers,
> which I believe is the case here).

Yes, that's what I was asking, thanks.

Ulf, the only other feedback I have for icalendar is that
icalendar--add-diary-entry is useful to/used by other packages (e.g.,
Excorporate) despite it being a private function.  What if we added a
public alias, icalendar-add-diary-entry, within this same patch?  Then I
could check for that alias's existence and only enable the workaround
advice for older Emacs versions.

Thomas