# HG changeset patch # User Glenn Morris # Date 1254884266 0 # Node ID bc225649d1e5b472adb5b69290db9f547df36ef4 # Parent 3cdeeb563149fcf746d4ab9aee29e94b42084d34 (calendar-basic-setup): In the wide frame case, show the original buffer rather than a random one. diff -r 3cdeeb563149 -r bc225649d1e5 lisp/ChangeLog --- a/lisp/ChangeLog Wed Oct 07 02:52:37 2009 +0000 +++ b/lisp/ChangeLog Wed Oct 07 02:57:46 2009 +0000 @@ -1,3 +1,8 @@ +2009-10-07 Glenn Morris + + * calendar/calendar.el (calendar-basic-setup): In the wide frame case, + show the original buffer rather than a random one. + 2009-10-07 Markus Rost * help.el (describe-no-warranty): Place point in a slightly better diff -r 3cdeeb563149 -r bc225649d1e5 lisp/calendar/calendar.el --- a/lisp/calendar/calendar.el Wed Oct 07 02:52:37 2009 +0000 +++ b/lisp/calendar/calendar.el Wed Oct 07 02:57:46 2009 +0000 @@ -1280,58 +1280,60 @@ and year, else uses the current date. If NODISPLAY is non-nil, don't display the generated calendar." (interactive "P") - (set-buffer (get-buffer-create calendar-buffer)) - (calendar-mode) - (let* ((pop-up-windows t) - ;; Not really needed now, but means we use exactly the same - ;; behavior as before in the non-wide case (see below). - (split-height-threshold 1000) - (date (if arg (calendar-read-date t) - (calendar-current-date))) - (month (calendar-extract-month date)) - (year (calendar-extract-year date))) - (calendar-increment-month month year (- calendar-offset)) - ;; Display the buffer before calling calendar-generate-window so that it - ;; can get a chance to adjust the window sizes to the frame size. - (unless nodisplay - ;; We want a window configuration that looks something like - ;; X X | Y - ;; - ----- - ;; C Z | C - ;; where C is the calendar, and the LHS is the traditional, - ;; non-wide frame, and the RHS is the wide frame case. - ;; We should end up in the same state regardless of whether the - ;; windows were initially split or not. - ;; Previously, we only thought about the non-wide case. - ;; We could just set split-height-threshold to 1000, relying on - ;; the fact that the window splitting treated a single window as - ;; a special case and would always split it (vertically). The - ;; same thing does not work in the wide-frame case, so now we do - ;; the splitting by hand. - ;; See discussion in bug#1806. - ;; Actually, this still does not do quite the right thing in the - ;; wide frame case if started from a configuration like the LHS. - ;; Eg if you start with a non-wide frame, call calendar, then - ;; make the frame wider. This one is problematic because you - ;; might need to split a totally unrelated window. Oh well, it - ;; seems unlikely, and perhaps respecting the original layout is - ;; the right thing in that case. - ;; - ;; Is this a wide frame? If so, split it horizontally. - (if (window-splittable-p t) (split-window-horizontally)) - (pop-to-buffer calendar-buffer) - ;; Has the window already been split vertically? - (when (and (not (window-dedicated-p)) - (window-full-height-p)) - (let ((win (split-window-vertically))) - ;; Show something else in the upper window. - (switch-to-buffer (other-buffer)) - ;; Switch to the lower window with the calendar buffer. - (select-window win)))) - (calendar-generate-window month year) - (if (and calendar-view-diary-initially-flag - (calendar-date-is-visible-p date)) - (diary-view-entries))) + (let ((buff (current-buffer))) + (set-buffer (get-buffer-create calendar-buffer)) + (calendar-mode) + (let* ((pop-up-windows t) + ;; Not really needed now, but means we use exactly the same + ;; behavior as before in the non-wide case (see below). + (split-height-threshold 1000) + (date (if arg (calendar-read-date t) + (calendar-current-date))) + (month (calendar-extract-month date)) + (year (calendar-extract-year date))) + (calendar-increment-month month year (- calendar-offset)) + ;; Display the buffer before calling calendar-generate-window so that it + ;; can get a chance to adjust the window sizes to the frame size. + (unless nodisplay + ;; We want a window configuration that looks something like + ;; X X | Y + ;; - ----- + ;; C Z | C + ;; where C is the calendar, and the LHS is the traditional, + ;; non-wide frame, and the RHS is the wide frame case. + ;; We should end up in the same state regardless of whether the + ;; windows were initially split or not. + ;; Previously, we only thought about the non-wide case. + ;; We could just set split-height-threshold to 1000, relying on + ;; the fact that the window splitting treated a single window as + ;; a special case and would always split it (vertically). The + ;; same thing does not work in the wide-frame case, so now we do + ;; the splitting by hand. + ;; See discussion in bug#1806. + ;; Actually, this still does not do quite the right thing in the + ;; wide frame case if started from a configuration like the LHS. + ;; Eg if you start with a non-wide frame, call calendar, then + ;; make the frame wider. This one is problematic because you + ;; might need to split a totally unrelated window. Oh well, it + ;; seems unlikely, and perhaps respecting the original layout is + ;; the right thing in that case. + ;; + ;; Is this a wide frame? If so, split it horizontally. + (if (window-splittable-p t) (split-window-horizontally)) + (pop-to-buffer calendar-buffer) + ;; Has the window already been split vertically? + (when (and (not (window-dedicated-p)) + (window-full-height-p)) + (let ((win (split-window-vertically))) + ;; In the upper window, show whatever was visible before. + ;; This looks better than using other-buffer. + (switch-to-buffer buff) + ;; Switch to the lower window with the calendar buffer. + (select-window win)))) + (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)))