bug#2199: 23.0.60; calendar marks and font-lock-mode

[Stephen Berman <stephen.berman@gmx.net>]

On Sat, 07 Feb 2009 20:58:17 -0500 Glenn Morris <rgm@gnu.org> wrote:

> severity 2199 minor
> stop
>
> I've taken out the checking of font-lock-mode. The implementation was
> broken, since it just depended on which buffer was current when one
> loaded calendar.el. And the idea didn't make sense either, since the
> relevant features don't use font-lock.
>
> Note that when run from --daemon, (display-color-p) apparently returns
> nil (no display at all, I guess). So if you happen to load calendar.el
> then, again you won't get faces. Don't know how to fix that, other
> than to say customize the markers appropriately if you want to do
> that, rather than relying on the defaults.
>
>
> Stephen Berman wrote:
>
>> There are two additional oddities: 
>> (i) Typing `q' in the *Calendar* buffer does nothing -- but on the next
>> keystroke, whatever it is, the *Calendar* buffer does disappear. 
>
> No idea about that. I guess the buffer is not getted buried for some
> reason.

I found out what's happening with `q': when I do `emacsclient -c', the
frame initially shows only the *scratch* buffer.  I now type `M-x
calendar', which as usual splits the screen vertically, with the
*Calendar* buffer below and *scratch* above.  Now type `M-:
(calendar-window-list)': it returns (something like) "(#<window 8 on
*Calendar*> #<window 4 on diary>)", and indeed `C-x C-b' reveals that
the diary buffer is a live buffer.  So when I type `q' in the *Calendar*
buffer, calendar-hide-window is applied to the unseen diary buffer and
to the displayed *Calendar* buffer, which explains my observation.  What
remains to be explained, and fixed, is why the diary buffer is not in a
displayed window, although its window is in calendar-window-list.  I
think this has to do with --daemon, because when I start Emacs without
--daemon but with the same ~/.emacs, then the diary is initially
displayed below and the splash screen above; but with --daemon neither
of these is displayed upon invoking `emacsclient -c'.

>> (ii) `M-x diary' correctly displays today's diary entries, but the mode
>> line consists of the string "---Diar---", rather than the expected
>> "-----------------Diary for Thursday, February 5, 2009-----------------"
>
> Couldn't reproduce that. 

Sorry, I gave the wrong recipe: after invoking `emacsclient -c', just do
`C-x b diary' and you should get the diary buffer with the truncated
mode line.

>                          It tries to fit to the width of the frame, so
> I can imagine it getting confused it if somehow tries to run from
> --daemon, when there is no frame.

On Sun, 08 Feb 2009 15:44:04 -0500 Glenn Morris <rgm@gnu.org> wrote:

> Glenn Morris wrote:
>
>> Note that when run from --daemon, (display-color-p) apparently returns
>> nil (no display at all, I guess). So if you happen to load calendar.el
>> then, again you won't get faces.
>
> Actually, I'll probably just take that test out too. I don't imagine
> B&W displays are too common any more.

Thanks for removing this too.  I think your comment in calendar.el on
this point probably has wider application:

;; They also used to check display-color-p, but that is a problem if
;; loaded from --daemon.  Since BW displays are rare now, this was
;; also taken out.  The way to keep it would be to have nil mean do a
;; runtime check whenever this variable is used.

Cf. also bug#2138 and Dan Nicolaescu's remark:

> Not really, this is not a problem with --daemon, it's a problem in the
> ediff implementation that it evaluates ediff-window-setup-function at
> load time.  This is not appropriate anymore now when you can have both
> X11 and tty frames in the same emacs session.

Steve Berman