Re: tool-bar-setup overwrites local tool-bar-map

2006-04-20 Thread Bill Wohler
Nick Roberts <[EMAIL PROTECTED]> wrote: > > > emacs22 -Q > > > M-x info > > > M-x tool-bar-mode > > > > > > Note how Preferences and Help icons are present. > > This doesn't make sense to me. If you start with -Q then doesn't > tool-bar-mode tool-bar-mode turn the tool bar *off*? Nic

Re: tool-bar-setup overwrites local tool-bar-map

2006-04-20 Thread Nick Roberts
> > emacs22 -Q > > M-x info > > M-x tool-bar-mode > > > > Note how Preferences and Help icons are present. This doesn't make sense to me. If you start with -Q then doesn't tool-bar-mode tool-bar-mode turn the tool bar *off*? I can't see a difference between the two recipes even witho

Re: tool-bar-setup overwrites local tool-bar-map

2006-04-20 Thread Bill Wohler
Bill Wohler <[EMAIL PROTECTED]> wrote: > emacs22 -Q > M-x info > M-x tool-bar-mode > > Note how Preferences and Help icons are present. > > C-x b *scratch* RET > > Note how Preferences and Help icons are absent. > > To see what should have happened: > > emacs22 -Q > M-x tool-bar-m

tool-bar-setup overwrites local tool-bar-map

2006-04-20 Thread Bill Wohler
emacs22 -Q M-x info M-x tool-bar-mode Note how Preferences and Help icons are present. C-x b *scratch* RET Note how Preferences and Help icons are absent. To see what should have happened: emacs22 -Q M-x tool-bar-mode Note how Preferences and Help icons are present. M-x info N

Re: mark comment-{start,end}[-skip] as safe-local-variable

2006-04-20 Thread Stefan Monnier
> /etc/termcap on my Fedora Core 5 system uses comment-start and > comment-start-skip, so given that they are actively used as local > variables, they should be marked as safe. > By analogy *-end variables should be also be marked as safe. > Should I check this in? Yes, please. Stefan

mark comment-{start,end}[-skip] as safe-local-variable

2006-04-20 Thread Dan Nicolaescu
/etc/termcap on my Fedora Core 5 system uses comment-start and comment-start-skip, so given that they are actively used as local variables, they should be marked as safe. By analogy *-end variables should be also be marked as safe. Should I check this in? *** newcomment.el 17 Apr 2006 09

Re: Customizing cursor color

2006-04-20 Thread Luc Teirlinck
Otto Maddox wrote: so I go to the "cursor" customize group. Next to the State button for Cursor face is this: NO CUSTOMIZATION DATA; not intended to be customized. That is because the defface sets the cursor face to '(), that is, nil. Custom stores that value in the `face-defface-spec'

Re: setting cursor-type in init file doesn't set it in *scratch*

2006-04-20 Thread David Reitter
On 20 Apr 2006, at 15:26, Kim F. Storm wrote: David Reitter <[EMAIL PROTECTED]> writes: Shouldnt setting the cursor-type with a (setq cursor-type '(bar .1)) Try: (setq cursor-type '(bar . 1)) That was not the problem. - just a missing space in my message. __

Re: setting cursor-type in init file doesn't set it in *scratch*

2006-04-20 Thread Kim F. Storm
David Reitter <[EMAIL PROTECTED]> writes: > Shouldnt setting the cursor-type with a (setq cursor-type '(bar .1)) Try: (setq cursor-type '(bar . 1)) -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pret

setting cursor-type in init file doesn't set it in *scratch*

2006-04-20 Thread David Reitter
Shouldnt setting the cursor-type with a (setq cursor-type '(bar .1)) set the cursor-type for *scratch*, because that is the selected buffer at the time? Instead, when I have the above statement in .emacs or a site-init file, `cursor-type' is magically set back to t or whatever is the def

Customizing cursor color

2006-04-20 Thread Otto Maddox
The node "Cursor Display" in the emacs info pages says this: You can customize the cursor's color, and whether it blinks, using the `cursor' Custom group so I go to the "cursor" customize group. Next to the State button for Cursor face is this: NO CUSTOMIZATION DATA; not intended to be customiz

Re: Strange display behavior after filling

2006-04-20 Thread Kim F. Storm
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: >> On Thu, 20 Apr 2006 09:36:07 +0900, YAMAMOTO Mitsuharu <[EMAIL >> PROTECTED]> said: > >> On Thu, 20 Apr 2006 01:21:04 +0200, [EMAIL PROTECTED] (Kim F. Storm) >> said: >>> Ok, so my first patch only fixed one instance of this probl