* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
@ 2014-09-01 14:59 Stephen Berman
2014-09-01 17:37 ` Glenn Morris
2014-09-04 12:27 ` martin rudalics
0 siblings, 2 replies; 21+ messages in thread
From: Stephen Berman @ 2014-09-01 14:59 UTC (permalink / raw)
To: 18381
0. emacs -Q
1. Type `M-x calendar' and then `i d' to create a diary file with an
entry for today.
2. M-x customize-option RET calendar-view-diary-initially-flag RET,
toggle the value to `On' and save for current session.
3. M-x diary => The diary entry made in step 1 is displayed (in the
Fancy Diary) in the lower window (which is not the selected window).
4. M-x calendar => The lower window resizes to fit the Calendar, which
is fleetingly displayed in it but then replaced by the Fancy Diary
display (in the same resized window).
The same problem happens if the simple diary display is used (e.g. by
customizing diary-display-function).
A real (i.e. my) use case which exposes this problem is to add
`(appt-activate 1)' to your init-file (cf. the commentary in appt.el) so
you see e.g. today's diary entries as in step 3 on starting Emacs, and
then you open the Calendar as in step 4.
The patch below fixes the problem for me, for both types of diary
display, though I haven't yet checked whether the change to
calendar-in-read-only-buffer adversely affects the other users of this
macro, since those are functions I don't use.
This problem does not happen in 24.3 (at least not in the one packaged
with openSUSE 13.1, for which I don't have the Lisp sources at hand), so
the fix should be committed to emacs-24.
In GNU Emacs 24.3.93.7 (x86_64-suse-linux-gnu, GTK+ Version 3.10.4)
of 2014-08-31 on rosalinde
Repository revision: 117464 rgm@gnu.org-20140828191824-o5hn2x503w527yhn
Windowing system distributor `The X.Org Foundation', version 11.0.11403901
System Description: openSUSE 13.1 (Bottle) (x86_64)
Configured using:
`configure --without-toolkit-scroll-bars 'CFLAGS=-g3 -O0''
=== modified file 'lisp/calendar/calendar.el'
*** lisp/calendar/calendar.el 2014-03-17 16:04:32 +0000
--- lisp/calendar/calendar.el 2014-09-01 13:02:00 +0000
***************
*** 1208,1214 ****
(goto-char (point-min))
(set-buffer-modified-p nil)
(setq buffer-read-only t)
! (display-buffer ,buffer)))
;; The following are in-line for speed; they can be called thousands of times
;; when looking up holidays or processing the diary. Here, for example, are
--- 1208,1214 ----
(goto-char (point-min))
(set-buffer-modified-p nil)
(setq buffer-read-only t)
! (display-buffer ,buffer t)))
;; The following are in-line for speed; they can be called thousands of times
;; when looking up holidays or processing the diary. Here, for example, are
=== modified file 'lisp/calendar/diary-lib.el'
*** lisp/calendar/diary-lib.el 2014-01-01 07:43:34 +0000
--- lisp/calendar/diary-lib.el 2014-09-01 12:28:23 +0000
***************
*** 1023,1029 ****
(calendar-set-mode-line (format "Diary for %s" (cdr empty))))
(unless (car empty) ; no entries
(with-current-buffer dbuff
! (let ((window (display-buffer (current-buffer))))
;; d-s-p is passed from diary-list-entries.
(set-window-point window diary-saved-point)
(set-window-start window (point-min)))))))
--- 1023,1029 ----
(calendar-set-mode-line (format "Diary for %s" (cdr empty))))
(unless (car empty) ; no entries
(with-current-buffer dbuff
! (let ((window (display-buffer (current-buffer) t)))
;; d-s-p is passed from diary-list-entries.
(set-window-point window diary-saved-point)
(set-window-start window (point-min)))))))
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
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 12:27 ` martin rudalics
1 sibling, 1 reply; 21+ messages in thread
From: Glenn Morris @ 2014-09-01 17:37 UTC (permalink / raw)
To: Stephen Berman; +Cc: 18381
Stephen Berman wrote:
> the fix should be committed to emacs-24.
At this stage, that depends how severe the problem is (not very IMO),
and how safe any fix is. At first sight, using ACTION = t with
display-buffer doesn't seem too safe to me. That code's been the way it
is for many years, so a bisection to find the cause might be
informative.
BTW minimal example is
echo "Monday foo" > ~/diary
emacs -Q --eval '(setq calendar-view-diary-initially-flag t)' \
--eval '(progn (diary) (calendar))'
At some point all this stuff should be rewritten to use modern methods
of displaying buffers, but not now, obviously.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-01 17:37 ` Glenn Morris
@ 2014-09-01 18:38 ` Stephen Berman
2014-09-04 0:34 ` Glenn Morris
0 siblings, 1 reply; 21+ messages in thread
From: Stephen Berman @ 2014-09-01 18:38 UTC (permalink / raw)
To: Glenn Morris; +Cc: 18381
On Mon, 01 Sep 2014 13:37:41 -0400 Glenn Morris <rgm@gnu.org> wrote:
> Stephen Berman wrote:
>
>> the fix should be committed to emacs-24.
>
> At this stage, that depends how severe the problem is (not very IMO),
> and how safe any fix is.
Ok. Though it is apparently a regression, I agree it isn't severe,
though a bit jarring.
> At first sight, using ACTION = t with
> display-buffer doesn't seem too safe to me.
AFAICS the worst that could happen is the diary (or other calendar
listing generated by using calendar-in-read-only-buffer) being displayed
in two different windows of the same frame, which doesn't seem as bad as
the diary stomping on the calendar. Or is there another bad effect
you're worried about?
> That code's been the way it
> is for many years, so a bisection to find the cause might be
> informative.
I'm sure it would, but since the only build I have that doesn't show the
issue is from openSUSE of 2014-01-23 and lacks a bzr revno, I'm afraid
this would be quite a time-consuming effort...
Steve Berman
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-01 18:38 ` Stephen Berman
@ 2014-09-04 0:34 ` Glenn Morris
0 siblings, 0 replies; 21+ messages in thread
From: Glenn Morris @ 2014-09-04 0:34 UTC (permalink / raw)
To: martin rudalics; +Cc: Stephen Berman, 18381
Bisected to:
revno: 115301
committer: martin rudalics <rudalics AT gmx.at>
branch nick: trunk
timestamp: Sat 2013-11-30 10:25:31 +0100
message:
Support resizing frames and windows pixelwise.
At first glance, there seems no reason why that would cause this, so
perhaps it was some unintended side-effect.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
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-04 12:27 ` martin rudalics
2014-09-04 18:04 ` Glenn Morris
1 sibling, 1 reply; 21+ messages in thread
From: martin rudalics @ 2014-09-04 12:27 UTC (permalink / raw)
To: Stephen Berman, 18381
> 0. emacs -Q
> 1. Type `M-x calendar' and then `i d' to create a diary file with an
> entry for today.
> 2. M-x customize-option RET calendar-view-diary-initially-flag RET,
> toggle the value to `On' and save for current session.
> 3. M-x diary => The diary entry made in step 1 is displayed (in the
> Fancy Diary) in the lower window (which is not the selected window).
The window you're using to display `diary' here ...
> 4. M-x calendar => The lower window resizes to fit the Calendar, which
> is fleetingly displayed in it but then replaced by the Fancy Diary
> display (in the same resized window).
... is the same window where you first show the calendar here. As a
consequence, `display-buffer-in-previous-window' will find a window
where you have shown `diary' already and reuse that window. I'm not
sure what's the best thing to do here - maybe we should remove
`display-buffer-in-previous-window' from
`display-buffer-fallback-action' in `calendar-in-read-only-buffer'.
martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-04 12:27 ` martin rudalics
@ 2014-09-04 18:04 ` Glenn Morris
2014-09-04 19:48 ` Glenn Morris
2014-09-05 10:46 ` martin rudalics
0 siblings, 2 replies; 21+ messages in thread
From: Glenn Morris @ 2014-09-04 18:04 UTC (permalink / raw)
To: martin rudalics; +Cc: Stephen Berman, 18381
martin rudalics wrote:
> ... is the same window where you first show the calendar here. As a
> consequence, `display-buffer-in-previous-window' will find a window
> where you have shown `diary' already and reuse that window. I'm not
> sure what's the best thing to do here - maybe we should remove
> `display-buffer-in-previous-window' from
> `display-buffer-fallback-action' in `calendar-in-read-only-buffer'.
The most conservative fix would seem to be to only change
calendar-basic-setup, where it calls diary-view-entries.
I guess what we really want to say is "don't display the diary in the
window that you just displayed the calendar in" (is that possible?), but
failing that, simply removing display-buffer-in-previous-window seems to
work. What's the cleanest way to do that? Binding
display-buffer-overriding-action or display-buffer-fallback-action
to an explicit list? display-buffer-fallback-action does not have the
friendliest format to make "remove element X" straightforward,
and is marked as a constant.
*** lisp/calendar/calendar.el 2014-03-17 16:04:32 +0000
--- lisp/calendar/calendar.el 2014-09-04 17:57:25 +0000
***************
*** 1432,1438 ****
(calendar-generate-window month year)
(if (and calendar-view-diary-initially-flag
(calendar-date-is-visible-p date))
! (diary-view-entries))))
(if calendar-view-holidays-initially-flag
(let* ((diary-buffer (get-file-buffer diary-file))
(diary-window (if diary-buffer (get-buffer-window diary-buffer)))
--- 1432,1444 ----
(calendar-generate-window month year)
(if (and calendar-view-diary-initially-flag
(calendar-date-is-visible-p date))
! (let ((display-buffer-fallback-action
! '((display-buffer--maybe-same-window
! display-buffer-reuse-window
! display-buffer--maybe-pop-up-frame-or-window
! display-buffer-use-some-window
! display-buffer-pop-up-frame))))
! (diary-view-entries)))))
(if calendar-view-holidays-initially-flag
(let* ((diary-buffer (get-file-buffer diary-file))
(diary-window (if diary-buffer (get-buffer-window diary-buffer)))
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-04 18:04 ` Glenn Morris
@ 2014-09-04 19:48 ` Glenn Morris
2014-09-04 22:39 ` Glenn Morris
2014-09-05 10:46 ` martin rudalics
1 sibling, 1 reply; 21+ messages in thread
From: Glenn Morris @ 2014-09-04 19:48 UTC (permalink / raw)
To: martin rudalics; +Cc: Stephen Berman, 18381
Glenn Morris wrote:
> I guess what we really want to say is "don't display the diary in the
> window that you just displayed the calendar in" (is that possible?),
Maybe "don't display the diary in the selected window" would suffice.
Sounds like adding '(inhibit-same-window . t) to display-buffer's alist
might do, but I cannot figure out how to do that.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
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
0 siblings, 2 replies; 21+ messages in thread
From: Glenn Morris @ 2014-09-04 22:39 UTC (permalink / raw)
To: martin rudalics; +Cc: Stephen Berman, 18381
Glenn Morris wrote:
> Maybe "don't display the diary in the selected window" would suffice.
> Sounds like adding '(inhibit-same-window . t) to display-buffer's alist
> might do, but I cannot figure out how to do that.
Following works, but having to use `ignore' seems odd?
*** lisp/calendar/calendar.el 2014-03-17 16:04:32 +0000
--- lisp/calendar/calendar.el 2014-09-04 22:36:56 +0000
***************
*** 1432,1438 ****
(calendar-generate-window month year)
(if (and calendar-view-diary-initially-flag
(calendar-date-is-visible-p date))
! (diary-view-entries))))
(if calendar-view-holidays-initially-flag
(let* ((diary-buffer (get-file-buffer diary-file))
(diary-window (if diary-buffer (get-buffer-window diary-buffer)))
--- 1432,1440 ----
(calendar-generate-window month year)
(if (and calendar-view-diary-initially-flag
(calendar-date-is-visible-p date))
! (let ((display-buffer-overriding-action
! '(ignore . ((inhibit-same-window . t)))))
! (diary-view-entries)))))
(if calendar-view-holidays-initially-flag
(let* ((diary-buffer (get-file-buffer diary-file))
(diary-window (if diary-buffer (get-buffer-window diary-buffer)))
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-04 22:39 ` Glenn Morris
@ 2014-09-04 23:40 ` Glenn Morris
2014-09-05 10:46 ` martin rudalics
1 sibling, 0 replies; 21+ messages in thread
From: Glenn Morris @ 2014-09-04 23:40 UTC (permalink / raw)
To: martin rudalics; +Cc: Stephen Berman, 18381
Glenn Morris wrote:
> Following works, but having to use `ignore' seems odd?
Oh, apparently `nil' works too.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-04 18:04 ` Glenn Morris
2014-09-04 19:48 ` Glenn Morris
@ 2014-09-05 10:46 ` martin rudalics
1 sibling, 0 replies; 21+ messages in thread
From: martin rudalics @ 2014-09-05 10:46 UTC (permalink / raw)
To: Glenn Morris; +Cc: Stephen Berman, 18381
> The most conservative fix would seem to be to only change
> calendar-basic-setup, where it calls diary-view-entries.
Is that sufficient? I thought the problematic call is that of
`display-buffer' in `calendar-in-read-only-buffer'. I must admit that I
have a hard time debugging calendar code.
> I guess what we really want to say is "don't display the diary in the
> window that you just displayed the calendar in" (is that possible?),
We can make that window softly dedicated to the calendar. But that's
not very clean.
> but
> failing that, simply removing display-buffer-in-previous-window seems to
> work. What's the cleanest way to do that? Binding
> display-buffer-overriding-action or display-buffer-fallback-action
> to an explicit list? display-buffer-fallback-action does not have the
> friendliest format to make "remove element X" straightforward,
> and is marked as a constant.
If we can identify the specific `display-buffer' or `pop-to-buffer'
calls in the calendar or diary code, we should pass it via the ACTION
argument. That is, pass the value of `display-buffer-fallback-action'
with `display-buffer-in-previous-window' removed.
`display-buffer-overriding-action' is too drastic here and
`display-buffer-fallback-action' should not be used indeed.
Eventually, the code should be revised anyway. For example, when a
window can be split, apparently the following sequence of actions is
performed:
(1) The calendar is displayed and its window is fit to the buffer.
(2) The diary is displayed in a window split off from the calendar
window annihilating the effort of `fit-window-to-buffer' and leaving
me with some two lines of the calendar.
martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
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
1 sibling, 1 reply; 21+ messages in thread
From: martin rudalics @ 2014-09-05 10:46 UTC (permalink / raw)
To: Glenn Morris; +Cc: Stephen Berman, 18381
>> Maybe "don't display the diary in the selected window" would suffice.
>> Sounds like adding '(inhibit-same-window . t) to display-buffer's alist
>> might do, but I cannot figure out how to do that.
>
> Following works, but having to use `ignore' seems odd?
> ! (let ((display-buffer-overriding-action
> ! '(ignore . ((inhibit-same-window . t)))))
> ! (diary-view-entries)))))
Stephen's original proposal would be cleaner provided we are sure that
the calendar window is always selected when `display-buffer' is called.
Is `calendar-in-read-only-buffer' presumably only executed in a state
where the calendar window is shown and selected?
martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-05 10:46 ` martin rudalics
@ 2014-09-05 16:14 ` Glenn Morris
2014-09-06 8:52 ` martin rudalics
0 siblings, 1 reply; 21+ messages in thread
From: Glenn Morris @ 2014-09-05 16:14 UTC (permalink / raw)
To: martin rudalics; +Cc: Stephen Berman, 18381
martin rudalics wrote:
>> ! (let ((display-buffer-overriding-action
>> ! '(ignore . ((inhibit-same-window . t)))))
>> ! (diary-view-entries)))))
>
> Stephen's original proposal would be cleaner provided we are sure that
> the calendar window is always selected when `display-buffer' is called.
I disagree, the above seems cleaner to me. I don't like changing a
general-purpose function to fix a specific problem.
Why do you say "`display-buffer-overriding-action' is too drastic"?
It seems fine to me. Since coming up with that form, I've noticed that
isearch.el and lisp.el use something similar (or identical).
I'm inclined to commit this solution...
> Is `calendar-in-read-only-buffer' presumably only executed in a state
> where the calendar window is shown and selected?
I don't think so, no.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-05 16:14 ` Glenn Morris
@ 2014-09-06 8:52 ` martin rudalics
2014-09-08 6:04 ` Glenn Morris
0 siblings, 1 reply; 21+ messages in thread
From: martin rudalics @ 2014-09-06 8:52 UTC (permalink / raw)
To: Glenn Morris; +Cc: Stephen Berman, 18381
> I disagree, the above seems cleaner to me. I don't like changing a
> general-purpose function to fix a specific problem.
Then I probably misinterpreted his patch. What is the "general-purpose
function" you intend here?
In general, if an application uses `display-buffer' or `pop-to-buffer'
directly, the application should enclose the preferred way to display
the buffer (or where not to display it) in the ACTION argument.
`display-buffer-overriding-action' should be only used as a last resort:
For example, when the targeted `display-buffer' call is nested in some
macro, in which case, however, the binding will probably affect any
other `display-buffer' call within that macro. Or, when the application
deliberately wants to preclude any form of users' customization.
> Why do you say "`display-buffer-overriding-action' is too drastic"?
> It seems fine to me. Since coming up with that form, I've noticed that
> isearch.el and lisp.el use something similar (or identical).
>
> I'm inclined to commit this solution...
Saying "don't use the selected window" should never harm here (a user
would never want to override that, I presume) so you should be on the
safe side side with your solution. Still I wonder why you can't change
`display-buffer' calls directly here.
>> Is `calendar-in-read-only-buffer' presumably only executed in a state
>> where the calendar window is shown and selected?
>
> I don't think so, no.
But wouldn't then using `display-buffer-overriding-action' preclude the
use of another window which is at that time shown and selected?
martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-06 8:52 ` martin rudalics
@ 2014-09-08 6:04 ` Glenn Morris
2014-09-08 20:32 ` Stephen Berman
0 siblings, 1 reply; 21+ messages in thread
From: Glenn Morris @ 2014-09-08 6:04 UTC (permalink / raw)
To: martin rudalics; +Cc: Stephen Berman, 18381
martin rudalics wrote:
> Then I probably misinterpreted his patch. What is the "general-purpose
> function" you intend here?
The reported issue is to do with calendar-view-diary-initially-flag non-nil,
so (in emacs-24) I prefer to fix that specific case and nothing more,
rather than changing the general function calendar-in-read-only-buffer
and the "can get called every time you view the diary" diary-simple-display.
I'm sure the general way in which calendar displays things can be
modernized (e.g. cal-x is probably unnecessary these days) to use
display-buffer's newer features, but it's not on my agenda right now.
So I committed my thing to emacs-24 and we'll see how it goes.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-08 6:04 ` Glenn Morris
@ 2014-09-08 20:32 ` Stephen Berman
2014-09-09 1:26 ` Glenn Morris
0 siblings, 1 reply; 21+ messages in thread
From: Stephen Berman @ 2014-09-08 20:32 UTC (permalink / raw)
To: Glenn Morris; +Cc: 18381
On Mon, 08 Sep 2014 02:04:43 -0400 Glenn Morris <rgm@gnu.org> wrote:
> martin rudalics wrote:
>
>> Then I probably misinterpreted his patch. What is the "general-purpose
>> function" you intend here?
>
> The reported issue is to do with calendar-view-diary-initially-flag non-nil,
> so (in emacs-24) I prefer to fix that specific case and nothing more,
> rather than changing the general function calendar-in-read-only-buffer
> and the "can get called every time you view the diary" diary-simple-display.
>
> I'm sure the general way in which calendar displays things can be
> modernized (e.g. cal-x is probably unnecessary these days) to use
> display-buffer's newer features, but it's not on my agenda right now.
>
> So I committed my thing to emacs-24 and we'll see how it goes.
Thanks.
Steve Berman
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-08 20:32 ` Stephen Berman
@ 2014-09-09 1:26 ` Glenn Morris
2014-09-09 6:58 ` martin rudalics
0 siblings, 1 reply; 21+ messages in thread
From: Glenn Morris @ 2014-09-09 1:26 UTC (permalink / raw)
To: Stephen Berman; +Cc: 18381
Actually it's still not 100% right...
emacs -Q
M-x diary
M-x calendar
M-x diary -> clobbered calendar window; not so in 24.3
I see now that the cause is that the pixelwise change that I bisected to
earlier added display-buffer-in-previous-window to
display-buffer-fallback-action - it wasn't there before.
So I can restore the 24.3 behaviour by using this horrible thing:
(let ((display-buffer-fallback-action
(list (delq 'display-buffer-in-previous-window
(copy-sequence (car display-buffer-fallback-action))))))
...)
This is Not The Right Thing, but ought to restore 24.3-like behaviour.
I think what I really want is a way to say to display-buffer:
never use a window showing buffer X.
Is that doable?
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-09 1:26 ` Glenn Morris
@ 2014-09-09 6:58 ` martin rudalics
2014-09-09 7:44 ` Glenn Morris
0 siblings, 1 reply; 21+ messages in thread
From: martin rudalics @ 2014-09-09 6:58 UTC (permalink / raw)
To: Glenn Morris, Stephen Berman; +Cc: 18381
> emacs -Q
> M-x diary
> M-x calendar
> M-x diary -> clobbered calendar window; not so in 24.3
>
> I see now that the cause is that the pixelwise change that I bisected to
> earlier added display-buffer-in-previous-window to
> display-buffer-fallback-action - it wasn't there before.
>
> So I can restore the 24.3 behaviour by using this horrible thing:
>
> (let ((display-buffer-fallback-action
> (list (delq 'display-buffer-in-previous-window
> (copy-sequence (car display-buffer-fallback-action))))))
> ...)
>
> This is Not The Right Thing, but ought to restore 24.3-like behaviour.
That's what I meant earlier when I said that
> > The window you're using to display `diary' here ...
> > ... is the same window where you first show the calendar here. As a
> > consequence, `display-buffer-in-previous-window' will find a window
> > where you have shown `diary' already and reuse that window. I'm not
> > sure what's the best thing to do here - maybe we should remove
> > `display-buffer-in-previous-window' from
> > `display-buffer-fallback-action' in `calendar-in-read-only-buffer'.
but obviously we should do something like
(let ((display-buffer-overriding-action
(list (delq 'display-buffer-in-previous-window
(copy-sequence (car display-buffer-fallback-action))))))
...)
because (as you remarked earlier) `display-buffer-fallback-action' is a
constant and should not be changed by the user or an application.
> I think what I really want is a way to say to display-buffer:
> never use a window showing buffer X.
>
> Is that doable?
You can mark the calendar window as softly dedicated to its buffer,
ideally only as long as `diary' wants to use it. Otherwise, we could
invent new alist entries à la `inhibit-same-window':
`inhibit-windows' (whose value would be a list of windows that should
not be used), and/or
`inhibit-windows-on' (whose value would be a list of buffers that should
remain displayed),
not for Emacs 24.4, in any case.
You still didn't tell me who actually is responsible for displaying the
calendar and then the diary. 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.
martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-09 6:58 ` martin rudalics
@ 2014-09-09 7:44 ` Glenn Morris
2014-09-09 9:18 ` martin rudalics
2014-09-09 13:00 ` Stefan Monnier
0 siblings, 2 replies; 21+ messages in thread
From: Glenn Morris @ 2014-09-09 7:44 UTC (permalink / raw)
To: martin rudalics; +Cc: Stephen Berman, 18381
martin rudalics wrote:
>> (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.
> 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.
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?
At the moment I think I'm going to settle for just getting 24.3
behaviour back.
Perhaps this should all be rewritten using modern display syntax rather
than trying to coerce it to behave piecemeal.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-09 7:44 ` Glenn Morris
@ 2014-09-09 9:18 ` martin rudalics
2014-09-09 18:13 ` Glenn Morris
2014-09-09 13:00 ` Stefan Monnier
1 sibling, 1 reply; 21+ messages in thread
From: martin rudalics @ 2014-09-09 9:18 UTC (permalink / raw)
To: Glenn Morris; +Cc: Stephen Berman, 18381
>>> (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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-09 7:44 ` Glenn Morris
2014-09-09 9:18 ` martin rudalics
@ 2014-09-09 13:00 ` Stefan Monnier
1 sibling, 0 replies; 21+ messages in thread
From: Stefan Monnier @ 2014-09-09 13:00 UTC (permalink / raw)
To: Glenn Morris; +Cc: Stephen Berman, 18381
>>> (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.
Indeed, they both have downsides. I think as a "stop-gap" fix, I think
the first is preferable.
Stefan
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#18381: 24.3.93; Diary can wrongly be displayed in Calendar's window
2014-09-09 9:18 ` martin rudalics
@ 2014-09-09 18:13 ` Glenn Morris
0 siblings, 0 replies; 21+ messages in thread
From: Glenn Morris @ 2014-09-09 18:13 UTC (permalink / raw)
To: martin rudalics; +Cc: Stephen Berman, 18381
I went with the following.
(I suspect it's going to be like when you press on a bubble in some
wallpaper, and another one pops up somewhere else...)
@@ -901,12 +900,20 @@
;;; (diary-include-other-diary-files) ; recurse
;;; (run-hooks 'diary-list-entries-hook))
(unless list-only
- (if (and diary-display-function
- (listp diary-display-function))
- ;; Backwards compatibility.
- (run-hooks 'diary-display-function)
- (funcall (or diary-display-function
- 'diary-simple-display))))
+ ;; Avoid M-x diary; M-x calendar; M-x diary
+ ;; clobbering the calendar window.
+ ;; FIXME this is not the right solution.
+ (let ((display-buffer-fallback-action
+ (list (delq
+ 'display-buffer-in-previous-window
+ (copy-sequence
+ (car display-buffer-fallback-action))))))
+ (if (and diary-display-function
+ (listp diary-display-function))
+ ;; Backwards compatibility.
+ (run-hooks 'diary-display-function)
+ (funcall (or diary-display-function
+ 'diary-simple-display)))))
(run-hooks 'diary-hook)))))
(and temp-buff (buffer-name temp-buff) (kill-buffer temp-buff)))
(or d-incp (message "Preparing diary...done"))
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2014-09-09 18:13 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2014-09-09 18:13 ` Glenn Morris
2014-09-09 13:00 ` Stefan Monnier
2014-09-05 10:46 ` martin rudalics
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).