Re: crash in xdisp.c: show_mouse_face
> On Fri, 7 Apr 2006 16:54:34 -0400, Phil <[EMAIL PROTECTED]> said: > On Apr 3, 2006, at 2:42 AM, YAMAMOTO Mitsuharu wrote: >> >> Phil, do you possibly set the variable `mouse-highlight' to some >> integer? > I've confirmed that nothing I am doing uses mouse-highlight. Then the previous patch would not change anything. Is it possible for you to see if the issue is also observed with Carbon Emacs created from Emacs CVS? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: no-byte-compile no longer considered safe?
Should no-byte-compile be marked as a safe variable, It already is, since a month ago. But the problem could still be related to that. Does Emacs currently ask any questions when you visit any of these files? ___ 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
> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes: > 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? The call to `die' is made from the XWINDOW macro (because it's built with ENABLE_CHECKING). The problem is really at line 429x: 4290 if (horiz_flag 4291 ? !NILP (XWINDOW (parent)->hchild) 4292 : !NILP (XWINDOW (parent)->vchild)) The problem is apparently that `parent' is nil, i.e. it's not a WINDOWP. A quick fix is to add a WINDOWP check, but since NILP(parent) is checked a bit further up (tho only if some other condition holds as well), I suspect the problem might be linked to this earlier NILP check. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Wrong type argument: arrayp, nil with LANG=C under Windows
> From: Ralf Angeli <[EMAIL PROTECTED]> > Date: Sun, 09 Apr 2006 13:32:35 +0200 > > Trying to start Emacs from an MSYS shell with the command line > > LANG=C :/path/to/emacs -Q > > results in > > Wrong type argument: arrayp, nil Thanks, I think I fixed this; please try again. However, the behavior of Emacs on non-Posix platforms under LANG=C raises a subtle issue. Right now, when LANG=C (or Posix), set-locale-environment sets up things so that the default buffer-file-coding-system is reset to nil, and that causes Emacs to create files with Unix-style EOL conversion. This happens because the "C" language is mapped to "ASCII", which specifies no encoding. Thus, set-language-environment resets the default coding systems to nil, and leaves it at that. Then the code which takes care of copying the EOL conversion from previous defaults doesn't do its thing. The question is, is this a bug or a feature? That is, is it right for Emacs on MS-Windows to create Unix-style text files under LANG=C? I tend to think it's a bug, but I'm not sure. (For that matter, what does it mean for buffer-file-coding-system to be nil?) Any thoughts? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: crash in xdisp.c: show_mouse_face
Phil <[EMAIL PROTECTED]> writes: > On Apr 3, 2006, at 2:42 AM, YAMAMOTO Mitsuharu wrote: >> >> Phil, do you possibly set the variable `mouse-highlight' to some >> integer? > > I've confirmed that nothing I am doing uses mouse-highlight. Just to be sure ... what is printed by ESC : mouse-highlight RET -- 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
Re: Wrong type argument: arrayp, nil with LANG=C under Windows
* Eli Zaretskii (2006-04-10) writes: >> From: Ralf Angeli <[EMAIL PROTECTED]> >> Date: Sun, 09 Apr 2006 13:32:35 +0200 >> >> Trying to start Emacs from an MSYS shell with the command line >> >> LANG=C :/path/to/emacs -Q >> >> results in >> >> Wrong type argument: arrayp, nil > > Thanks, I think I fixed this; please try again. Thanks, I'll do this as soon as I will have access to a better connection again. (Or find out why cvs sends half of the repository to the server during an update.) > However, the behavior of Emacs on non-Posix platforms under LANG=C > raises a subtle issue. Right now, when LANG=C (or Posix), > set-locale-environment sets up things so that the default > buffer-file-coding-system is reset to nil, and that causes Emacs to > create files with Unix-style EOL conversion. This happens because the > "C" language is mapped to "ASCII", which specifies no encoding. Thus, > set-language-environment resets the default coding systems to nil, and > leaves it at that. Then the code which takes care of copying the EOL > conversion from previous defaults doesn't do its thing. > > The question is, is this a bug or a feature? That is, is it right for > Emacs on MS-Windows to create Unix-style text files under LANG=C? I > tend to think it's a bug, but I'm not sure. Isn't that an academic question? Are there people running Emacs intentionally under LANG=C and expecting Windows-style line endings? -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: no-byte-compile no longer considered safe?
Richard Stallman <[EMAIL PROTECTED]> writes: > Should no-byte-compile be marked as a safe variable, > > It already is, since a month ago. But the problem could > still be related to that. Does Emacs currently ask any questions > when you visit any of these files? Ah, now I see what happened and I found the bug. I was actually being asked for another variable in the same Local Variables stanza. If you add the following to a file, make recompile will compile it: ;; Local Variables: ;; no-byte-compile: t ;; url-unreserved-chars: nil ;; End -- 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
Strange redisplay problem in minibuffer.
Try this: ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Wrong type argument: arrayp, nil with LANG=C under Windows
> connection again. (Or find out why cvs sends half of the repository > to the server during an update.) Arch is much better in this respect, so you may want to prefer using Miles's Arch archive. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange redisplay problem in minibuffer.
> "Kim" == Kim F Storm <[EMAIL PROTECTED]> writes: > Try this: Huh? I tried it and it didn't do anything. Stefan ;-) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Strange display behavior after filling
I found some strange display behavior after filling. In the following, "row" means a displayed horizontal segment, and "line" means a sequence of characters delimited by newlines. 1. emacs -D -Q 2. M-q (I'm not sure why this is needed.) 3. Insert "123456789 " (without quotations or newlines) 18 times. Say, C-x ( 1 2 3 4 5 6 7 8 9 SPC C-x ) C-u 1 7 C-x e. It is displayed in three rows. 4. M-< 5. C-u 1 C-v Now the first row becomes continued to both directions. 6. M-q Then the first row is displayed shorter than the second one, whereas they have the same number of characters. 7. C-p C-n C-n The line number in the mode line says the cursor is at the third line. But it is displayed at the second row that corresponds to the second line. YAMAMOTO Mitsuharu [EMAIL PROTECTED] In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars) of 2006-04-11 on church X server distributor `The XFree86 Project, Inc', version 11.0.4030 configured using `configure '--x-libraries=/usr/local/lib' 'CFLAGS=-g -O2 -mv8 -DSYNC_INPUT'' 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: ja locale-coding-system: japanese-iso-8bit default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t auto-compression-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: no-byte-compile no longer considered safe?
Ah, now I see what happened and I found the bug. I was actually being asked for another variable in the same Local Variables stanza. If you add the following to a file, make recompile will compile it: ;; Local Variables: ;; no-byte-compile: t ;; url-unreserved-chars: nil ;; End I think the byte compiler needs a way to ignore all local variables except those specific few it is interested in--and thus avoid ever asking for confirmation. Does anyone see a way in which that will fail to do the job? I think other commands will want more or less the same facility (but with a different list of significant variables). So the implementation should be at least a little bit general. Perhaps involving a variable that specifies the list of variables to pay attention to. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Wrong type argument: arrayp, nil with LANG=C under Windows
> From: Ralf Angeli <[EMAIL PROTECTED]> > Date: Mon, 10 Apr 2006 23:07:00 +0200 > > Thanks, I'll do this as soon as I will have access to a better > connection again. (Or find out why cvs sends half of the repository > to the server during an update.) Is it possible that the DST became in effect in your timezone since the last "cvs up"? If so, the problem is that, with some ports of the CVS client to Windows, the time stamps are different from what is recorded in CVS/Entries, and the server requests that the client send every single file upstream. But this should happen only once after the clock change, and again when DST is reset. (I got tired of the long delay, so I wrote a program that can shift time stamps of all files in a directory tree by N hours.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Wrong type argument: arrayp, nil with LANG=C under Windows
> From: Ralf Angeli <[EMAIL PROTECTED]> > Date: Mon, 10 Apr 2006 23:07:00 +0200 > > > However, the behavior of Emacs on non-Posix platforms under LANG=C > > raises a subtle issue. Right now, when LANG=C (or Posix), > > set-locale-environment sets up things so that the default > > buffer-file-coding-system is reset to nil, and that causes Emacs to > > create files with Unix-style EOL conversion. This happens because the > > "C" language is mapped to "ASCII", which specifies no encoding. Thus, > > set-language-environment resets the default coding systems to nil, and > > leaves it at that. Then the code which takes care of copying the EOL > > conversion from previous defaults doesn't do its thing. > > > > The question is, is this a bug or a feature? That is, is it right for > > Emacs on MS-Windows to create Unix-style text files under LANG=C? I > > tend to think it's a bug, but I'm not sure. > > Isn't that an academic question? Are there people running Emacs > intentionally under LANG=C and expecting Windows-style line endings? I don't think it's academic: you yourself found one example of running Emacs under LANG=C, albeit non-interactively. Suppose Emacs needed to create a file during that non-interactive session---is it okay for that file to be in Unix text format? I know that I'd be surprised to learn about such behavior. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
> Date: Tue, 11 Apr 2006 11:48:06 +0900 (JST) > From: YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> > > I found some strange display behavior after filling. In the > following, "row" means a displayed horizontal segment, and "line" > means a sequence of characters delimited by newlines. > > 1. emacs -D -Q > 2. M-q (I'm not sure why this is needed.) I don't know either, but it loads newcomment. > 3. Insert "123456789 " (without quotations or newlines) 18 times. > Say, C-x ( 1 2 3 4 5 6 7 8 9 SPC C-x ) C-u 1 7 C-x e. > It is displayed in three rows. > 4. M-< > 5. C-u 1 C-v > > Now the first row becomes continued to both directions. > > 6. M-q > > Then the first row is displayed shorter than the second one, whereas > they have the same number of characters. > > 7. C-p C-n C-n > > The line number in the mode line says the cursor is at the third line. > But it is displayed at the second row that corresponds to the second > line. The problem is with redisplay of the cursor: it is displayed in the wrong place. Try typing C-a and arrow keys, and eventually you will see a second cursor in the correct place. C-l fixes the messed up display. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: crash in xdisp.c: show_mouse_face
t On Apr 10, 2006, at 4:55 PM, Kim F. Storm wrote: Phil <[EMAIL PROTECTED]> writes: On Apr 3, 2006, at 2:42 AM, YAMAMOTO Mitsuharu wrote: Phil, do you possibly set the variable `mouse-highlight' to some integer? I've confirmed that nothing I am doing uses mouse-highlight. Just to be sure ... what is printed by ESC : mouse-highlight RET -- 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
Re: Wrong type argument: arrayp, nil with LANG=C under Windows
* Eli Zaretskii (2006-04-11) writes: >> From: Ralf Angeli <[EMAIL PROTECTED]> >> Date: Mon, 10 Apr 2006 23:07:00 +0200 >> >> Thanks, I'll do this as soon as I will have access to a better >> connection again. (Or find out why cvs sends half of the repository >> to the server during an update.) > > Is it possible that the DST became in effect in your timezone since > the last "cvs up"? Yes. > If so, the problem is that, with some ports of the > CVS client to Windows, the time stamps are different from what is > recorded in CVS/Entries, and the server requests that the client send > every single file upstream. But this should happen only once after > the clock change, and again when DST is reset. With the repository in question cvs has always been sending a lot of stuff to the server during cvs up. Maybe it became worse when updating after the DST change, I don't know. I'll check what happens now as soon as I'll find the time. At least cvs status tells me that some sample files I've looked at are up-to-date. Thanks for your suggestions. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Wrong type argument: arrayp, nil with LANG=C under Windows
* Eli Zaretskii (2006-04-11) writes: >> From: Ralf Angeli <[EMAIL PROTECTED]> >> Date: Mon, 10 Apr 2006 23:07:00 +0200 >> >> > The question is, is this a bug or a feature? That is, is it right for >> > Emacs on MS-Windows to create Unix-style text files under LANG=C? I >> > tend to think it's a bug, but I'm not sure. >> >> Isn't that an academic question? Are there people running Emacs >> intentionally under LANG=C and expecting Windows-style line endings? > > I don't think it's academic: you yourself found one example of running > Emacs under LANG=C, albeit non-interactively. Suppose Emacs needed to > create a file during that non-interactive session---is it okay for that > file to be in Unix text format? I know that I'd be surprised to learn > about such behavior. Taking the context of the particular example we have into account I wouldn't be surprised. All the AUCTeX files have Unix-style line endings. So I would not be surprised if a file created during the setup process had such line endings as well. In the end, LANG=C doesn't really have a meaning under Windows, does it? -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
