GNU bug report logs -
#2199
23.0.60; calendar marks and font-lock-mode
Previous Next
Full log
Message #30 received at 2199 <at> emacsbugs.donarmstrong.com (full text, mbox):
On Sat, 07 Feb 2009 20:58:17 -0500 Glenn Morris <rgm <at> 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 <at> 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
This bug report was last modified 16 years and 167 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.