Re: Strange display behavior after filling
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 problem. I have committed a different, more generic fix for this, which also attempts to select a more reasonable window start rather than just recentering. Thanks. It works for the cases I've shown. Sorry, maybe I should have tested it more carefully. Sometimes it seems to recenter too much: 1. emacs -q The splash screen is shown. 2. C-p The message in *scratch* is not shown. 3. C-p Now we can see it. I'm sorry too. The problem is that I set centering_position = 0 which works fine when PT is on the top line, but fails miserably otherwise. I changed the code to just recenter which seems to DTRT. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Customizing cursor color
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 customized. which says, to me, that I'm not supposed to use customize to set the cursor color, contradicting what the manual is telling me. In GNU Emacs 22.0.50.1 (powerpc-apple-darwin8.6.0) of 2006-04-19 X server distributor `Apple Computers', version 10.4.6 configured using `configure '--without-x' '--prefix=/usr/local'' -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: setting cursor-type in init file doesn't set it in *scratch*
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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Customizing cursor color
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' symbol property of the symbol `cursor'. But a nil value for a symbol property is equivalent with no property. Thus `cursor' has _no_ face-defface-spec property, which tells Custom that it is not intended to be customized. This apparently causes still other bugs in addition to the one you reported. For variables, Custom avoids this problem by storing the standard value as a list with one element (the standard value). Thus, if the standard value is nil, Custom stores '(nil) in the standard-value property, thereby avoiding the bugs for faces. Apparently, Custom does not consider nil a valid value for a face. If you erase all attributes of a face and then save it through Custom, Custom will save it as '((t nil)). I do not know whether nil actually is supposed to be a valid value for a face, or whether one is supposed to always use '((t nil)) instead. The simplest solution would be to simply replace all nil's in faces.el with '((t nil)) which fixes the bug you reported and other ones. The patch below, which I could install if desired, implements this simple solution. If we really want to admit nil as a valid value, one could store face-defface-spec as a list of one element, in analogy with standard-value, but I believe that this would require quite some rewriting. Another solution would be to make Custom automatically store '((t nil)) in face-defface-spec, if nil was specified in the defface, but I am not sure that this could not yield unexpected problems. Patch: ===File ~/faces.el-diff-b=== *** faces.el06 Feb 2006 16:01:46 -0600 1.348 --- faces.el20 Apr 2006 12:00:05 -0500 *** *** 2143,2161 :group 'frames :group 'basic-faces) ! (defface scroll-bar '() Basic face for the scroll bar colors under X. :version 21.1 :group 'frames :group 'basic-faces) ! (defface border '() Basic face for the frame border under X. :version 21.1 :group 'frames :group 'basic-faces) ! (defface cursor '() Basic face for the cursor color under X. Note: Other faces cannot inherit from the cursor face. :version 21.1 --- 2143,2161 :group 'frames :group 'basic-faces) ! (defface scroll-bar '((t nil)) Basic face for the scroll bar colors under X. :version 21.1 :group 'frames :group 'basic-faces) ! (defface border '((t nil)) Basic face for the frame border under X. :version 21.1 :group 'frames :group 'basic-faces) ! (defface cursor '((t nil)) Basic face for the cursor color under X. Note: Other faces cannot inherit from the cursor face. :version 21.1 *** *** 2164,2170 (put 'cursor 'face-no-inherit t) ! (defface mouse '() Basic face for the mouse color under X. :version 21.1 :group 'mouse --- 2164,2170 (put 'cursor 'face-no-inherit t) ! (defface mouse '((t nil)) Basic face for the mouse color under X. :version 21.1 :group 'mouse ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
mark comment-{start,end}[-skip] as safe-local-variable
/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:41:47 -0700 1.92 --- newcomment.el 20 Apr 2006 11:37:05 -0700 *** *** 108,128 --- 108,132 ;;;###autoload (defvar comment-start nil *String to insert to start a new comment, or nil if no comment syntax.) + ;;;###autoload(put 'comment-start 'safe-local-variable 'string-or-null-p) ;;;###autoload (defvar comment-start-skip nil *Regexp to match the start of a comment plus everything up to its body. If there are any \\(...\\) pairs, the comment delimiter text is held to begin at the place matched by the close of the first pair.) + ;;;###autoload(put 'comment-start-skip 'safe-local-variable 'string-or-null-p) ;;;###autoload (defvar comment-end-skip nil Regexp to match the end of a comment plus everything up to its body.) + ;;;###autoload(put 'comment-end-skip 'safe-local-variable 'string-or-null-p) ;;;###autoload (defvar comment-end *String to insert to end a new comment. Should be an empty string if comments are terminated by end-of-line.) + ;;;###autoload(put 'comment-end 'safe-local-variable 'string-or-null-p) ;;;###autoload (defvar comment-indent-function 'comment-indent-default ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tool-bar-setup overwrites local tool-bar-map
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*? Nick, you bring up a good point. I have Emacs.toolBar: 0 in my .Xresources file to avoid the frame resizing that happens if you just customize tool-bar-mode to nil. If I set Emacs.toolBar: 1, then I don't see the problem. You can reproduce with emacs22 -Q --xrm Emacs.toolBar:0. Is this a corner-case we wish to fix? I think so. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
