Re: Big desktop undo buffer crashes Emacs
Richard Stallman [EMAIL PROTECTED] wrote: Every morning for the past weeks, I've had a message in my minibuffer that roughly goes, Desktop undo buffer is 3+ MB, discard? (yes or no). I've been saying yes. This morning, feeling snarky, I said no and Emacs crashed. Could you please provide the precise text of the message? The message includes a buffer name; what is the buffer name? I haven't seen the prompt in a couple of days. Could a recent update have suppressed it? -- 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
crash under X using compose-region with null string
$ emacs -Q Insert (compose-region 1 2 ) in the *scratch* buffer and evaluate it. Emacs crashes during redisplay: Program received signal SIGSEGV, Segmentation fault. set_glyph_string_background_width (s=0x0, start=1, last_x=892) at xdisp.c:19150 19150 if (start == s-row-used[s-area] (gdb) In GNU Emacs 22.0.50.33 (x86_64-unknown-linux-gnu, X toolkit) of 2006-05-01 on muon X server distributor `The X.Org Foundation', version 11.0.7000 Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding system of compressed PO files is not recognized
I have a new idea. We could establish the convention that you can pass a buffer to find-operation-coding-system instead of a file name, for the `insert-file-contents' operation. And elements of Vfile_coding_system_alist could have symbols instead of regexps; the symbol would match the buffer's major mode. Vfile_coding_system_alist elements that have regexps would get the buffer-file-name from the buffer, and match against it. Or perhaps in this case they should never match. I am not sure which choice is better. I think that provides 100% clean way to fix it. Can you try implementing this method? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding system of compressed PO files is not recognized
In article [EMAIL PROTECTED], Richard Stallman [EMAIL PROTECTED] writes: I have a new idea. We could establish the convention that you can pass a buffer to find-operation-coding-system instead of a file name, for the `insert-file-contents' operation. And elements of Vfile_coding_system_alist could have symbols instead of regexps; the symbol would match the buffer's major mode. I don't understand how that solve the problem. When find-operation-coding-system is called, even if a buffer is given, the major mode of the buffer is not yet decided. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug