GNU bug report logs - #18381
24.3.93; Diary can wrongly be displayed in Calendar's window

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 18381 <at> debbugs.gnu.org
Subject: bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
Date: Tue, 09 Sep 2014 11:18:16 +0200

>>> (let ((display-buffer-fallback-action
>>>          (list (delq 'display-buffer-in-previous-window
>>>                   (copy-sequence (car display-buffer-fallback-action))))))
>>>     ...)
> [...]
>> (let ((display-buffer-overriding-action
>>         (list (delq 'display-buffer-in-previous-window
>>                  (copy-sequence (car display-buffer-fallback-action))))))
>>    ...)
>
> I can't see that the second form is substantially cleaner than the
> first, but ok.

`display-buffer-overriding-action' is a variable while
`display-buffer-fallback-action' is a constant.  But the former is also
stronger in the sense that the user cannot override it.

>> You still didn't tell me who actually is responsible for displaying the
>> calendar and then the diary.
>
> Not sure I understand. Like I said:
>
> M-x diary
> M-x calendar
> M-x diary
>
> If you are asking me where the display-buffer call is, then it's
> diary-display-function as called from diary-list-entries.
>
> The two standard values are diary-fancy-display (which uses
> calendar-in-read-only-buffer, which calls display-buffer),
> and diary-simple-display, which calls display-buffer directly.
>
> Since calendar-in-read-only-buffer is a general function, I'd prefer not
> to add too much that is specific to this one usage.

I now understand what you earlier meant with "general function".

> And even for the diary using the previous window might be right in some
> cases, just not this specific one where the previous window now contains
> the calendar.
>
>>   Is it `calendar-in-read-only-buffer'? If we are sure that it's there,
>> we can pass the necessary advice in that mancro's `display-buffer'
>> call's ACTION argument.
>
> What would the necessary advice look like?

Setting inhibit-same-window to t.  But the problem is that if
`calendar-in-read-only-buffer' is used to display the calendar or to
display the diary even when the calendar was not displayed before or is
not called with the calendar window selected, then inhibiting the same
window might not be TRT.  WOW if `calendar-in-read-only-buffer' is as
general as you say, we really should not mess with its `display-buffer'
arguments.

> At the moment I think I'm going to settle for just getting 24.3
> behaviour back.

Agreed.  I still don't understand _where_ you plan to make the needed
change if `calendar-in-read-only-buffer' is too general.  For example,
where precisely would you bind `display-buffer-fallback-action'?  I
suppose around the calls of `calendar-in-read-only-buffer' in diary.el.
Is that correct?  Can a function like `diary-fancy-display' within the
`calendar-in-read-only-buffer' macro try to display another buffer but
the diary itself?

BTW, did you try using the dedicated status of the calendar window?
Something like

(let* ((window (get-buffer-window "calendar"))
       (status (and window (window-dedicated-p window))))
  ;; Protect calendar window.
  (and window (set-window-dedicated-p window 'soft))
  (calendar-in-read-only-buffer
      ....
    )
  ;; Unprotect calendar window.
  (and window (window-live-p window)
       (set-window-dedicated-p window status)))

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.