[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] org-read-date with pop-up-frames set to t
From: |
Alan Schmitt |
Subject: |
Re: [O] org-read-date with pop-up-frames set to t |
Date: |
Wed, 03 Dec 2014 14:37:21 +0100 |
User-agent: |
Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (darwin) |
On 2014-11-30 16:47, Alan Schmitt <address@hidden> writes:
> Hello,
>
> I'm experimenting with using frames instead of windows, and I'm seeing
> some strange behavior with `org-read-date'. Here is an ECM starting from
> an emacs -Q (with an emacs 24.4 and the bundled org):
>
> #+begin_src emacs-lisp
> (setq pop-up-frames t)
> (setq frame-auto-hide-function 'delete-frame)
>
> (require 'org)
> (org-read-date)
> #+end_src
>
> When evaluating the `org-read-date' function, a new frame opens (great)
> with two windows, the bottom one being the calendar window.
>
> Question 1: is it possible just to have the calendar window in the new
> frame?
>
> When I select a date, I see the selected date echoed in the minibuffer
> (the function has returned a value), but the frame and the two windows
> stay there, and I have to manually delete the frame to get back where
> I was.
>
> Question 2: is there a way to delete this frame when I'm done selecting
> the date?
As a follow-up, I discussed this with a friend who understand emacs-lisp
much better than I do. Here is what he said about `org-read-date':
> It uses (save-excursion (save-window-excursion...)), but that
> does not save the selected frame (save which frame was selected).
> Also, it does not remove frame *Calendar* because it uses only
> (bury-buffer "*Calendar*"). It should perhaps use something
> like `frame-auto-hide-function' as well.
I can start looking into this. Would a patch around these issues be
considered?
Thanks,
Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
signature.asc
Description: PGP signature
- Re: [O] org-read-date with pop-up-frames set to t,
Alan Schmitt <=