Re: shouldn't Fsignal be marked NORETURN?
Stefan Monnier [EMAIL PROTECTED] writes: Any reason not to? The `quit' signal can be continued. OK, thanks. Then report_file_error can be marked as NORETURN, right? Yes, Thanks How about wrong_type_argument ? It looks like there's some dead code in there, but it has not been touched in ages. Also it seems that the while (1) can be deleted from args_out_of_range and args_out_of_range_3. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: void-variable c-subword-mode with debug-on-error
Cc: emacs-pretest-bug@gnu.org From: Ralf Angeli [EMAIL PROTECTED] Date: Sun, 09 Apr 2006 10:08:44 +0200 Unrelated, but annoying: With the new build on Windows AUCTeX cannot be configured. I got the following error in config.log: configure:1539: checking if c:/Programme/Emacs/bin/emacs is XEmacs c:/Programme/Emacs/bin/emacs -batch -no-site-file -eval (let* ((x (if (featurep (quote xemacs)) yes no))) (write-region (if (stringp x) x (prin1-to-string x)) nil ./conftest-140)) Wrong type argument: arrayp, nil = configure:1557: error: Unable to run c:/Programme/Emacs/bin/emacs! Aborting! Trying the above (properly quoted) in an MSYS shell succeeds. So I am a bit stumped. If anybody has an idea what the cause could be, I am all ears. (The carriage return after nil looks suspicious.) One idea is to modify the command so that Emacs displays the value of the variable command-line-args. (I suspect that the MSYS shell, which is known to munge command lines with file names, does something bad to the ./conftest-140 part.) The build from beginning of March did not have this problem. Did something perhaps change in the AUC TeX configury since March? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: shouldn't Fsignal be marked NORETURN?
How about wrong_type_argument ? It looks like there's some dead code in there, but it has not been touched in ages. Why not leave it alone, for now? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: void-variable c-subword-mode with debug-on-error
Richard Stallman writes: emacs -Q -f toggle-debug-on-error test.c the following error occurs: Debugger entered--Lisp error: (void-variable c-subword-mode) It did not happen for me on GNU/Linux. (I fetched the sources today and rebuilt.) I've had this problem before because I hadn't built Emacs correctly. I think it has something to do with cc-modes many macros and the order in which they're byte compiled. `make bootstrap' probably solves it but I just deleted the byte compiled files associated with cc-mode (cc-*.elc) and did `make recompile' in emacs/lisp followed by `make' in emacs/src, and that seemed to solve it. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
no-byte-compile no longer considered safe?
An MH-E user has reported that a few of the MH-E files which MUST NOT be compiled were compiled after a recent CVS Emacs update. I've noticed this behavior too after I updated. Unfortunately, the compilation of these files causes mysterious bugs in MH-E (which is why we set no-byte-compile to t in the local variables stanza). When I fired up Emacs recently, I noticed that I was prompted for several of my local variables. I imagine that the safe variable code that has been discussed here was implemented. Related? Should no-byte-compile be marked as a safe variable, or is there something the MH-E package should be doing differently now? -- 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
Re: Fcitx and Emacs fights over C-Space key compostion.
In article [EMAIL PROTECTED], Yiyi Hu [EMAIL PROTECTED] writes: [1 text/plain; UTF-8 (base64)] Since I prefer use fcitx to the im built-in within Emacs, But the problem now is, if you are in X, you can no longer activate fcitx within emacs. When I run Emacs as this: % LANG=zh_CN fcitx % LANG=zh_CN emacs I can activate fcitx with C-SPC and type Chinese. And as set-mark-command is normally bind both to C-SPC and C-@, I can use it by C-@ (instead of C-SPC). The problem is that I see no indicator showing whether fcitx is activated or not. Another annoying problem is that while activating fcitx, I can't use C-k, C-l, etc because they are all eaten by fcitx. But, it seems that all key-binding for fcitx can be cutomized by ~/.fcitx/config. For instance, if you don't need to use Emacs' builtin IM, you can use C-\ for activating/de-activating fcitx by changing this line: 打开/关闭输入法=CTRL_SPACE to 打开/关闭输入法=CTRL_\ C-k etc eaten by fcitx can also be customized. Please read the document of fcitx and your ~/.fcitx/config for more detail. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: balance-windows causes core dump
On my GNU/Linux system here, I can crash Emacs as follows: emacs -Q C-x 2 M-x balance-windows RET Nobody seems to have investigated this, so I tried it (please forgive the delay), but it did not fail for me. Does it still fail for you? There has been no change in window.c since you sent that report, but line window.c:4290 does not contain anything that might call alloc.c: Meanwhile, it looks like you have compiled with some sort of inlining. #0 0xb7c1dbf1 in kill () from /lib/tls/libc.so.6 #1 0x081306bc in abort () at emacs.c:464 #2 0x0819ce06 in die (msg=0x0, file=0x0, line=0) at alloc.c:6199 #3 0x080beed3 in Fadjust_window_trailing_edge (window=138362889, delta=-8, horizontal=138362889) at window.c:4290 Could you please try with that turned off? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
