[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35645: Fix icalendar--add-diary-entry/diary-make-entry interaction
From: |
Thomas Fitzsimmons |
Subject: |
bug#35645: Fix icalendar--add-diary-entry/diary-make-entry interaction |
Date: |
Thu, 23 May 2019 22:49:46 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Noam Postavsky <npostavs@gmail.com> writes:
> Thomas Fitzsimmons <fitzsim@fitzsim.org> 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