Re: Wrong type argument: arrayp, nil with LANG=C under Windows
From: Kenichi Handa [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Date: Wed, 12 Apr 2006 14:53:04 +0900 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. I agree that it's a bug. So, given your explanation about the nil value of buffer-file-coding-system, do you agree that we need to change mule-cmds.el so that reset-language-environment sets the default buffer-file-coding-system to dos on MS-DOS and MS-Windows? Or are you saying that with your change in coding.c, the issue of creating new files is already taken care of, and no further changes are required? If buffer-file-coding-system is dos, and some other file is inserted with decoding, the buffer-file-coding-system is changed to XXX-dos where, XXX part is the text-encoding part of the coding-system used for that decoding. Do we want it to change to XXX-dos on Windows, or do we want the inserted file to determine EOL conversion as well? I tend to think that we want XXX-dos regardless of the inserted file. And, on writing, coding-system is nil, it is treated as raw-text-unix. I've just installed the attached change to make it system-dependent; i.e. on Windows, nil is treated as raw-text-dos. FYI, system_eol_type is set as this (in init_coding_once): #if defined (MSDOS) || defined (WINDOWSNT) system_eol_type = CODING_EOL_CRLF; #else system_eol_type = CODING_EOL_LF; #endif What do you think? I think this is the right change. Thanks. ___ 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: Kenichi Handa [EMAIL PROTECTED] CC: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED] Date: Wed, 12 Apr 2006 17:13:51 +0900 If buffer-file-coding-system is dos, and some other file is inserted with decoding, the buffer-file-coding-system is changed to XXX-dos where, XXX part is the text-encoding part of the coding-system used for that decoding. Do we want it to change to XXX-dos on Windows, What do you mean by it above? The value of buffer-file-coding-system. or do we want the inserted file to determine EOL conversion as well? Yes, because it's the behavior on Unix/GNU-Linux. I tend to think that we want XXX-dos regardless of the inserted file. With my change, even if the inserted file has no newline, and thus EOL part of the buffer-file-coding-system is still not decided, when a user input a newline in that buffer, it is encoded into CRLF. Isn't it not enough? But with LANG set to English (or any other language that specifies a preferred coding system in locale-language-names), inserting a file with Unix EOLs does not change the EOL conversion of the buffer. Why should this be different under LANG=C? In other words, I don't think the value of LANG has anything to say about the preferred EOL conversion. The default EOL conversion should stay according to the platform's conventions, no matter what LANG is set to. Currently, on Windows it stays -dos for any value of LANG except C, and I don't see anything special about the C locale that it should be different from any other locale as far as EOLs are concerned. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
setenv documentation in elisp manual outdated
The setenv command now takes two new optional arguments UNSET and SUBSTITUTE-ENV-VARS, which are not discussed in the elisp manual. Actually, I wanted to look into the elisp manual because from the doc string of setenv it was not clear to me what the difference was between a nil value of VALUE and a value of t for UNSET. When does one need the optional arg UNSET because nil for VALUE is not doing the job? Thanks, Roland ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tramp splits frame when opening Subversion-controlled remote file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 11, 2006, at 12:41 PM, Michael Albinus wrote: Ian Eure [EMAIL PROTECTED] writes: When I open a remote file which is in a Subversion working directory with tramp (via ssh), the frame is split into two windows. Only happens with SVN-controlled files; regular files, or files in CVS working directories do not split the frame, nor do local files in SVN work dirs. Yes, and? What do you see in those windows? Errors, or just the files/directories you expect? I see one of the other buffers I have open in Emacs. If I open a SVN file over tramp first thing, *Messages* is displayed in the lower window, and the file I opened is displayed in the upper. If I've been using Emacs for a while, I'll see one of the buffers that's visiting another file. Perhaps I should clarify that this isn't a temporary split, like when entering a commit message for VC. The frame contains one window before the file is opened, and after the file is opened, it has two. I expect Emacs to not open permanent windows like that unless I explicitly request it. Again, this behavior is specific to this case: - - SVN controlled file, via Tramp: Splits frame - - SVN controlled file, locally: Does not split frame - - CVS controlled file, via Tramp: Does not split frame - - CVS controlled file, locally: Does not split frame - - Regular file, via tramp: Does not split frame - - Regular file, locally: Does not split frame It's very irritating, since I must press C-x 1 every time I open a remote file in a SVN working directory. - -- Ian Eure Developer, eNotes.com LLC -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEPSadxuUdPD6j2IMRAvdKAKCfvGc4G9/8QXCox4OM0T35fYeA3QCeOuQ5 ppY+lwy2q9gjBSXrhXkiuAU= =xmnF -END PGP SIGNATURE- ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs crashes at search-backward
#3 0x08124ae7 in simple_search (n=180836955, pat=0x92294 Address 0x92294 out of bounds, len=598820, len_byte=1, trt=1, pos=-1, pos_byte=0, lim=139377756, lim_byte=139470164) at search.c:1487 That appears to be in the following line: buf_ch = STRING_CHAR_AND_LENGTH (BYTE_POS_ADDR (this_pos_byte), ZV_BYTE - this_pos_byte, buf_charlen); (Please check your sources and verify that.) Can you please examine these data and see what is invalid? Also, what does BYTE_POS_ADDR (this_pos_byte)? (If you need to expand macros by hand, please do it!) What is really the value of n? What is really the value of lim? The values shown in the stack frame arg list seem nonsensical, so I suspect they are not the real values. Can you look at frame 4 and evaluate the args that will have been passed to simple_search for N and LIM? ___ 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 (2006-04-10) 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 just updated the sources, did make maintainer-clean ./configure --with-gtk make bootstrap and I am still getting the error. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tramp splits frame when opening Subversion-controlled remote file
Ian Eure [EMAIL PROTECTED] writes: Yes, and? What do you see in those windows? Errors, or just the files/directories you expect? I see one of the other buffers I have open in Emacs. If I open a SVN file over tramp first thing, *Messages* is displayed in the lower window, and the file I opened is displayed in the upper. If I've been using Emacs for a while, I'll see one of the buffers that's visiting another file. Tramp splits the frame and shows the *Messages* buffer only in case there is an error it wants to point to. What are the most relevant messages in the *Messages* buffer? Furthermore, if you enable Tramp traces, are there messages worth to report? Ian Eure Best regards, Michael. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tramp splits frame when opening Subversion-controlled remote file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 12, 2006, at 1:16 PM, Michael Albinus wrote: Ian Eure [EMAIL PROTECTED] writes: Yes, and? What do you see in those windows? Errors, or just the files/directories you expect? I see one of the other buffers I have open in Emacs. If I open a SVN file over tramp first thing, *Messages* is displayed in the lower window, and the file I opened is displayed in the upper. If I've been using Emacs for a while, I'll see one of the buffers that's visiting another file. Tramp splits the frame and shows the *Messages* buffer only in case there is an error it wants to point to. What are the most relevant messages in the *Messages* buffer? No, the only message is: Wrote /tmp/tramp.88725x1 Again, it does not always show *Messages*. If I have a few buffers visiting files, one of them will be displayed instead. *Messages* only seems to be shown when I have no other buffers open, and open a SVN file with tramp. Furthermore, if you enable Tramp traces, are there messages worth to report? No, there are no errors, nor anything that looks unusual. Tramp works fine; I can open, edit, and save files without problems. It's just that whenever that file is in a SVN working directory, my frame is split into two windows. - -- Ian Eure Developer, eNotes.com LLC -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEPWJ1xuUdPD6j2IMRAt9gAJ9C5vxIpNeOEJ8j8a1qpEJszNXL4gCg2WJe WCRe1Mqm570O3zzoGyOi48Q= =khNY -END PGP SIGNATURE- ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tramp splits frame when opening Subversion-controlled remote file
Ian Eure [EMAIL PROTECTED] writes: Furthermore, if you enable Tramp traces, are there messages worth to report? No, there are no errors, nor anything that looks unusual. Tramp works fine; I can open, edit, and save files without problems. It's just that whenever that file is in a SVN working directory, my frame is split into two windows. Strange. Using my local subversion instance, I cannot reproduce the problem yet. Which svn access method are you using? And just for completeness: I assume you're using Tramp 2.0.52 from Emacs CVS? I'll continue to test, hoping to provoke the error. Best regards, Michael. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tramp splits frame when opening Subversion-controlled remote file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 12, 2006, at 1:57 PM, Michael Albinus wrote: Ian Eure [EMAIL PROTECTED] writes: Furthermore, if you enable Tramp traces, are there messages worth to report? No, there are no errors, nor anything that looks unusual. Tramp works fine; I can open, edit, and save files without problems. It's just that whenever that file is in a SVN working directory, my frame is split into two windows. Strange. Using my local subversion instance, I cannot reproduce the problem yet. Which svn access method are you using? And just for completeness: I assume you're using Tramp 2.0.52 from Emacs CVS? I'm using svn+ssh, but it was happening with https as well (we just switched our SVN server over), i.e. it doesn't seem to matter what the SVN access method is. I'm using Tramp with ssh. I don't know the specific Tramp version, but yes, it occurred in a GNU Emacs nightly build. I used this one: http:// homepages.inf.ed.ac.uk/dreitter/Aquamacs/GNU-Emacs-nightly.dmg.bz2 - The Aquamacs people pointed me there after I reported the bug to them. - -- Ian Eure Developer, eNotes.com LLC -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEPWwexuUdPD6j2IMRAj0LAKDb1zRHS8Z8M/6DthmINnaxIuhnggCg7oU2 zwE4iozZewBlIdI1K4i9aHU= =7XbV -END PGP SIGNATURE- ___ 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: I guess a simper way to do it is to provide a var that says set all the safe vars and ignore the others. I hope I never simper, but I implemented your suggestion. Thanks, it appears to have fixed the problem. The files that shouldn't be byte-compiled are no longer byte-compiled. -- 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: balance-windows causes core dump
Does this fix it?
*** window.c21 Mar 2006 17:05:43 -0500 1.540
--- window.c12 Apr 2006 23:15:34 -0400
***
*** 4255,4272
while (1)
{
p = XWINDOW (window);
parent = p-parent;
! /* Make sure there is a following window. */
! if (NILP (parent)
! (horiz_flag ? 1
! : NILP (XWINDOW (window)-next)))
{
Fset_window_configuration (old_config);
error (No other window following this one);
}
/* Don't make this window too small. */
if (XINT (CURSIZE (window)) + delta
(horiz_flag ? window_min_width : window_min_height))
--- 4255,4284
while (1)
{
+ Lisp_Object first_parallel = Qnil;
+
p = XWINDOW (window);
parent = p-parent;
! if (NILP (XWINDOW (window)-next))
{
Fset_window_configuration (old_config);
error (No other window following this one);
}
+ /* See if this level has windows in parallel in the specified
+direction. If so, set FIRST_PARALLEL to the first one. */
+ if (horiz_flag)
+ {
+ if (! NILP (parent) !NILP (XWINDOW (parent)-vchild))
+ first_parallel = XWINDOW (parent)-vchild;
+ }
+ else
+ {
+ if (! NILP (parent) !NILP (XWINDOW (parent)-hchild))
+ first_parallel = XWINDOW (parent)-hchild;
+ }
+
/* Don't make this window too small. */
if (XINT (CURSIZE (window)) + delta
(horiz_flag ? window_min_width : window_min_height))
***
*** 4284,4295
XINT (CURSIZE (window)) + delta);
/* If this window has following siblings in the desired dimension,
!make them smaller.
(If we reach the top of the tree and can never do this,
we will fail and report an error, above.) */
! if (horiz_flag
! ? !NILP (XWINDOW (parent)-hchild)
! : !NILP (XWINDOW (parent)-vchild))
{
if (!NILP (XWINDOW (window)-next))
{
--- 4296,4306
XINT (CURSIZE (window)) + delta);
/* If this window has following siblings in the desired dimension,
!make them smaller, and exit the loop.
!
(If we reach the top of the tree and can never do this,
we will fail and report an error, above.) */
! if (NILP (first_parallel))
{
if (!NILP (XWINDOW (window)-next))
{
***
*** 4311,4319
else
/* Here we have a chain of parallel siblings, in the other dimension.
Change the size of the other siblings. */
! for (child = (horiz_flag
! ? XWINDOW (parent)-vchild
! : XWINDOW (parent)-hchild);
! NILP (child);
child = XWINDOW (child)-next)
if (! EQ (child, window))
--- 4322,4328
else
/* Here we have a chain of parallel siblings, in the other dimension.
Change the size of the other siblings. */
! for (child = first_parallel;
! NILP (child);
child = XWINDOW (child)-next)
if (! EQ (child, window))
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tramp splits frame when opening Subversion-controlled remote file
I wrote: Strange. Using my local subversion instance, I cannot reproduce the problem yet. Which svn access method are you using? And just for completeness: I assume you're using Tramp 2.0.52 from Emacs CVS? I'll continue to test, hoping to provoke the error. OK, it's reproduceable now locally. Tramp's implementation of `process-file' calls `shell-command', which displays always the output buffer, even if `process-file' is called with DISPLAY equal nil. I'll provide a fix later. Best regards, Michael. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
