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

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

[Stephen Berman]

In GNU Emacs 23.0.60.31 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
 of 2009-01-31 on escher

Let ~/.emacs consist of the following three sexps:

(add-hook 'calendar-today-visible-hook 'calendar-mark-today)
(setq calendar-mark-diary-entries-flag t)
(setq calendar-mark-holidays-flag t)

(i) Start Emacs by invoking `emacs', then type `M-x calendar'.
=> In the Calendar, today's date is marked with `=', diary entries are
marked with `+' and holidays are marked with `*'.

(ii) Start Emacs by invoking `emacs', type `q' to quit the splash
screen, then type `M-x calendar'.
=> In the Calendar, today's date is marked with the face calendar-today,
diary entries are marked with the face diary and holidays are marked
with the face holiday.

The difference between (i) and (ii) is that the splash screen is in
Fundamental mode and in this mode font-lock-mode is nil, which makes the
calendar marks use string displays rather than faces, due, I believe, to
this change:

2008-04-02  Glenn Morris  <rgm@gnu.org>

	* calendar/calendar.el (diary-entry-marker, calendar-today-marker)
	(calendar-holiday-marker, mark-visible-calendar-date):
	* calendar/diary-lib.el (fancy-diary-display):
	Check for font-lock-mode before using faces.

This change is justified by the following comment in calendar.el: "These
[defcustoms] don't respect changes in font-lock-mode after loading."  So
maybe having to live with (i) is the lesser evil (the faces can (only)
be restored in the same Emacs session by explicitly changing the
variables' values in Custom or with setq).

Steve Berman

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

[Stephen Berman]

The issue seems to be more complicated than I thought.  Calendar marks
are displayed with strings instead of faces not only when Calendar is
invoked from a buffer in which font-lock-mode is nil (e.g. in
Fundamental mode), as in my OP, but also in the following case:

Let ~/.emacs consist of the following four sexps:

(add-hook 'today-visible-calendar-hook 'calendar-mark-today)
(setq calendar-mark-diary-entries-flag t)
(setq calendar-mark-holidays-flag t)
(appt-activate 1)

Also, let ~/diary contain entries for today (either date or day).

Now start Emacs like this:

$ emacs --daemon
$ emacsclient -c

The frame that now opens displays the *scratch* buffer only (the diary
is not displayed), in which font-lock-mode is t.  Nevertheless, after
`M-x calendar' the Calendar displays string marks rather than faces.

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. 
(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-----------------"

Note that if I start Emacs simply by invoking `emacs' (still with the
above ~/.emacs), then everything is as expected: the frame is vertically
split, above the splash screen, below today's diary entries, and `M-x
calendar' displays the Calendar with faces.

Note, too, that if instead of `emacs --daemon' I invoke Emacs with
`emacs -nw -f server-start' (still with the above ~/.emacs), then in the
terminal display the frame is vertically split, above *scratch*, below
today's diary entries, and `M-x calendar' displays the Calendar with
faces (likewise in the X11 frame opened by `emacsclient -c').

Finally, if I comment out "(appt-activate 1)" in the above ~/.emacs,
then start Emacs with `emacs --daemon' and `emacsclient -c', then the
behavior is as in my OP: Calendar marks are displayed with strings
instead of faces only when Calendar is invoked from a buffer in which
font-lock-mode is nil (e.g. in Fundamental mode)

Steve Berman

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

[Glenn Morris]

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.

> (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. 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.

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

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> severity 2199 minor
bug#2199: 23.0.60; calendar marks and font-lock-mode
Warning: Unknown package 'calendar'
Severity set to `minor' from `normal'

> stop
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

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

[Glenn Morris]

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.

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

[Stephen Berman]

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

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

[Glenn Morris]

Stephen Berman wrote:

>  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'.

With specified .emacs:

emacs --daemon
emacsclient -c
M-x calendar

(let (wlist)
  (walk-windows (lambda (w) (push w wlist)) nil t)
  wlist)

gives:

(#<window 5 on *scratch*> #<window 4 on diary>
 #<window 1 on *GNU Emacs*> #<window 9 on *Calendar*>)

So there's an invisible frame with the splash and diary buffers.

Changing the last argument of walk-windows in calendar-window-list
from t to 0 is probably good enough.

> 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.

As expected, window-edges is confused by --daemon:

emacs  -Q --daemon --eval "(setq in (window-inside-edges) out (window-edges))"
emacsclient -c

in = (0 1 10 8)
out = (0 1 10 9)

No idea what to do about that.

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

[Glenn Morris]

Glenn Morris wrote (on Mon, 9 Feb 2009 at 15:04 -0500):

> So there's an invisible frame with the splash and diary buffers.
> 
> Changing the last argument of walk-windows in calendar-window-list
> from t to 0 is probably good enough.

But that breaks the behaviour if I have multiple frames open on
different workspaces in Window Maker. Only buffers on the current
workspace are buried. So I have no idea what to do about this either.

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

[Stefan Monnier]

>> So there's an invisible frame with the splash and diary buffers.
>> 
>> Changing the last argument of walk-windows in calendar-window-list
>> from t to 0 is probably good enough.

> But that breaks the behaviour if I have multiple frames open on
> different workspaces in Window Maker. Only buffers on the current
> workspace are buried. So I have no idea what to do about this either.

Not sure I understand what you mean by "different workspaces in Window
Maker"?  I'm guessing that these are different X displays, maybe of the
form "foo:0.0" and "foo:0.1"?


        Stefan

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

[Glenn Morris]

Stefan Monnier wrote:

>>> Changing the last argument of walk-windows in calendar-window-list
>>> from t to 0 is probably good enough.
>
>> But that breaks the behaviour if I have multiple frames open on
>> different workspaces in Window Maker.

I was wrong, it doesn't make a difference in that regard, so I can
install that.

> Not sure I understand what you mean by "different workspaces in Window
> Maker"?  I'm guessing that these are different X displays, maybe of the
> form "foo:0.0" and "foo:0.1"?

No. I probably should have said "virtual desktop"? The different
screens provided by your window manager / "desktop environment", which
you can switch between and move applications between.

I noticed that frames on workspaces other than the current one have a
'visibility frame-parameter of 'icon, which surprised me. Does that
make sense?

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

[Stefan Monnier]

> I noticed that frames on workspaces other than the current one have a
> 'visibility frame-parameter of 'icon, which surprised me. Does that
> make sense?

Yes.  X11 doesn't have a notion of "workspace", fundamentally, so
window-managers simulate it by mapping/unmapping (the X11 terms for
display/hide) the windows according to which windows are displayed in
the current workspace.

Now mapping/unmapping is the same mechanism used to iconify/deiconify
a window, so Emacs treats an unmapped window as "iconified".

Note that window-managers could use other techniques to
hide/show windows.  E.g. they could just move them "out of sight", in
which case Emacs would consider those windows as still "visible" but
with bogus left/right positions.


        Stefan

bug#2199: marked as done (23.0.60; calendar marks and font-lock-mode)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]


Your message dated Tue, 10 Feb 2009 23:00:25 -0500
with message-id <qlwsbxy65i.fsf@fencepost.gnu.org>
and subject line Re: bug#2199: 23.0.60; calendar marks and font-lock-mode
has caused the Emacs bug report #2199,
regarding 23.0.60; calendar marks and font-lock-mode
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
2199: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2199
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3793 bytes --]

From: Stephen Berman <stephen.berman@gmx.net>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; calendar marks and font-lock-mode
Date: Wed, 04 Feb 2009 18:03:36 +0100
Message-ID: <87hc3am8wn.fsf@escher.local.home>

In GNU Emacs 23.0.60.31 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
 of 2009-01-31 on escher

Let ~/.emacs consist of the following three sexps:

(add-hook 'calendar-today-visible-hook 'calendar-mark-today)
(setq calendar-mark-diary-entries-flag t)
(setq calendar-mark-holidays-flag t)

(i) Start Emacs by invoking `emacs', then type `M-x calendar'.
=> In the Calendar, today's date is marked with `=', diary entries are
marked with `+' and holidays are marked with `*'.

(ii) Start Emacs by invoking `emacs', type `q' to quit the splash
screen, then type `M-x calendar'.
=> In the Calendar, today's date is marked with the face calendar-today,
diary entries are marked with the face diary and holidays are marked
with the face holiday.

The difference between (i) and (ii) is that the splash screen is in
Fundamental mode and in this mode font-lock-mode is nil, which makes the
calendar marks use string displays rather than faces, due, I believe, to
this change:

2008-04-02  Glenn Morris  <rgm@gnu.org>

	* calendar/calendar.el (diary-entry-marker, calendar-today-marker)
	(calendar-holiday-marker, mark-visible-calendar-date):
	* calendar/diary-lib.el (fancy-diary-display):
	Check for font-lock-mode before using faces.

This change is justified by the following comment in calendar.el: "These
[defcustoms] don't respect changes in font-lock-mode after loading."  So
maybe having to live with (i) is the lesser evil (the faces can (only)
be restored in the same Emacs session by explicitly changing the
variables' values in Custom or with setq).

Steve Berman



[-- Attachment #3: Type: message/rfc822, Size: 1817 bytes --]

From: Glenn Morris <rgm@gnu.org>
To: 2199-done@emacsbugs.donarmstrong.com
Subject: Re: bug#2199: 23.0.60; calendar marks and font-lock-mode
Date: Tue, 10 Feb 2009 23:00:25 -0500
Message-ID: <qlwsbxy65i.fsf@fencepost.gnu.org>

Glenn Morris wrote:

> emacs  -Q --daemon --eval "(setq in (window-inside-edges) out (window-edges))"
> emacsclient -c
>
> in = (0 1 10 8)
> out = (0 1 10 9)
>
> No idea what to do about that.

I've installed a hacky fix (for calendar) and am closing this bug.