From: martin rudalics <rudalics@gmx.at>
To: Glenn Morris <rgm@gnu.org>
Cc: Stephen Berman <stephen.berman@gmx.net>, 18381@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 [thread overview]
Message-ID: <540EC5D8.2000302@gmx.at> (raw)
In-Reply-To: <tgegvlkzl2.fsf@fencepost.gnu.org>
>>> (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
next prev parent reply other threads:[~2014-09-09 9:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-01 14:59 bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window Stephen Berman
2014-09-01 17:37 ` Glenn Morris
2014-09-01 18:38 ` Stephen Berman
2014-09-04 0:34 ` Glenn Morris
2014-09-04 12:27 ` martin rudalics
2014-09-04 18:04 ` Glenn Morris
2014-09-04 19:48 ` Glenn Morris
2014-09-04 22:39 ` Glenn Morris
2014-09-04 23:40 ` Glenn Morris
2014-09-05 10:46 ` martin rudalics
2014-09-05 16:14 ` Glenn Morris
2014-09-06 8:52 ` martin rudalics
2014-09-08 6:04 ` Glenn Morris
2014-09-08 20:32 ` Stephen Berman
2014-09-09 1:26 ` Glenn Morris
2014-09-09 6:58 ` martin rudalics
2014-09-09 7:44 ` Glenn Morris
2014-09-09 9:18 ` martin rudalics [this message]
2014-09-09 18:13 ` Glenn Morris
2014-09-09 13:00 ` Stefan Monnier
2014-09-05 10:46 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=540EC5D8.2000302@gmx.at \
--to=rudalics@gmx.at \
--cc=18381@debbugs.gnu.org \
--cc=rgm@gnu.org \
--cc=stephen.berman@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.