Re: save-frame-excursion?

[Bastien]

Stefan Monnier <address@hidden> writes:

>> The calendar buffer was configured to be sticky in a particular frame,
>> so that when emacs wanted to show that calendar buffer, it showed it in
>> the different frame.
>
> That still doesn't explain the shift of focus.

Briefly, here is how org-read-date works:

- if org-read-date-popup-calendar is t, it pops up a calendar, either in
  a different window, either in a different frame, depending on the user
  configuration;

- it prompt the user for a date (and possibly more information like the
  time, the repeater, etc.);

- it add new commands to the minibuffer-local-map: these commands modify
  the calendar display.  For example, M-S-<left> will call this command:
  (org-eval-in-calendar '(calendar-backward-month 1))

- those minibuffer commands get a post-command hook which displays the
  calendar according to the minibuffer prompt.

That's the basic mechanism.

For org-read-date to work when the calendar is displayed in another
frame, we need to prevent org-eval-in-calendar from losing the frame
focus.

I've just pushed a change to Org that spares us org-save-frame-excursion
by making `org-eval-in-calendar' DTRT about restauring the frame focus.

>> I don't entirely understand how the stickiness happens -- configuration
>> of the emacs calendar is far beyond me.
>
> Doesn't matter.  If the code doesn't explicitly ask for a change in
> focus, then there's no reason (other than to work around a bug
> somewhere, probably) why we need to reset the focus via
> select-frame-set-input-focus when unwinding.

The code was indirectly asking for a change in focus by calling the
calendar from within a command.

>> Admittedly it's unlikely (at least now) to get into a state where you
>> will change the frame focus, but whenever you /do/ change the frame
>> focus, wouldn't you want it restored?
>
> Emacs almost never changes frame focus explicitly (for the good reason
> that it's mighty hard to do it reliably for all possible WMs).

I am not using frames so I was not aware of these issues until now, 
and I agree changing frame focus explicitely is not very good.

Maybe we should have an option `org-calendar-force-display-in-window'
defaulting to t to prevent the calendar to be displayed in a separate
frame.

-- 
 Bastien