Jay Berkenbilt <[EMAIL PROTECTED]> writes: > Well, the problem doesn't happen for me with a vanilla setup, so it > must be something in my environment.
That's a valuable piece of information. > This is, by the way, why I used to always run pretest versions -- > before I started doing that, there was never an emacs release in which > all my customizations worked together, and my init files used to be > littered with version-specific workarounds. Heh. Thanks again for using emacs-snapshot, your bug reports are very useful! > Being able to run regularly updated snapshots on this one machine (my > main home development system) is great because it means I will always > have a stable emacs everywhere else, and with your rapid responses, > things never stay broken for very long. :-) Sorry for the occasional breakage -- I do my best to make emacs-snapshot as stable as any Emacs release but even though I read emacs-diffs daily, read the debdiff of each snapshot, and test each version thoroughly (with my setup), some changes still slip under my radar (like the hi-lock bug last week, or this filling issue). Back to this bug: I grepped through your configuration, and it could be caused by any (or both) of the following customizations: - next-line-add-newlines set to t (it's nil here) - this substitution in q-message.el: (substitute-key-definition 'next-line 'mail-abbrev-next-line message-mode-map global-map ) Let me know if I hit the mark. -- ,''`. : :' : Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
