'woman' can't format the ssh man page
I don't know if this has been reported before - it's a bug that I've become so used to that I almost don't notice myself working around it any more... Typing: M-x woman RET ssh RET should display the 'ssh' man page, but instead I see only parts of it, strangely formatted. I just noticed myself switching to an xterm to run man ssh, where the page displays properly. In the xterm I see: SSH(1)BSD General Commands Manual SSH(1) NAME ssh - OpenSSH SSH client (remote login program) SYNOPSIS ssh [-1246AaCfgKkMNnqsTtVvXxY] [-b bind_address] and so on, whereas in the *WoMan 1 ssh* buffer I see: (SSH client) is a program for logging into a remote machine and for executing commands on a remote machine. It is intended to replace rlogin and rsh, and provide secure encrypted [...] that's how the buffer starts - no title, name, synopsis, etc. Further down the buffer I see: If is specified, it is executed on the remote host instead of a login shell. the xterm version has the word 'command' in there, between 'if' and 'is', which makes more sense. This is on debian unstable, but I'm pretty sure I've seen the same on a variety of other systems too. In GNU Emacs 22.0.91.30 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2006-12-16 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
Re: TRAMP password caching
Eli Zaretskii [EMAIL PROTECTED] writes: I have now added a primitive, called w32-window-exists-p, that you can use to check whether the agent is running on Windows. To that end, test whether w32-window-exists-p is fboundp, and if it is, see if the expression `(w32-window-exists-p Pageant Pageant)' evaluates to a non-nil value. If it does, the agent is running. Thank you! I've added that patch to tramp.el. I hope this resolves the issue in a way that the Windows port can now work the same as the Unix one. Since I haven't a build environment for w32, I cannot check whether it works as expected. It would be great if somebody could report about. Or I wait for the next snapshot from Lennart. Best regards, Michael. ___ 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/17/06, Richard Stallman [EMAIL PROTECTED] wrote: That is smart. Please install it. I can install it, if you don't want to install Kim's change instead right now. But I think his is the way to go. /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: ediff displays gibberish output
From: Leo [EMAIL PROTECTED] Date: Wed, 13 Dec 2006 01:22:50 + 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. Thank you for your report. I'm not sure this is a bug, though: `D' displays the raw output from Diff, whose encoding is not clear, because it comes from two different files that could be each encoded differently. Ediff reads the output of Diff in raw-text form, precisely for this reason, and that is how the buffer is displayed to you when you press `D'. What you see is not gibberish, but the UTF-8 encoding of the non-ASCII characters, exactly as they are in the written in file1.txt on disk. I'm not sure we can do any better here, unless we somehow know the encoding of each of the two files. Michael and Handa-san, could you please comment on this? This is also what I basically told Leo. --michael ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 'woman' can't format the ssh man page
That man page is written in doc rather than in an. With modern groff you have to pass -man-old to get the old an macros w/o also supporting the newer doc macros. If you do that with ssh.1 you see the same results as woman shows. This means that what woman needs is support for the doc macro set. (Sometimes AKA the mdoc macro set.) -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP password caching
Michael Albinus wrote: Eli Zaretskii [EMAIL PROTECTED] writes: I have now added a primitive, called w32-window-exists-p, that you can use to check whether the agent is running on Windows. To that end, test whether w32-window-exists-p is fboundp, and if it is, see if the expression `(w32-window-exists-p Pageant Pageant)' evaluates to a non-nil value. If it does, the agent is running. Thank you! I've added that patch to tramp.el. I hope this resolves the issue in a way that the Windows port can now work the same as the Unix one. Since I haven't a build environment for w32, I cannot check whether it works as expected. It would be great if somebody could report about. Or I wait for the next snapshot from Lennart. Best regards, Michael. Ok, I have uploaded a new unpatched version. ___ 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
Thanks for the revised patch for emacsclient. It solves the problem I reported. Francis - Original Message - From: Juanma Barranquero [EMAIL PROTECTED] To: Eli Zaretskii [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; emacs-pretest-bug@gnu.org; emacs-devel@gnu.org Sent: Friday, December 15, 2006 12:07 PM Subject: Re: Emacsclient/server filename quoting error On 12/15/06, Eli Zaretskii [EMAIL PROTECTED] wrote: Actually, a cleaner way of fixing this would be to have a WINDOWSNT-only wrapper for execvp, called, say w32_execvp, that does TRT with quoting the arguments. You like this one better, then? /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: Emacs Manual: G.5 Keyboard Usage on MS-Windows
From: Eli Zaretskii [EMAIL PROTECTED] To: Lennart Borgman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; emacs-pretest-bug@gnu.org Sent: Sunday, December 17, 2006 4:21 AM Subject: Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows Date: Sun, 17 Dec 2006 02:34:23 +0100 From: Lennart Borgman [EMAIL PROTECTED] CC: Francis Wright [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I did not follow this thread very carefully. However after some tips a year ago or more on EmacsWiki I wrote the following tip in the documentation that comes with EmacsW32: AltGr+Control - Is That Possible? Emacs uses some keys that are a combination of AltGr+Control. Those keys might seem impossible to type on MS Windows since you might have heard that AltGr is the same as Alt+Control. The truth is that AltGr is the same as /Alt+Left Control/. You can still use the /AltGr+Right Control/. /Important:/ You must type /AltGr/ before /Right Control/! Normally the order between shift, control etc does not matter, but here they do. Is that correct according to what you have found now, or? For me, in Emacs 22, by default RCtrl-AltGR is equivalent to Ctrl-Meta provided I press the RCtrl key first and hold it, then press AltGr, which is the other way around to what you wrote above! If I press and hold AltGr and then press RCtrl, the RCtrl makes no difference. If I set w32-recognize-altgr to nil then AltGR alone is equivalent to Ctrl-Meta and RCtrl has no effect, regardless of precisely when I press it. Maybe it's correct, but it's not really relevant. We were talking about the w32-recognize-altgr option, which is pertinent to support of ALtGr itself, either the literal key or its equivalent combination Alt+Control. We said nothing about AltGr+Right Control. Yes. However, I think it might be useful to document in the Emacs manual the way that RCtrl affects AltGr, which seems to be specific to Emacs and is not something that I would have expected. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Francis Wright wrote: From: Eli Zaretskii [EMAIL PROTECTED] To: Lennart Borgman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; emacs-pretest-bug@gnu.org Sent: Sunday, December 17, 2006 4:21 AM Subject: Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows Date: Sun, 17 Dec 2006 02:34:23 +0100 From: Lennart Borgman [EMAIL PROTECTED] CC: Francis Wright [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I did not follow this thread very carefully. However after some tips a year ago or more on EmacsWiki I wrote the following tip in the documentation that comes with EmacsW32: AltGr+Control - Is That Possible? Emacs uses some keys that are a combination of AltGr+Control. Those keys might seem impossible to type on MS Windows since you might have heard that AltGr is the same as Alt+Control. The truth is that AltGr is the same as /Alt+Left Control/. You can still use the /AltGr+Right Control/. /Important:/ You must type /AltGr/ before /Right Control/! Normally the order between shift, control etc does not matter, but here they do. Is that correct according to what you have found now, or? For me, in Emacs 22, by default RCtrl-AltGR is equivalent to Ctrl-Meta provided I press the RCtrl key first and hold it, then press AltGr, which is the other way around to what you wrote above! If I press and hold AltGr and then press RCtrl, the RCtrl makes no difference. I just tested and I see that you are right. You have to type RCtrl first (or hold it down if you do not use StickyKes) and AltGr after. I am rather sure it was the other way round before - I believe. I got the information at first from this page on EmacsWiki http://www.emacswiki.org/cgi-bin/wiki/AltGrKey#toc4 and it also says you have to type AltGr first. Anyway I am going to change that information now then. Yes. However, I think it might be useful to document in the Emacs manual the way that RCtrl affects AltGr, which seems to be specific to Emacs and is not something that I would have expected. Agree. It is specific to Emacs and it should be documented in (info (emacs) Windows Keyboard). BTW I also think this page should mention the trouble with ALT-TAB and the windows keys. This can't be totally bypassed without a low level keyboard (as I use to tell here ;-). That is very useful information to new users and I really want it to stand out in the documentation, not hidden somewhere in the middle of the text. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: color bug?
Ronald writes: see the title of the mini buffer window It just looks like you've customised the face mode-line-highlight to have something like a white foreground and a firebrick background. (If I'm looking at the right place, actually mode-line of the buffer 4.c, not the title of the mini buffer window.) When I changed to another color theme which is not ``arjen, there is no such problem. I don't think the colour theme arjen is part of Emacs. In any case you haven't described the `problem'. If the mouse is over certain parts of the mode-line, its appearance can change to indicate that you can click there. -- 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
Re: TRAMP password caching
Lennart Borgman [EMAIL PROTECTED] writes: Ok, I have uploaded a new unpatched version. Thanks a lot, Lennart. It works as expected. Best regards, Michael. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Date: Sun, 17 Dec 2006 19:26:30 +0100 From: Lennart Borgman [EMAIL PROTECTED] CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org BTW I also think this page should mention the trouble with ALT-TAB M-TAB is taken by many modern window managers, so this is not an MS-Windows only issue anymore. If it should be mentioned, that should be in the main body of the manual, not in a Windows specific appendix. and the windows keys. This can't be totally bypassed without a low level keyboard (as I use to tell here ;-). That is very useful information to new users and I really want it to stand out in the documentation, not hidden somewhere in the middle of the text. I don't understand what is wrong with the current text. It clearly explains the variables that affect the windows keys. It's impossible to write a manual where EVERYTHING STANDS OUT, for obvious reasons. Let's not exaggerate every obscure issue as if it were the only important thing we should describe in the manual. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Eli Zaretskii wrote: Date: Sun, 17 Dec 2006 19:26:30 +0100 From: Lennart Borgman [EMAIL PROTECTED] CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org BTW I also think this page should mention the trouble with ALT-TAB M-TAB is taken by many modern window managers, so this is not an MS-Windows only issue anymore. If it should be mentioned, that should be in the main body of the manual, not in a Windows specific appendix. Yes, that is right. Does not most users get hit by this problem? I think it should be mentioned in the main body then and that there should be a pointer to that part of the manual from where I suggest that it should be first. and the windows keys. This can't be totally bypassed without a low level keyboard (as I use to tell here ;-). That is very useful information to new users and I really want it to stand out in the documentation, not hidden somewhere in the middle of the text. I don't understand what is wrong with the current text. It clearly explains the variables that affect the windows keys. It's impossible to write a manual where EVERYTHING STANDS OUT, for obvious reasons. Let's not exaggerate every obscure issue as if it were the only important thing we should describe in the manual. The manual says that setting w32-pass-lwindow-to-system (and dito r) to nil prevents that these keys are sent to MS Windows. I do not know how many times I have said this now: It does not do that! They are sent to MS Windows. The only way to stop that according to the documentation from Microsoft is to use a low level keyboard hook. To show this just test emacs -Q M-: (setq w32-pass-lwindow-to-system nil) and then press lwindow + e. That will open MS Windows Explorer. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 'woman' can't format the ssh man page
Chris Moore wrote: I don't know if this has been reported before - it's a bug that I've become so used to that I almost don't notice myself working around it any more... Ditto. I reported the issue with the very same manpage in May 2004: http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00144.html The consensus then (off list, with the woman author) was that it would be nice if woman could at least say don't know how to format man pages of type FOO and produce no output, rather than displaying a broken page. And also it could suggest writing to the maintainer of the man pages in question to suggest using the standard macros... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
From: Lennart Borgman [EMAIL PROTECTED] To: Eli Zaretskii [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; emacs-pretest-bug@gnu.org Sent: Sunday, December 17, 2006 9:23 PM Subject: Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows The manual says that setting w32-pass-lwindow-to-system (and dito r) to nil prevents that these keys are sent to MS Windows. I do not know how many times I have said this now: It does not do that! They are sent to MS Windows. The only way to stop that according to the documentation from Microsoft is to use a low level keyboard hook. To show this just test emacs -Q M-: (setq w32-pass-lwindow-to-system nil) and then press lwindow + e. That will open MS Windows Explorer. The documentation for the variable `w32-pass-lwindow-to-system' carries a rider that key *combinations* involving the left windows key cannot be handled by Emacs, but the manual does not include this rider, and so is a little misleading. Perhaps adding a reference in the manual to the variable documentation for further details would suffice. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Francis Wright wrote: From: Lennart Borgman [EMAIL PROTECTED] To: Eli Zaretskii [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; emacs-pretest-bug@gnu.org Sent: Sunday, December 17, 2006 9:23 PM Subject: Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows The manual says that setting w32-pass-lwindow-to-system (and dito r) to nil prevents that these keys are sent to MS Windows. I do not know how many times I have said this now: It does not do that! They are sent to MS Windows. The only way to stop that according to the documentation from Microsoft is to use a low level keyboard hook. To show this just test emacs -Q M-: (setq w32-pass-lwindow-to-system nil) and then press lwindow + e. That will open MS Windows Explorer. The documentation for the variable `w32-pass-lwindow-to-system' carries a rider that key *combinations* involving the left windows key cannot be handled by Emacs, but the manual does not include this rider, and so is a little misleading. Perhaps adding a reference in the manual to the variable documentation for further details would suffice. Ah, yes, I see it has been added to the variable. That is very good! I did not notice that now. Thanks for adding this to the doc strings. However Info is still misleading here. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu tooltip error
From: Eli Zaretskii [EMAIL PROTECTED] To: Francis Wright [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Sent: Saturday, December 16, 2006 6:33 PM Subject: Re: Menu tooltip error From: Francis Wright [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Date: Sat, 16 Dec 2006 16:48:08 - I have now built the 22.0.91 pretest on a completely different machine and I observe the same problem. I suspect it may be triggered by my build environment, which was the same (or very similar) on both machines. It could be the build environment, but it could also be the runtime environment. For example, do you turn on or off some non-default Windows features, or install software that modifies Windows behavior, in the same way on both machines? I built without image support, and if you built with image support then it may be why I see the problem and you don't. I'll try building with image support and see what happens. Thanks, please do. However, I don't think the image support can modify menu behavior. I have now rebuilt Emacs with full image support. The toolbar and splash screen look prettier but the menu tooltip bug is still there. I thought that the menus might use image support if it was available, and hence presumably different code, but apparently not. I may well have changed some interface setting on both my main machines, or possibly even installed some other software that is provoking this bug, but I have no idea what. Fortunately, I can live with this problem until I find out what's causing it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: scroll-other-window scrolls wrong window for vc-revert-buffer
Richard Stallman [EMAIL PROTECTED] writes: I looked into this ... and it is because yes-or-no-p uses read-from-minibuffer, and thus obeys all key bindings. It could bind minibuffer-scroll-window around the call to yes-or-no-p. That would be a fix for C-x v u ... Stefan? But I don't see it would help in the case of (defalias 'y-or-n-p 'yes-or-no-p) That's the case where nothing works, because y-or-n-p doesn't obey any key-bindings... -- 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: Menu tooltip error
From: Eli Zaretskii [EMAIL PROTECTED] To: Francis Wright [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Sent: Saturday, December 16, 2006 6:35 PM Subject: Re: Menu tooltip error From: Francis Wright [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Date: Sat, 16 Dec 2006 16:48:08 - I have now built the 22.0.91 pretest on a completely different machine and I observe the same problem. I suspect it may be triggered by my build environment Btw, what is special about your build environment? could you describe it, please? I see you are using MinGW, which is what I use. But there are other parameters, like the precise version of MinGW runtime, the compiler, Binutils, etc. According to the MinGW installed.ini file I am running the following: runtime=mingw-runtime-3.11.tar.gz w32api=w32api-3.8.tar.gz binutils=binutils-2.15.91-20040904-1.tar.gz core=gcc-core-3.4.2-20040916-1.tar.gz make=mingw32-make-3.80.0-3.tar.gz I installed MinGW very recently using the installer from sourceforge, although most of the files seem to be dated 2004, so perhaps they are not as up-to-date as I thought. Otherwise, I am using Cygwin bash, cp, rm, etc., which should all be the latest versions. However, I initiate the build from a cmd prompt. I have the MinGW bin directory before the Cygwin bin directory in my path. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu tooltip error
Francis Wright wrote: I installed MinGW very recently using the installer from sourceforge, although most of the files seem to be dated 2004, so perhaps they are not as up-to-date as I thought. The updating of the MinGW download table at http://www.mingw.org/download.shtml does not work currently. There is a link to the actual download page at SourceForge however. Look for SF File Releases just above the table. There are newer binaries. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse click into window doesn't always select frame
On 11 Dec 2006, at 08:01, YAMAMOTO Mitsuharu wrote: It seems like a problem that is specific to the Mac Carbon port. Please try the following patch. If there's no problem with this for a few days, I'll install it. Your patch works as advertised and I it doesn't seem to cause any problems for me. Thanks for providing this! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ediff displays gibberish output
I'm not sure we can do any better here, unless we somehow know the encoding of each of the two files. [...] This is also what I basically told Leo. Clearly, we can take a look at each file, figure out their respective encoding, and if both use the same, then use that encoding to decode the diff output. I haven't looked at the code to see what kid of effort would be required to do that, but it's likely to be a fairly common case, so it'd be good to handle it right. Stefan ___ 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
Can you point to a single instance where doing a case-insensitve match as a fallback would be harmful? There are many patterns which are meant to apply to file names used for specific conventional purposes in a GNU-like system, names which are used with specific case patterns. Here's one example. (\\(/\\|\\`\\)\\.\\(bash_profile\\|z?login\\|bash_login\\|z?logout\\)\\' . sh-mode) The answer is no, and I've chosen a different solution. Please drop the subject. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Directory name completion blocks when it shouldn't
Is it feasible to fix read-file-name to obey the predicate in the completion case? It could be that the reason it doesn't do so was the difficulty of implementing that case efficiently. Since no one else seemed interested in this, I did it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: In a shell buffer, RET moves current prompt line to bottom of window.
Since the Emacs 22 jump scrolling upon entering a RET does not appear to serve any purpose, I suspect it is unintentional and, therefore, a bug. This is a feature, and it is controlled by comint-scroll-show-maximum-output. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ediff displays gibberish output
In article [EMAIL PROTECTED], Leo [EMAIL PROTECTED] writes: * Eli Zaretskii (2006-12-17 06:30 +0200) said: ^ From: Leo [EMAIL PROTECTED] Date: Sun, 17 Dec 2006 03:15:59 + But a file with eight-bit characters can have a correct diff output. What makes ediff fail where diff succeeds? I'm not sure what you mean, but my crystal ball says that you are looking at the output of Diff in a terminal that supports UTF-8 encoded characters. If that's the case, then you will only see correct output from Diff with UTF-8 encoded files; other encodings will show gibberish. By contrast, Emacs does not support a single encoding, it supports many different ones. It needs to know the right encoding to display the characters as readable. I mean in emacs running diff-buffer-with-file or vc-diff. The diff output displays correctly. That's perhaps because Emacs reads the output of process while decoding by a detected coding system. That method works for your test case, but fails in a case that two files contain non-ascii characters in different encoding (e.g. UTF-8 vs GBK). --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ediff displays gibberish output
* Kenichi Handa (2006-12-18 10:17 +0900) said: ^ [...] That's perhaps because Emacs reads the output of process while decoding by a detected coding system. That method works for your test case, but fails in a case that two files contain non-ascii characters in different encoding (e.g. UTF-8 vs GBK). In ediff, two files both in UTF-8 encoding that contain Chinese characters still output the diff in raw utf-8 coding (those \234 etc.) All my files are in utf-8 encoding and that's why I am surprised to see such output. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Date: Sun, 17 Dec 2006 22:23:26 +0100 From: Lennart Borgman [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org The manual says that setting w32-pass-lwindow-to-system (and dito r) to nil prevents that these keys are sent to MS Windows. I do not know how many times I have said this now: It does not do that! The effect is similar, and I don't see the need to complicate things by expanding this obscure issue. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
From: Francis Wright [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Date: Sun, 17 Dec 2006 21:58:36 - The documentation for the variable `w32-pass-lwindow-to-system' carries a rider that key *combinations* involving the left windows key cannot be handled by Emacs, but the manual does not include this rider, and so is a little misleading. Perhaps adding a reference in the manual to the variable documentation for further details would suffice. Sorry, I don't understand: what rider? what variable? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu tooltip error
From: Francis Wright [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Date: Sun, 17 Dec 2006 22:37:34 - According to the MinGW installed.ini file I am running the following: runtime=mingw-runtime-3.11.tar.gz w32api=w32api-3.8.tar.gz binutils=binutils-2.15.91-20040904-1.tar.gz core=gcc-core-3.4.2-20040916-1.tar.gz make=mingw32-make-3.80.0-3.tar.gz The only difference that I spot is that I have an older version of MinGW runtime (3.7 on one machine, 3.9 on another). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ediff displays gibberish output
From: Leo [EMAIL PROTECTED] Date: Mon, 18 Dec 2006 02:02:55 + All my files are in utf-8 encoding and that's why I am surprised to see such output. But that's a very special case. We cannot make Emacs work only in special cases. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: In a shell buffer, RET moves current prompt line to bottom of window.
Richard Stallman wrote: Since the Emacs 22 jump scrolling upon entering a RET does not appear to serve any purpose, I suspect it is unintentional and, therefore, a bug. This is a feature, and it is controlled by comint-scroll-show-maximum-output. Has someone been keeping a list of Emacs 22 features which have default behaviors different from the corresponding default behaviors in Emacs 21? This would be extremely helpful to pre-testers, like me, who have just recently started to use the Emacs 22. Perhaps it is buried somewhere in Info and I didn't look in the right place? Knowing which changed behaviors are intentional will help eliminate bug reports about things which are not bugs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: In a shell buffer, RET moves current prompt line to bottom of window.
Has someone been keeping a list of Emacs 22 features which have default behaviors different from the corresponding default behaviors in Emacs 21? This would be extremely helpful to pre-testers, like me, who have just recently started to use the Emacs 22. Perhaps it is buried somewhere in Info and I didn't look in the right place? Knowing which changed behaviors are intentional will help eliminate bug reports about things which are not bugs. The NEWS file lists such differences. Antinews in the Emacs manual does too, albeit in a briefer sometimes more frivolous fashion. -- 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
Re: emacs-unicode-2 crashed in zh_CN.UTF-8 environment
In article [EMAIL PROTECTED], Felix Huang [EMAIL PROTECTED] writes: I compiled the latest CVS version of emacs-unicode-2 branch in Ubuntu Edgy, and run it in a zh_CN.UTF-8 environment. Emacs crashed at the splash screen. If I turned off the splash (setq inhibit-splash-screen t), it was normal until I manually invoked the splash. And in some files, like a TeX file in LaTeX mode (with auctex), all characters in section names were squares. When I changed the environment variables (LC_ALL, LANG) to en_US.UTF-8, emacs did not crash at either splash screen or other pages that were crashed at. However, most characters were represented as squares thus it was incapable of editing. What do all charactes and most characters exactly mean? Do they include ASCII characters, or only Chinese characters? I configured the emacs with: ./configure --with-xft --with-freetype --enable-font-backend --prefix=/opt/emacs23 --with-x-toolkit=gtk I can't reproduce such a bug. Did you start Emacs with --enable-font-backend? Do you see the same bug with Emacs 22 (cvs HEAD) version? How about starting Emacs with -Q? #0 0x080ef1dd in fontset_font (fontset=137847608, c=24555, face=0x8e81fc8, id=43) at fontset.c:618 In the latest code, line 618 is this. retry: and that should should not cause crash. Please update and rebuild your emacs, and show me the result of: (gdb) bt full --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Shell completion on w32 uses / instead of \
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: When I use the Interactive Inferior Shell in emacs on w32 and press TAB for completion, I get / instead of \ after the directory names. Couldn't emacs add \ on w32 instead? Thanks anyway for your great work. B.R. Mats 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 c:/Download/emacs061211/emacs/etc/DEBUG for instructions. In GNU Emacs 22.0.91.1 (i386-mingw-nt5.0.2195) of 2006-12-11 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.0.2195 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: SVE locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Shell Minor modes in effect: shell-dirtrack-mode: t 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: M-x s h e l l return c d SPC . . return c d SPC b tab M-x r e p o r t SPC e m SPC b SPC return Recent messages: (C:\Download\emacs061211\emacs\bin\emacs.exe -q --no-site-file) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. [2 times] Loading shell...done ~/Download/emacs061211/emacs Completing file name... Completed Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
