odd change in OSX behavior of toolbar in the past few weeks

odd change in OSX behavior of toolbar in the past few weeks

[Randal L. Schwartz]

I have 

(custom-set-variables
 '(menu-bar-mode t)
 '(tool-bar-mode nil nil (tool-bar))
)

in my .emacs on OSX.  That is, I want the menu to be alive, but
I don't care for those icons occupying 3 lines of valueable space.

Up until two weeks ago, a launch of OSX Emacs started nicely.  However,
sometime in the last two (maybe three) weeks, it now starts up *with*
the toolbar in place for half a second, then it animates that to make
it disappear.

This behavior is annoying.  Is there a setting to make it work the
way I want, or at least the way it used to be?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: odd change in OSX behavior of toolbar in the past few weeks

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 08 Jul 2007 20:03:44 -0700, merlyn@stonehenge.com (Randal L. Schwartz) said:

> Up until two weeks ago, a launch of OSX Emacs started nicely.
> However, sometime in the last two (maybe three) weeks, it now starts
> up *with* the toolbar in place for half a second, then it animates
> that to make it disappear.

> This behavior is annoying.  Is there a setting to make it work the
> way I want, or at least the way it used to be?

That's related to the change for the Carbon HIToolbar support.  You
can turn it off by adding -DUSE_MAC_TOOLBAR=0 to CFLAGS, but could you
try to see if the following patch works?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp
Index: src/macterm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
retrieving revision 1.224
diff -c -p -r1.224 macterm.c
*** src/macterm.c	28 Jun 2007 10:08:41 -0000	1.224
--- src/macterm.c	9 Jul 2007 07:40:10 -0000
*************** free_frame_tool_bar (f)
*** 6114,6120 ****
  
        BLOCK_INPUT;
        ShowHideWindowToolbar (FRAME_MAC_WINDOW (f), false,
! 			     f == mac_focus_frame (dpyinfo));
        /* Mac OS X 10.3 does not issue kEventWindowBoundsChanged events
  	 on toolbar visibility change.  */
        mac_handle_origin_change (f);
--- 6114,6122 ----
  
        BLOCK_INPUT;
        ShowHideWindowToolbar (FRAME_MAC_WINDOW (f), false,
! 			     (NILP (Fsymbol_value
! 				    (intern ("frame-notice-user-settings")))
! 			      && f == mac_focus_frame (dpyinfo)));
        /* Mac OS X 10.3 does not issue kEventWindowBoundsChanged events
  	 on toolbar visibility change.  */
        mac_handle_origin_change (f);

Re: odd change in OSX behavior of toolbar in the past few weeks

[Richard Stallman]

Can you try checking out code from various dates
so as to determine which change causes the problem?

Re: odd change in OSX behavior of toolbar in the past few weeks

[Randal L. Schwartz]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

Richard> Can you try checking out code from various dates
Richard> so as to determine which change causes the problem?

By the time I looked again, it was working fine again.

It was fixed recently by this patch:

    diff --git a/lisp/ChangeLog b/lisp/ChangeLog
    index 2123e07..a7cf4d2 100644
    --- a/lisp/ChangeLog
    +++ b/lisp/ChangeLog
    @@ -1,5 +1,7 @@
     2007-07-10  Stefan Monnier  <monnier@iro.umontreal.ca>

    +       * emacs-lisp/cl.el: Load cl-loaddefs.el quietly.
    +
            * vc-arch.el (vc-arch-complete): Remove.
            (vc-arch-revision-completion-table): Use complete-with-action.

    diff --git a/lisp/emacs-lisp/cl.el b/lisp/emacs-lisp/cl.el
    index 233df65..f8b178a 100644
    --- a/lisp/emacs-lisp/cl.el
    +++ b/lisp/emacs-lisp/cl.el
    @@ -628,7 +628,7 @@ If ALIST is non-nil, the new pairs are prepended to it."
     (fmakunbound 'dolist)
     (fmakunbound 'dotimes)
     (fmakunbound 'declare)
    -(load "cl-loaddefs")
    +(load "cl-loaddefs" nil 'quiet)

     ;; This goes here so that cl-macs can find it if it loads right now.
     (provide 'cl-19)     ; usage: (require 'cl-19 "cl")

So there was something about the noisy loading of cl-loaddefs
that forced the toolbar to be shown.  Weird.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: odd change in OSX behavior of toolbar in the past few weeks

[Stefan Monnier]

> So there was something about the noisy loading of cl-loaddefs
> that forced the toolbar to be shown.  Weird.

Weird indeed.  Maybe it's just the fact of outputting a message which causes
some kind of redisplay.  Maybe placing a call to `message' in your .emacs
can result in the same problem.


        Stefan

Re: odd change in OSX behavior of toolbar in the past few weeks

[Randal L. Schwartz]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

Stefan> Weird indeed.  Maybe it's just the fact of outputting a message which
Stefan> causes some kind of redisplay.  Maybe placing a call to `message' in
Stefan> your .emacs can result in the same problem.

Just tested.  No.  Again, weird.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: odd change in OSX behavior of toolbar in the past few weeks

[Randal L. Schwartz]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
Stefan> Weird indeed.  Maybe it's just the fact of outputting a message which
Stefan> causes some kind of redisplay.  Maybe placing a call to `message' in
Stefan> your .emacs can result in the same problem.

Randal> Just tested.  No.  Again, weird.

but (sit-for 1) *does*.  So, if the screen is forced to show something before
it finishes loading my customizations, it makes sense that it would have to
show the toolbar, because it doesn't know not to show that yet.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!