image.el doesn't associate image-mode with .JPG files
Lots of digital cameras create '.JPG' files (note: capital letters). Opening these files with Emacs opens them in fundamental mode, not image mode, since Emacs only associates image-mode with .jpg and .jpeg files. Adding this line to the default value of image-type-file-name-regexps in lisp/image.el would help: (\\.JPE?G\\' . jpeg) In GNU Emacs 22.0.91.28 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2006-12-11 on chrislap X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local/emacs22' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Fix for C++ class label preventing fontification
The below patch fixes a previous change I made (to fix switch label fontification) that causes missing fontification of a member name declared directly following a label in a C++ class declaration. 2006-12-12 Simon Marshall [EMAIL PROTECTED] * progmodes/cc-fonts.el (c-font-lock-declarations): Fix previous change. === RCS file: /sources/emacs/emacs/lisp/progmodes/cc-fonts.el,v retrieving revision 1.18 diff -c -r1.18 cc-fonts.el *** cc-fonts.el 15 Nov 2006 16:31:03 - 1.18 --- cc-fonts.el 12 Dec 2006 10:55:10 - *** *** 1179,1185 ;; The below code attempts to fontify the case constants in ;; c-label-face-name, but it cannot catch every case [sic]. ;; And do we want to fontify case constants anyway? ! nil ;;; (when (c-forward-label t match-pos nil) ;;; ;; Can't use `c-fontify-types-and-refs' here since we ;;; ;; should use the label face. --- 1179,1185 ;; The below code attempts to fontify the case constants in ;; c-label-face-name, but it cannot catch every case [sic]. ;; And do we want to fontify case constants anyway? ! (c-forward-label t match-pos nil) ;;; (when (c-forward-label t match-pos nil) ;;; ;; Can't use `c-fontify-types-and-refs' here since we ;;; ;; should use the label face. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacsclient/server filename quoting error
On 12/10/06, Francis Wright [EMAIL PROTECTED] wrote: I execute all the following commands from a cmd command prompt (outside of Emacs). emacsclient -n -a runemacs TO DO.txt works correctly if Emacs IS already running, but if it is not already running then Emacs does not see the filename correctly; the quotes do not appear to be passed on to runemacs. Yeah. With an instrumented emacsclient: C:\emacs emacsclient -a c:\emacs\bin\runemacs.exe TO DO.txt 2: [c:\emacs\bin\runemacs.exe] 3: [TO DO.txt] So it would be necessary to re-quote args containing whitespaces before calling execvp(). Question is: is that the right behavior in non-Windows environments? (Quoting filenames with embedded spaces, I mean). /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
On 12/12/06, Chris Moore [EMAIL PROTECTED] wrote: Opening these files with Emacs opens them in fundamental mode, not image mode, since Emacs only associates image-mode with .jpg and .jpeg files. `image-type-from-file-name' uses `string-match', which depends on the setting of `case-fold-search'. Adding this line to the default value of image-type-file-name-regexps in lisp/image.el would help: (\\.JPE?G\\' . jpeg) Perhaps the following patch would be more correct. After all, I don't think it will be common to have files with extensions .PNG, .TIFF, .BMP, etc. which are not images. /L/e/k/t/u Index: lisp/image.el === RCS file: /cvsroot/emacs/emacs/lisp/image.el,v retrieving revision 1.63 diff -u -2 -r1.63 image.el --- lisp/image.el 21 Apr 2006 20:56:06 - 1.63 +++ lisp/image.el 12 Dec 2006 10:59:47 - @@ -271,4 +271,5 @@ be determined. (let ((types image-type-file-name-regexps) + (case-fold-search t) type) (while types ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
Juanma Barranquero [EMAIL PROTECTED] writes: Adding this line to the default value of image-type-file-name-regexps in lisp/image.el would help: (\\.JPE?G\\' . jpeg) Perhaps the following patch would be more correct. After all, I don't think it will be common to have files with extensions .PNG, .TIFF, .BMP, etc. which are not images. ... --- lisp/image.el 21 Apr 2006 20:56:06 - 1.63 +++ lisp/image.el 12 Dec 2006 10:59:47 - @@ -271,4 +271,5 @@ (let ((types image-type-file-name-regexps) + (case-fold-search t) Thought that's probably a reasoanble change, but it doesn't suffice in this case -- image-type-from-file-name is not called except when specifically dealing with an image, and Emacs never gets that far unless auto-mode-alist tells it to... -Miles -- `The suburb is an obsolete and contradictory form of human settlement' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
On 12/12/06, Miles Bader [EMAIL PROTECTED] wrote: Thought that's probably a reasoanble change, but it doesn't suffice in this case -- image-type-from-file-name is not called except when specifically dealing with an image, and Emacs never gets that far unless auto-mode-alist tells it to... Ah. I wasn't aware, because on Windows machines, emacs TEST.JPEG opens it in image mode. If .JPG/.JPEG is frequent, perhaps we should add it to `auto-mode-alist', then. Or do this: (push '(^\xFF\xD8\xFF\xE0\x00\x10JFIF . image-mode) magic-mode-alist) /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
If the argument i is of type int (32bit), then the compiler is sufficiently clever to infer that the comparisons will always return the same value (even though we cast that value to EMACS_INT (64bit) in between). Is it really that smart? Apparently, yes. But also enough stupid that it makes that comparison when it is useless (as I tried to have it understand using sizeof()). Will it also be that smart if we do some arithmetics, like `(EMACS_INT)i + 0L' or `(EMACS_INT)i*1L'? Will try that and see if it is useful to make the warning go away. If FIXNUM_OVERFLOW_P should always return zero on 64-bit machines, It shouldn't. There are a few sites where it does, tho. Are these few cases those for which the argument of FIXNUM_OVERFLOW_P is an int (rather than a long)? No, it will always return 0 if (sizeof(i) sizeof(EMACS_INT)), but it may not return 0 if (i) has the same or greater size than EMACS_INT. On amd64, this happens when (i) is long. There is no problem other than unhelpful warnings. Well, that's exactly the problem :-) Having spurious warnings should be avoided, if at all possible. We can probably remove those warnings with the right -Wno-foo invocation. No, that would mask out other possible cases when the warning is significant. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
Juanma Barranquero [EMAIL PROTECTED] writes: If .JPG/.JPEG is frequent, perhaps we should add it to `auto-mode-alist', then. Or do this: I don't know exactly how frequent it is, but every Canon digital camera I've seen uses the .JPG extension when saving in jpeg format. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
Will it also be that smart if we do some arithmetics, like `(EMACS_INT)i + 0L' or `(EMACS_INT)i*1L'? Will try that and see if it is useful to make the warning go away. No, it changes nothing: the compiler is too clever, but not enough :-) But, rereading it: #define FIXNUM_OVERFLOW_P(i) \ ((EMACS_INT)(i) MOST_POSITIVE_FIXNUM \ || (EMACS_INT)(i) MOST_NEGATIVE_FIXNUM) What is the purpose of casting (i) to EMACS_INT? The cast is redundant, unless (sizeof(i) sizeof(EMACS_INT)). Or unless (i) is floating point. In both cases, the cast should not be there, I suppose. In my case, removing the casts apparently changes nothing, and the warnings are always there. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't display Japanese text in menu bar
Thanks Handa-san for following up. In [EMAIL PROTECTED] Handa-san wrote: (let ((japanese (decode-coding-string \e$B%F%9%H\e(B 'iso-2022-jp))) (easy-menu-define testing-menu global-map Testing. `(Testing [,japanese (lambda nil (interactive) (message ,japanese)) t])) (easy-menu-add testing-menu global-map)) It works for me (my Emacs also uses LUCID) both in ja_JP.EUC-JP and en_US.UTF-8. In which locale did you test it? The locale command returns the following in the PCs, running Fedora Core 6 Linux, both in the office and home. LANG=ja_JP.eucjp LC_CTYPE=ja_JP.eucjp LC_NUMERIC=C LC_TIME=C LC_COLLATE=C LC_MONETARY=C LC_MESSAGES=C LC_PAPER=C LC_NAME=C LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=C LC_IDENTIFICATION=C LC_ALL= Those are set globally in the systems and I don't modify any of them in Emacs. I verified it doesn't work in both the PCs. I found the way to make it work. That is to re-set the font for the `menu' face as follows: (set-face-font 'menu (face-font 'menu)) But I don't think this is the right way. WDYT? I have no idea why it makes any change. I'll look into it further... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
We can probably remove those warnings with the right -Wno-foo invocation. No, that would mask out other possible cases when the warning is significant. But since this warning is about something which is not itself a bug, either gcc provides a way to annotate the code to indicate that this is not a bug (like the use of double-parens to turn off the warning about assignment in an `if'), or there's not much we can do about it (other than try to work around it by making the code ugly, less robust, and maybe even less efficient: after all the warning here is output specifically when gcc finds an optimization). Turning off such warnings is not such a big deal. There are thousand more such warnings that are currently turned off for the reason that either they're too difficult to figure out or nobody has thought of writing them yet. The warning just says hey, I've found a piece of code that's silly, but in the case where that piece of code is the result of macro-expansion (or function inlining, or other such code manipulation), it is often very much normal and the result of good coding practices. So I believe the problem is with the warning which is not careful enough to see how that code came about. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
dired-sort-toggle-or-edit not mouse accessible
They tied my hands behind my back and locked the keyboard. All I could do was operate the mouse (OK, ThinkCl*t) with my nose. Only then I discovered s runs the command dired-sort-toggle-or-edit which is an interactive compiled Lisp function in `dired.el'. It is bound to s. doesn't have a mouse binding. Indeed, even clicking on (Dired by name) temptingly in the mode line won't get you far. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
adieu *scratch*
Nope, it's time the *scratch* buffer should go for experienced user me. Just gets in the way in switch-to-buffer *s: Possible completions are: *scratch* *shell* That was the last straw, you might say. Anyway, I'm no old fogey who needs a buffer to type lisp into all day or something. The above humor is intended to keep me plopular. Hey Mom, I moved this line to the 81st column, where HE'll surely never see it :-) (kill-buffer *scratch*);in .emacs OK, that wasn't too hard. Anyway, there are plenty of variables regarding the *scratch* buffer but none to not create it in the first place. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
But since this warning is about something which is not itself a bug, either gcc provides a way to annotate the code to indicate that this is not a bug (like the use of double-parens to turn off the warning about assignment in an `if'), or there's not much we can do about it (other than try to work around it by making the code ugly, less robust, and maybe even less efficient: after all the warning here is output specifically when gcc finds an optimization). First I tried to work around it by making the code slightly more complex, but still clear. However, I failed. I looked at the gcc 4.1 info page, and I found no warnings to turn off that are specific for this case (I looked for the string compar). As far as code annotations are concerned, I don't know where to look: I had never heard of the double parenthesis trick, nor was I able to find it in the gcc info page. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
But since this warning is about something which is not itself a bug, either gcc provides a way to annotate the code to indicate that this is not a bug (like the use of double-parens to turn off the warning about assignment in an `if'), or there's not much we can do about it (other than try to work around it by making the code ugly, less robust, and maybe even less efficient: after all the warning here is output specifically when gcc finds an optimization). First I tried to work around it by making the code slightly more complex, but still clear. However, I failed. I looked at the gcc 4.1 info page, and I found no warnings to turn off that are specific for this case (I looked for the string compar). Yes, I believe there's no way. Which is why I think the least bad course is -Wno-foo. As far as code annotations are concerned, I don't know where to look: I had never heard of the double parenthesis trick, nor was I able to find it in the gcc info page. Can't remember where I saw it, but if you do if (foo = bar) ... gcc warns that you may have meant == instead of =, so if you really meant = you can just write if ((foo = bar)) ... and gcc will then keep quiet. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mysterious fontification/C++ context issue
Stefan Monnier [EMAIL PROTECTED] writes: The docstring doesn't mention anything about it. And really, when defun-prompt-regexp is nil, then beginning-of-defun considers that defun starts when there is a char with open-parenthesis syntax at the beginning of a line. So if open-paren-in-column-0-is-defun-start is nil, it's hard to figure out what should be considered as a defun start. It's kind of like saying I won't tell you what it is, I'll just tell you that it's not what you think. We could explicitly document that this situation (defun-prompt-regexp and o-p-i-c-0-i-d-s both nil) means figure it out using syntactically, i.e. using ppss as Alan implemented. We have to bring this to a resolution; intricate changes can be postphone till after the release. I recommend the following: * Updating the relevant docstrings to say what defun-prompt-regexp and o-p-i-c-0-i-d-s both nil means. * Updating the Elisp manual, and mentioning that such a combination can be slow. * Checking in Martin's optimization to Alan's code. * Setting o-p-i-c-0-i-d-s to t for cc mode. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mysterious fontification/C++ context issue
The docstring doesn't mention anything about it. And really, when defun-prompt-regexp is nil, then beginning-of-defun considers that defun starts when there is a char with open-parenthesis syntax at the beginning of a line. So if open-paren-in-column-0-is-defun-start is nil, it's hard to figure out what should be considered as a defun start. It's kind of like saying I won't tell you what it is, I'll just tell you that it's not what you think. We could explicitly document that this situation (defun-prompt-regexp and o-p-i-c-0-i-d-s both nil) means figure it out using syntactically, i.e. using ppss as Alan implemented. We could, but I'm very much not in favor since it makes o-p-i-c-0-i-d-s more important than it deserves and it's very unclear that this behavior is of any use to beginning-of-defun. It seems to only be useful in the case where you actually wanted to use syntax-ppss and syntax-ppss-toplevel-pos instead. * Updating the relevant docstrings to say what defun-prompt-regexp and o-p-i-c-0-i-d-s both nil means. I think the current docstring is quite clear. * Updating the Elisp manual, and mentioning that such a combination can be slow. * Checking in Martin's optimization to Alan's code. * Setting o-p-i-c-0-i-d-s to t for cc mode. * revert the change and live with the resulting occasional problems for now (problems which have existed for ever anyway). -- Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: -fs hides part of Emacs window behind task bar on w32
On 12/11/06, Lennart Borgman [EMAIL PROTECTED] wrote: When starting with emacs -Q -fs the lower part of Emacs may get hidden behind the MS Windows task bar. The following patch should fix that. /L/e/k/t/u Index: src/frame.c === RCS file: /cvsroot/emacs/emacs/src/frame.c,v retrieving revision 1.335 diff -u -2 -r1.335 frame.c --- src/frame.c 10 Nov 2006 07:54:22 - 1.335 +++ src/frame.c 12 Dec 2006 17:32:17 - @@ -2614,4 +2614,9 @@ int newwidth = FRAME_COLS (f); int newheight = FRAME_LINES (f); +#ifdef HAVE_NTGUI + RECT work_area; + + SystemParametersInfo (SPI_GETWORKAREA, 0, work_area, 0); +#endif *top_pos = f-top_pos; @@ -2623,4 +2628,7 @@ ph = FRAME_X_DISPLAY_INFO (f)-height; +#ifdef HAVE_NTGUI + ph = min (ph, work_area.bottom - work_area.top); +#endif newheight = FRAME_PIXEL_HEIGHT_TO_TEXT_LINES (f, ph); ph = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, newheight) - f-y_pixels_diff; @@ -2634,4 +2642,7 @@ pw = FRAME_X_DISPLAY_INFO (f)-width; +#ifdef HAVE_NTGUI + pw = min (pw, work_area.right - work_area.left); +#endif newwidth = FRAME_PIXEL_WIDTH_TO_TEXT_COLS (f, pw); pw = FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, newwidth) - f-x_pixels_diff; ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
I looked at the gcc 4.1 info page, and I found no warnings to turn off that are specific for this case (I looked for the string compar). Yes, I believe there's no way. Which is why I think the least bad course is -Wno-foo. ??? Oops, sorry, I misunderstood at first reading. We should ask the gcc people what thet recommend. if (foo = bar) ... gcc warns that you may have meant == instead of =, so if you really meant = you can just write if ((foo = bar)) ... Probably this is just because it is then clear that the logical expression is the result of the expression inside the parentheses. I mean, not in fact a special case for gcc. Probably, yes. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP password caching
From: Michael Albinus [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Mon, 04 Dec 2006 21:09:39 +0100 Under w32, it still might be desirable to go back to plink as default method. Here I would like to get a recommendation from w32 users. What is the issue here, and how does one see it in tramp.el? (I didn't follow this thread, sorry.) Recently, tramp-default-method has been changed to scp respective pscp methods. It has been reported, that people experience a lot of password requests from tramp, when they do not run ssh-agent, or when password.el is not available. For openssh like implementations, I've (tried to) fix(ed) it by adding ControlMaster/ControlPath arguments to the scp commands. AFAIK, these arguments are not available under w32, so it shall be checked whether pscp is still the preferrable default method. I checked this now: on Windows, pscp behaves like scp and plink behaves like ssh on Posix platforms. In other words, we should indeed change the default method on w32 to plink, because that is faster and asks for the passphrase fewer times. Of course, one would be on the safe side when PuTTY's pageant is running (the ssh-agent pendant). Maybe one could check this during initialization, and set tramp-default-method to either plink or pscp, depending on the result. I will try to see if this can be done easily from within a running Emacs. Btw, why does pscp method work so hard when pageant is not running? I see a lot of activity, including remote shell setup, remote `ls' command to get a directory, sending Perl scripts to the remote machine, etc. Why doesn't it simply invoke pscp to copy the darn file? Is it for file-name completion, perhaps? if so, maybe we should give users a way of disabling completion? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org From: Stefan Monnier [EMAIL PROTECTED] Date: Mon, 11 Dec 2006 23:48:43 -0500 Is it really that smart? Will it also be that smart if we do some arithmetics, like `(EMACS_INT)i + 0L' or `(EMACS_INT)i*1L'? Could be, or maybe not. My guess is that the optimization scheme uses an abstract domain where integer values are approximated by bounds (so a char is approximated by [-128..127]), so +1 should be handled just fine (after conversion to EMACS_INT this same char is still [-128..127] and since 1 is most likely approximated by [1..1], then the sum of the two will be approximated by [-127..128]). But why should it matter whether it does or not? Because if we understand that, we could devise a way to defeat the warning. I agree with the intention but I wouldn't want to fix the warnings by applying the optimization by hand, unless the code after optimization is just as clean and maintainable. I don't see how it can be less maintainable than it is now, what with the multi-layered macros we sprinkle everywhere. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
Perhaps the following patch would be more correct. After all, I don't think it will be common to have files with extensions .PNG, .TIFF, .BMP, etc. which are not images. It is more flexible to add the specific uppercase extensions, even if we add all of them. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
If .JPG/.JPEG is frequent, perhaps we should add it to `auto-mode-alist', then. Or do this: (push '(^\xFF\xD8\xFF\xE0\x00\x10JFIF . image-mode) magic-mode-alist) I am not sure which is better, but I agree we should do one or the other. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
wrong-type-argument markerp for Info-goto-node
emacs -Q C-h i C-x k *info* M-x Info-goto-node wrong-type-argument markerp error, for (marker-buffer nil) In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600) of 2006-12-11 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' 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: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-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 auto-compression-mode: t line-number-mode: t Recent input: down-mouse-1 mouse-1 M-x I n f o - g o t o - n o d e return return C-g C-h i C-x k return C-x C-b C-x 1 M-x I n f o - g o t o - n o d e return help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu re port-emacs-bug Recent messages: Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Quit [2 times] Loading info... Loading easymenu...done Loading info...done Composing main Info directory...done Info-build-node-completions: Wrong type argument: markerp, nil Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Eli Zaretskii wrote: Date: Tue, 12 Dec 2006 00:09:00 +0100 From: Lennart Borgman [EMAIL PROTECTED] It turned out that the test below for execute access failed. That seems strange since indeed runemacs.exe can be executed. Is that perhaps a bug in MinGW or in w32? Or am I misunderstanding something? Where could I try to report this (potential) bug? According to this: http://msdn2.microsoft.com/en-us/library/1w06ktdy(VS.80).aspx the Windows version of `access' doesn't support X_OK at all, only F_OK, R_OK, and W_OK. I don't really understand why did you need that test. The CVS version of emacsclient.c doesn't have such a test, AFAICS. Ah, thanks Eli. I did not know that X_OK was not supported (though somewhere in my head is a memory of hearing theis before). This is for the code I have added in my patched version of emacsclient.c to start Emacs automatically. Since I wanted to avoid errors I tested as much as I could come up with. Some testing overkill I guess. Now the automatic starting of Emacs seems to work very well on w32. If someone is interested I believe the code should run on other platforms too. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
In article [EMAIL PROTECTED], Glenn Morris [EMAIL PROTECTED] writes: Kenichi Handa wrote: years that I modified the code. But, AIST keeps copyright for all continuous years. If we must list all years explicitely in such a case, could you please update the lines for AIST too? I've done my best, but I would ask you to check the files where AIST holds copyright to make sure that they are correct. In several cases, the AIST copyright had not been updated for many years (before Emacs 21), whereas the FSF one had. I therefore only updated the FSF years. You may want to update AIST years too. In particular, in lisp/language: Thank you very much. I've just updated all AIST copyright years. I would also draw attention to the following files, which have no FSF copyright at all, it seems. Maybe this is correct, I don't know: lisp/composite.el lisp/international/ja-dic-cnv.el lisp/international/ja-dic-utl.el lisp/language/greek.el lisp/language/misc-lang.el lisp/language/thai-word.el They are written by me and not modified by any other person. So, I think it's ok not having FSF copyright. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ediff displays gibberish output
Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: How to reproduce: 1. save the attachments to file1.txt and file2.txt 2. M-x ediff RET and choose file1.txt file2.txt respectively 3. Type 'D' in ediff panel window and you see the difference output is gibberish as shown in the screenshot. GNU Emacs是什么？ What is GNU Emacs? If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /opt/free.APPS/emacs/share/emacs/23.0.0/etc/DEBUG for instructions. In GNU Emacs 23.0.0.3 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2006-11-22 on Fedora X server distributor `The X.Org Foundation', version 11.0.7000 configured using `configure '--prefix=/opt/free.APPS/emacs' '--with-gtk' '--with-freetype' '--with-xft' '--enable-font-backend' '--with-pop=yes' '--enable-locallisppath=/opt/share/emacs/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/site-lisp' '--without-xim' 'CFLAGS=-O2 -march=pentium-m -pipe -fomit-frame-pointer'' 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_GB.UTF-8 locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: erc-page-mode: t erc-services-mode: t erc-autojoin-mode: t erc-button-mode: t erc-ring-mode: t erc-pcomplete-mode: t erc-track-mode: t erc-match-mode: t erc-fill-mode: t erc-stamp-mode: t erc-netsplit-mode: t erc-smiley-mode: t erc-scrolltobottom-mode: t paredit-mode: t dired-omit-mode: t recentf-mode: t icomplete-mode: t show-paren-mode: t delete-selection-mode: t global-auto-revert-mode: t display-time-mode: t shell-dirtrack-mode: t tooltip-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 global-auto-composition-mode: t auto-composition-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: right backspace backspace backspace backspace 1 6 6 9 , 2 5 right right right right right right right right right right right right right right right right right right right down left up up right right backspace 2 down down left left left left backspace backspace backspace 1 6 6 9 , 2 5 down C-e return return help-echo switch-frame help-echo help-echo help-echo help-echo tool-bar kill-buffer q y C-x 1 C-x k return C-x k return C-x k return C-x C-b q help-echo switch-frame switch-frame switch-frame switch-frame help-echo M-x r e p o r tab b u tab return Recent messages: Buffer A: Processing difference region 0 of 2 Buffer B: Processing difference region 0 of 2 Processing difference regions ... done Mark set [3 times] Auto-saving...done Mark set Quit this Ediff session? (y or n) Updating buffer list...done Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Date: Wed, 13 Dec 2006 00:11:05 +0100 From: Lennart Borgman [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-pretest-bug@gnu.org This is for the code I have added in my patched version of emacsclient.c to start Emacs automatically. Since I wanted to avoid errors I tested as much as I could come up with. Some testing overkill I guess. Why not test the status returned by whatever function you use to run Emacs? If it is called to run a non-executable file, it will return an appropriate error code, right? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2: misjudged eol type when startup on windows-xp
Sorry for the late response on this matter. In article [EMAIL PROTECTED], Zhang Wei [EMAIL PROTECTED] writes: When startup on Windows-XP, the default-buffer-file-coding-system is set to chinese-gbk-unix, it should be chinese-gbk-dos by default on windows. I've just built the latest emacs-unicode on Windows-XP under Cygwin, but it sets default-buffer-file-coding-system correctly to japanese-shift-jis-dos. And, when I run Emacs with LANG=zh_CN.GBK, default-buffer-file-coding-system is set to chinese-gbk-dos. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
M-\ does not work with prefix argument as documented
Hi emacs -Q -D Insert a line like the following: otto foo ^ Place the cursor approximately where the accent is. Type M-- M-\ and all white space is deleted instead of only the one on the left hand side. Could you, please, also make the command symmetric? For example negative arguments are killing on the left hand side of the point and positive arguments on the left hand side. The default would remain as is. (There was recently a request--unrelated to M-\--for such a feature on gnu.emacs.help, killing white space left or right of the cursor). Dieter -- In GNU Emacs 22.0.91.2 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-12-03 on hans X server distributor `The X.Org Foundation', version 11.0.60802000 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: fr_FR.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Summary Minor modes in effect: gnus-mailing-list-mode: t gnus-agent-mode: t display-time-mode: t shell-dirtrack-mode: t auto-insert-mode: t show-paren-mode: t minibuffer-indicate-depth-mode: t delete-selection-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-d C-d C-d S P C C-f C-f C-f C-f C-f C-f C-f C-f : C-p C-p C-p C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b : C-p C-p C-b C-b C-b C-b C-b : C-n C-n C-n C-n C-s SPC SPC return backspace M-q C-c C-c f1 M-p return f2 M-x r e p o r tab b u tab return Recent messages: Auto-saving...done Mark saved where search started Auto-saving...done Sending... Sending via mail... Saving file /home/dieter/Mail/archive/sent... Wrote /home/dieter/Mail/archive/sent Sending...done History item: 1 Loading emacsbug...done -- Best wishes H. Dieter Wilhelm Darmstadt, Germany ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
