Re: When in no-window use GNU Emacs clips contents in *Backtrace* buffer
Peter Dyballa wrote:
> When I try the same in xterm or in Apple's Terminal without windows,
> the truncated lines like in this example
>
> Debugger entered--Lisp error: (void-variable -)
> eval-buffer(# nil "/Users/pete/.emacs" nil t) ;
> Reading at buffer position 2$
> load-with-code-conversion("/Users/pete/.emacs"
> "/Users/pete/.emacs" t t)
>
> are not expanded, they seem to be clipped in *Backtrace* buffer. So
> it's not easy to get the buffer position where the error happens ...
How do you copy them in the xterm window? If you use xterm's clipboard
integration, then you shouldn't expect to get more than xterm can see on
the clipboard.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bootstrapping CVS Emacs Windows XP / gcc 3.4.4 fails
Christoph Conrad wrote: make[1]: Entering directory `/cygdrive/c/user/cco/emacs-cvs/lisp' Cygwin make does not work for building Emacs. That is documented in nt/INSTALL. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: compile error on Windows XP
Zhang Wei wrote: > process.c: In function `conv_sockaddr_to_lisp': > process.c:2307: `uint16_t' undeclared (first use in this function) > Please check if it compiles now. I checked in a Windows specific fix, since there have never been reports of this in the past, and that code has been there some time, but the same compilation error should happen on any platform where the system headers do not support the new size specific types introduced in ISO C99. Perhaps it is a safe assumption on other platforms that if IPv6 is supported, so is C99? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2 does not display U+3333
Hongzheng Wang wrote: > Jason Rumney wrote: > >> Try a different font. It may be that the font you are using claims to >> support that character, but doesn't have a glyph for it. >> > > I'm afraid not. I can re-produce this bug with the font DejaVu Sans > Mono, which does contain the Unicode char 0x (in Common section). > According to the truetype font engine built into Windows, it only supports the following scripts: symbol lao arabic cyrillic greek latin So it seems the font is not declaring its support correctly. xft / fontconfig probably lets you override such brokenness, but the brokenness may be deeper - eg it may declare that character to have a width of 0 or something similar. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2 does not display U+3333
Zhang Wei wrote: > Input the character U+ with `M-x ucs-insert ', it won't > display, not even in a hollow box, it looks like as if that char > doesn't exist, but moving the cursor *does* stop at it. > Try a different font. It may be that the font you are using claims to support that character, but doesn't have a glyph for it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: key binding of `M-&' shows up in menu as (M-)
Lennart Borgman (gmail) wrote: > Unfortunately I do not think that is the right change. This totally > spoils the possibility to use accelerators for the menus on w32. I do > not think the minor problem it solves justifies that. For now, it is the right change. In future when accelerators are supported, they will need to be supported in a cross platform way anyway, and this bug will still exist, so avoiding fixing this bug now will not help us later. > The reasonable value is in my opinion the position for the > accelerator within *name. Generally accelerators are defined by a character, not position. The first occurrence of that character gets underlined by the toolkit. But we need to check all toolkits that Emacs supports to be sure that this is sufficient information. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: clipboard integration hangs pasting text from emacs
Peter Wisnovsky wrote: > In GNU Emacs 22.0.990.1 (i386-mingw-nt5.1.2600) > > Loading semantic-edit...done > Loading semanticdb-file...done Emacs 21.1 has been released, so please use that rather than a pretest version. Also, I see you are using semantic. Make sure you are using the latest version from cedet.sourceforge.net, as there is a bug in previous versions which cause Emacs to use 100% CPU while it is idle. One of the symptoms was being unable to paste from Emacs while Emacs was in background. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display problem
Drew Adams wrote: > > What does Emacs mean by "Emacs 23"? There are currently two branches in CVS identifying themselves as Emacs 23 AFAIK. When you are using CVS versions, it helps considerably if you tell us details about which branch you are using, rather than relying on version numbers. I suspect you are using emacs-unicode-2, in which case the change of internal coding from emacs-mule to unicode would explain why you can't just reuse integer values to refer to the same characters. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display problem
Miles Bader wrote: > The "19" should be "21" in the unicode branch. > > I'm not sure I understand what this magic number 19/21 is. Is there a constant for it that could be substituted? I'm surprised that that is the only change needed. The code points between the unicode branch and Emacs 22 should be completely different, shouldn't they? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display problem
Drew Adams wrote: > emacs -Q > > (aset standard-display-table ?\014 [10 33030176 33030176 33030176 > > See two attached images. In Emacs 22 (all recent builds), this is > displays correctly. In Emacs 23: 1) Each character appears as an empty > rectangle. > What do you mean by Emacs 23? Thinking about this might help with your problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Console mouse support breaks unicode2 branch
Leo wrote: > >> In file included from term.c:418: >> buffer.h:403: error: redefinition of ‘struct buffer_text’ >> buffer.h:461: error: redefinition of ‘struct buffer’ >> buffer.h is included at the top of the file, so doesn't need to be included again, but shouldn't it be protected against double inclusion by the following? #ifndef EMACS_BUFFER_H #define EMACS_BUFFER_H ... #endif /* EMACS_BUFFER_H */ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Extra file in 22.0.990 release
The 22.0.990 pretest tarball contains the file emacs-22.0.990/info/.arch-inventory. There are many other files of that name in the repository, but they are filtered out from the release tarballs, so I think the presence of this one is an oversight. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Minor Cleartype rendering bug
Geoff Gole wrote: > Running emacs 22 under windows xp, I'm seeing a minor text rendering > error when Cleartype is enabled. This is already listed in etc/PROBLEMS. Search the file for "ClearType". ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x dired /// crashes emacs
>>> Rainer Stengele <[EMAIL PROTECTED]> writes: >>> M-x dired /// crashes my emacs w32 repeatable. Emacs asks to attach the gdb debugger but that doesn't really help. When you say it doesn't help, what exactly do you mean? Can you try running Emacs under gdb to start with? That way gdb will hopefully catch the error before the stack is messed up, or whatever it is that is preventing it from helping when you attach it after the fact. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Euro sign bound, Pound sign not bound. (Bug?)
Richard Stallman wrote: That would be good to install in the unicode-2 branch. Maybe I am misunderstanding what you wrote there, but it appears that even bug fixes cannot be installed in HEAD right now? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Maximization doesn't work properly on Windows Xp, Emacs 22.0.92.1
Lennart Borgman (gmail) wrote: I just tried the latest pretest (unpatched) and indeed AFAICS Emacs now behave as it should with a maximized window, at least on Windows XP. That is very nice! When was that change made? Apparently there is no such change, as Eivind can still reproduce the bug. So we need to find what is required to reproduce it, beyond simply moving the taskbar to the left of the screen, as neither I nor Lennart can reproduce it by that simple recipe. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Maximization doesn't work properly on Windows Xp, Emacs 22.0.92.1
Eivind Midtgård wrote: In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600) of 2007-01-01 on DTOP Please try the latest pretest before reporting bugs in old unreleased versions. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: abnormally high cpu-usage
Livin Stephen Sharma wrote: output of "top -o pid" please note: "Carbon Emacs" cpu-usage is 81.2%. Minor modes in effect: semantic-idle-scheduler-mode: t have you pulled the latest semantic-idle.el from semantic's CVS, or are you using the released version? The released one is known to cause high CPU usage with Emacs 22. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with overlays (on w32 only?)
Thanks, but I should have sent some code in addition to my explanation. The above works for me to, but can you please test the code below. That code gives the error. The important thing is the newline characters. The behaviour is the same on w32 as it is on X. What made you say it was on w32 only? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with overlays (on w32 only?)
Lennart Borgman (gmail) wrote: In the attached images I have one overlay one character long that has a red underline. In the first picture there is only this overlay at that point and the display is correct. In the second picture I have added another overlay, with a slightly blue background. This doesn't match with what your images show. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: expand-file-name leaves "/../" in expansions at times
Chong Yidong wrote: Convert filename name to absolute, and canonicalize it. All your examples are consistent with this behavior. The important thing is that DEFAULT-DIRECTORY is only consulted if the filename is relative. But shouldn't the "and canonicalize it" step involve replacing the ../ with the actual directories they represent? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dnd bug with setting case-fold-search nil
graphist wrote: I'm using NTemacs22 and have found one small bug. If you add the following statement in .emacs file: (setq-default case-fold-search nil) you can't drag and drop some files to emacs (eg: with ":" in its full path). I have tried to modify the dnd-get-local-file-name function in file dnd.el: %[A-Z0-9][A-Z0-9] ==>%[a-zA-Z0-9][a-zA-Z0-9] I changed that regexp to %[A-Fa-f0-9][A-Fa-f0-9], since there is no point in trying to decode G-Z as hex characters. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Juanma Barranquero wrote: On 4/12/07, Jason Rumney <[EMAIL PROTECTED]> wrote: Yes it can. Cool. How? (I searched Microsoft's docs, but they are less than clear sometimes and I didn't find anything which seemed to imply app-specific settings of ClearType...) You can specify the antialiasing you want when you load fonts, using the lfQuality element of the LOGFONT struct. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Juanma Barranquero wrote: ClearType cannot be deactivated for specific apps Yes it can. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Richard Matthew Stallman wrote: The Windows system was using ClearType. Changing that setting fixed the problem. Thanks Eli. Should Emacs users always turn off use of ClearType? These problems are not apparent with most fonts. I can only see them with some fonts if I reduce the size to 9 point, but it probably depends on screen resolution. If so, can Emacs do it automatically? Yes, this was my solution to Cleartype problems some time ago, but it was an unpopular one. We could add a user option. If not, is this documented in PROBLEMS or somewhere suitable? Eli just added it back, it had been previously removed because someone submitted some patches that was supposed to fix the problems. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
Nick Roberts wrote: The manual says: A "character" in Emacs Lisp is nothing more than an integer. That would have to change. Not really, since that statement does not imply that the reverse is true. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
martin rudalics wrote: I have the same problem with a popup-menu and a toggle-styled entry. Whenever I toggle the entry and line- or mouse-move to the menu title, the latter changes to something like "t", a dot, or an unprintable character. When I toggle the entry again the original title is restored, and changes again when I move there again ... How do you continue to interact with the menu after toggling the menu item? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
Lennart Borgman (gmail) wrote: Ah, then should not menu_kill_timer be called from within w32_free_menu_strings (or always before that)? I have fixed it now. I moved the freeing of strings earlier for popup menus, so we can guarantee they are freed even when a signal is raised instead of returning normally. Then the code in w32fns.c that makes sure the strings are freed when the menu is cancelled only needs to deal with menubar menus. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
Lennart Borgman (gmail) wrote: Do you mean that the second menu is created before returning from the first w32_menu_show. It does not look so to me, but I might be misreading the code. Is not "selection" that is returned from the first w32_menu_show what is used to decide to do? w32_free_menu_strings is also called from elsewhere, to handle the case where the menus are cancelled by pressing ESC or clicking outside the menu. This is what causes the problems, as it is not easy to figure out whether old strings need to be cleaned up. The creation of the second menu has fooled the cleanup code into thinking that w32_free_menu_strings has not yet been called at the point where Windows has finished destroying the menu (actually after a delay, because doing so immediately caused problems in the past), so it goes ahead and destroys the second menu's strings, which causes problems if the second menu needs to redraw its owner-drawn strings (the title) again. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
Lennart Borgman (gmail) wrote: Thanks, but is there a global variable wv? Do you mean current_popup_menu? Is that what is freed in w32_free_menu_strings? That is called right after discard_menu_item. So I still do not understand. Indeed it is w32_free_menu_strings that is the function I was thinking of, current_popup_menu is the Windows menu handle, and it seems the data I was thinking of is not stored as global variable but accessible through the menu handle. It is current_popup_menu that is the problem here, when the first menu's strings are being freed, current_popup_menu is actually pointing to the second menu. Looking at the code, we may be able to move things around to avoid this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
Lennart Borgman (gmail) wrote: I know one should not expect anything if there is no guarantee, but should all doc strings be read that way? The doc string for sit-for explicitly states both that it will not wait, and that it will not redisplay when input is pending. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
Here is the end of x-popup-menu in w32menu.c. It looks to me like the menu structure is freed before "selection" is used. Obviously you think otherwise, Jason. Can you explain to me what is happening here? Does perhaps w32_menu_show do more than the name suggests? discard_menu_items frees up the lisp menu structure for garbage collection. There is another copy of the menu structure in global variable wv, that is used by the C code that needs it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
Lennart Borgman (gmail) wrote: But unfortunately the other bug (menu title corruption in the second popup-menu) is still there. This bug indeed looks a bit serious IMO. I have not been able to reproduce it clearly before, but with the test code I sent I see it every time. What especially bothers me is that this happens during the time the popup-menu is displayed. At first the menu title is shown, but using the up/down arrows erases or even corrupts the text shown. It seems to me that something is wrong with the data structures sent to w32 menu handler - and that could lead to trouble. I think what happens is this: First menu structure created, and Windows asked to create the menu. User selects option from first menu. Second menu structure created, and Windows asked to create the menu. First menu structure destroyed after Windows destroys the actual menu. User uses arrows to move in second menu - when the cursor is moved the menu items moved from and to are redrawn. The problem is that there is only one copy of the menu structure kept. So when the second menu is created, it overwrites the first one. This causes two bugs: 1) A memory leak, since the first menu structure is never freed. 2) The menu structure for the second menu is destroyed while the menu is still active. There are two possible solutions to this: 1) Make the popup menu signal an error if it is used reentrantly. 2) Wait for Windows to destroy the menu before running any lisp code associated with the chosen action. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: vertical scrollbar error on MS Windows
Stephan Hennig wrote: I've done some tests with that version now (This is GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-02-19 on LENNART-69DE564). Scrolling has indeed improved. The erratic up and down movement of the buffer while dragging the scrollbar in _one_ direction seems to has gone away. Still there are some problems: It seems that the latest change reverted the previous buggy behaviour to earlier buggy behaviour, where the scrollbar handle resizes as you scroll. If this behaviour is generally preferred to the previous behaviour, then we should leave it like this until after the release. Experience has shown that it is going to take major changes in the way we perform our scroll-bar related calculations to make an improvement in this area without breaking it in some other way. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
Jason Rumney wrote: This particular one is specific to w32 Actually, I was wrong. redisplay_internal contains the following code which makes the behaviour the same on X (I have not yet found what prevents redisplay on Windows)... #if defined (USE_X_TOOLKIT) || defined (USE_GTK) if (popup_activated ()) return; #endif ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
The bugs I refer to here are in the display of the popup menus. The display of the second popup menu gets garbled very often. I also once saw that the menus did not open at all. I got an error instead. I have no idea of why. Probably not related directly to this, but may be caused by the same problem that the blocking of redisplay is trying to avoid. If you want to sync the threads, is there an explicit way to do it? Why can't popup-menu do it? It is not a simple matter of syncing the threads (the Lisp thread is paused waiting for the popup menu to complete anyway). It is the fundamental design of Emacs to be single threaded. Until that is changed, and every attempt so far hasn't gotten past the stage of talk, the forced use of multiple threads that Windows imposes on us is going to present problems. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
Lennart Borgman (gmail) wrote: I consider this bug and I can see other bugs here that seems related. Though I do not know if these bugs are only related to the w32 port. I can't comment, because I don't know which bugs you are referring to. This particular one is specific to w32, because the event handling on w32 is different than on X. Events on Windows arrive on a different thread, and in the case of popup menus, need to be processed on that thread because the Lisp thread is waiting for popup-menu to return and won't process its message queue during that time. On X, events are received by callbacks into the same thread of execution, so it can be safe there to perform redisplay while it isn't on Windows. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
Lennart Borgman (gmail) wrote: There still seems to be some problems with refreshing buffer contents. In the example below the buffer gets refreshed before the first popup menu, but not before the second popup menu. Redisplayed is blocked while popup menus are active. The user's attention is on the popup menu, so I don't see it as a problem, and AFAIK there were good technical reasons why it is as it is, to do with GC and the arbitrary data structures that might be associated with the menu. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? Web servers don't change anything (at least, no web server I've ever seen does, and I've worked with most of them). I don't know what happened in Drew's case, but I don't think this a real life problem that is worth making the code less readable over. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding systems and file completion for shell on w32
Lennart Borgman (gmail) wrote: There is a problem with spaces in the names too in the current code. And the output is quite confusing as it looks now. Spaces in file names seems to be a problem for all platforms. What about the output is confusing? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding systems and file completion for shell on w32
Lennart Borgman (gmail) wrote:
Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
We have also discussed the tab file name completion in a cmdproxy
*Shell* buffer. This is currently broken. I sent a suggestion to
fix it, but I have got no feedback whatsoever on this.
http://lists.gnu.org/archive/html/emacs-devel/2006-12/msg01128.html
That isn't a suggested fix, it is some code to bind completely new
functions to some function keys.
Yes, but it works. But maybe it interferes with the comint code in a
bad way?
This works too, and is a lot less code:
(setq comint-completion-addsuffix '("\\" " "))
The problem with both "solutions" is how to enable them only for
shell-mode, and only when the shell being used has dos semantics.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding systems and file completion for shell on w32
Lennart Borgman (gmail) wrote: Yes, but it works. But maybe it interferes with the comint code in a bad way? We are looking for something that causes backslashes to be used in completion when the shell is cmd.exe. We are not looking for a complete replacement for the completion mechanism. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding systems and file completion for shell on w32
Lennart Borgman (gmail) wrote: We have also discussed the tab file name completion in a cmdproxy *Shell* buffer. This is currently broken. I sent a suggestion to fix it, but I have got no feedback whatsoever on this. http://lists.gnu.org/archive/html/emacs-devel/2006-12/msg01128.html That isn't a suggested fix, it is some code to bind completely new functions to some function keys. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding systems and file completion for shell on w32
Lennart Borgman (gmail) wrote: We have previously on the developers list discussed coding systems for *Shell* buffers on w32. I have sent some suggestions, but I do not think any changes have been done yet. Could we please try to fix this? There are two parts to this. One part is to set the coding-system for input in default-coding-system based on the user's language environment, as is done on other platforms. The second is to consider whether we should make shell on Windows a special case and also set it's output coding-system. I disagree with the second part of this, as we do not know what commands the user will run, and what coding-system the output will be in. If the user is running commands like grep, diff, cat etc, then the coding-system will match the contents of the files they are processing. If they are mostly using dir, then the DOS codepage will certainly be better, but I do not think that is the most common use case. What is needed to fix this is to have shell-mode set the coding system independantly for each command that is run, but I cannot think of a good way to detect reliably what coding system the output should be read as, unless we make a special exception for dir and any other commands we can think of that will cause output in the DOS codepage. Such a change would be for after the release. We have also discussed the tab file name completion in a cmdproxy *Shell* buffer. This is currently broken. I sent a suggestion to fix it, but I have got no feedback whatsoever on this. Your suggestion must have been lost in the noise, that was a very long thread that deteriorated into off topic arguments so many people may have given up following it. Please send your suggestion again. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Cursor bug
Prof. G. Venkatarathnam wrote: The cursor is absent in my emacs in the beginning. If I delete a character after marking it, I get the usual block cursor. How do I make my cursor visible ? I din’t have this problem before. I’m using the latest version of precompiled win32 version available from auctex site. We are currently pretesting the next release of Emacs, which will be 22.1. It would help us if you could try that rather than using a precompiled version from elsewhere which may be built from an arbitrary checkout from CVS on an unknown date, and may contain any number of patches. Also, please try to reproduce the bug starting from "emacs -Q", and report any snippets from your .emacs that are required to reproduce the bug after you have narrowed down what causes it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Windox XP Mouse wheel error when using 2nd monitor placed to the left of primary monitor
Paul Whitfield wrote: In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-12-18 on NEUTRINO Perhaps you should update from CVS more often. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
Lennart Borgman (gmail) wrote: Jason Rumney wrote: Lennart Borgman (gmail) wrote: We never made any decision on this issue. Most of the answers pointed to that GetUserDefaultUILanguage is the correct function to use. Or am I just misinterpreting to confirm what I said at the beginning ;-) You are just misinterpreting to agree with what you yourself believe. Benjamin Riefenstahl had a similar setup as yourself, with a non-English locale on an English localized version of Windows, and he too would prefer the English tutorial, but I don't think we should limit ourselves to the languages that Windows has been translated to, and in some cases this is plainly the wrong language to use. I am sorry, but I do not at all understand what you mean. What do you mean with that "I don't think we should limit ourselves to the languages that Windows has been translated to"? Have we discussed that at all? Is not this discussion about how to choose the correct language for text to be shown inside Emacs (in this case the tutorial of couse)? The function you are suggesting we use returns the language used by Windows itself for its UI. If we use that function to determine the user's language preference, we (1) limit the language selection to languages that Windows has been localized in, and (2) the language cannot be changed by the user after installation except in Vista and installations of Windows 2000/XP that Microsoft makes available only to large multinational corporations. It would be very good if we continued this discussion. It may not matter very much for those using an English keyboard layout, but it definitively does if you use for example a Swedish keyboard layout. I don't see why keyboard layout has anything to do with it. The language that Emacs (and Gimp) uses is determined by the user's locale settings, not by the keyboard layout. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Character shown as \377 in *Shell* on w32
Eli Zaretskii wrote: This is because DOS programs and Windows programs use different coding-systems for their output. I believe you mean "console programs and GUI programs", not "DOS programs and Windows programs", is that right? Right. Native Windows console programs tend to use the DOS codepage corresponding to the user's locale. But I think ports of GNU tools are likely to use the equivalent ISO encoding (especially Cygwin, which ignores Windows and runs in its own world), and since these are very useful and widely used by Emacs users, I wouldn't want to fix on the DOS codepage for process I/O. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
Lennart Borgman (gmail) wrote: We never made any decision on this issue. Most of the answers pointed to that GetUserDefaultUILanguage is the correct function to use. Or am I just misinterpreting to confirm what I said at the beginning ;-) You are just misinterpreting to agree with what you yourself believe. Benjamin Riefenstahl had a similar setup as yourself, with a non-English locale on an English localized version of Windows, and he too would prefer the English tutorial, but I don't think we should limit ourselves to the languages that Windows has been translated to, and in some cases this is plainly the wrong language to use. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Character shown as \377 in *Shell* on w32
Kenichi Handa wrote: It seems that default-process-coding-system is not setup properly on Windows. When I run Emacs on my Windows, default-buffer-file-coding-system is set correctly to: japanese-shift-jis-dos but default-process-coding-system is: (undecided-dos . undecided-unix) This is because DOS programs and Windows programs use different coding-systems for their output. cmd.exe uses the DOS codepage. So there isn't a single coding-system that is likely to be correct in most cases. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Character shown as \377 in *Shell* on w32
Lennart Borgman (gmail) wrote: In *Shell* using cmdproxy.exe on w32 a character shows up as \377: 2006-12-10 16:14 6\377588\377879 emacs.exe It is actually from a directory list where emacs.exe is shown: 2006-12-10 16:14 6 588 879 emacs.exe It seems you have set your thousands separator to be a non-breaking space, and cmd.exe is using cp850 or cp437 for its output, while Emacs is expecting windows-1252 or iso8859-1. ___ 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
Lennart Borgman (gmail) wrote: I have never even thought about what Ctrl-Esc does in Emacs. Hope it does not do anything I want to use. It doesn't really make any sense, as ESC is used as a sticky Meta key, so the Ctrl- usually follows it. That Esc does not run some form of quit is probably surprising to most new Emacs users on w32. It does, you just have to press it 3 times to be sure. ___ 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
Lennart Borgman wrote: It is a very good idea to document those keys. Here is a preliminary list for w32: - Ctrl-Tab, Ctrl-Shift-Tab - Ctrl-C, Ctrl-X, Ctrl-V, Ctrl-Z - Ctrl-A - Alt-Space - Esc - Tab, Shift-Tab ** Also very important: - Ctrl- - Alt- - Alt-Print ** More clashes: - Alt-F4 You are overstating things here. None of these are grabbed by Windows. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
Kenichi Handa wrote: I couldn't compile the second program (saved as mstest.c) by gcc in my Cygwin environment. This is the error log. To compile a native Windows program with Cygwin gcc, you need to use -mno-cygwin. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
Drew Adams wrote: 1. Reminder: The bug report was about the default order of options in a custom buffer. If it were alphabetical, users could find options there easier. I can't think of any other program that orders its options alphabetically by default. Usually they are grouped by functionality, and ordered by importance/usefulness. Ordering the options alphabetically only helps users who are looking for a specific option that they know the name of, but there are better ways of finding a specific option than browsing a whole group and scanning through. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
Jason Rumney wrote: This is on the UK English version of Windows XP LangID = SYS: 0x809, USR: 0x809[en_GB] LCID = SYS: 0x809, USR: 0x809 [en_GB] GetUserDefaultUILanguage() = 0409 [en] GetSystemDefaultUILanguage = 0409 [en] Actually, the [en], which came from http://www.microsoft.com/globaldev/reference/win2k/setup/Langid.mspx is incorrect. These values are actually [en_US]. Nothing in my OS settings specifies US English. So these values are just plain wrong. It appears that these last two API functions report the localization package used by the Windows UI itself, which is distinct from the user's preferences for language settings they make in the control panel. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
Eli Zaretskii wrote: Date: Fri, 22 Dec 2006 01:11:01 +0100 From: Lennart Borgman <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Could people who have access to MS-Windows please try these two programs and report the results? It is important to describe the full details about your regional and international settings (found in Control Panel) on each machine where you test this. Thanks in advance. This is on the UK English version of Windows XP LangID = SYS: 0x809, USR: 0x809[en_GB] LCID = SYS: 0x809, USR: 0x809 [en_GB] GetUserDefaultUILanguage() = 0409 [en] GetSystemDefaultUILanguage = 0409 [en] Regional Options: Standards and formats: English (United Kingdom) Location: United Kingdom Advanced: Language for non-Unicode programs: English (United Kingdom) As far as I can tell from documentation, GetSystemDefaultUILanguage() and GetUserDefaultUILanguage() return a constant value that the user has no control over on all versions of Windows ME and XP Home, and most versions of Windows 2000, XP Professional and Server 2003. The exception to this is certain large corporate customers who get a special version of Windows so they can deploy a single OS image across all their machines regardless of language. For those cases, GetSystemDefaultUILanguage() should always return 0409 (english), as these images are based on the English version of Windows. GetUserDefaultUILanguage() result can be changed by the user at login, or by the administrators in policy files. Since the first set of values can be changed by the user on all versions of windows, I think it is more appropriate to use these in Emacs. They also seem to be more precise, offering the sub-language as well as the main language. The fact that these can get out of step, as Lennart has managed to do on his machine, seems to be a bug in Windows, and I think it is an edge case we shouldn't worry about. Some of Lennart's settings state that Swedish should be used on his computer, so he should not be surprised when programs such as Emacs take notice of that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Wrong language choosen on w32
LENNART BORGMAN wrote: Lennart Borgman wrote: Regional settings: Your local (location): Swedish Language setting: x Western Europe and United State (default) Control Panel - Regional Options - General. Unfortunately th e Regional Options control panel changes between every release of Windows, on XP there is no General tab, and none of the options I see let you choose "Western Europe and United States (default)". In any case, that is not a language, the only thing I can think of that fits that description is the default coding system (ie Windows-1252). Swedish is a language, not a location, so I think that is defining the locale. I think the problem is that the user interface for configuring this has always been confusing in Windows, which I guess is why they keep changing it with every release. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Wrong language choosen on w32
Lennart Borgman wrote: Regional settings: Your local (location): Swedish Language setting: x Western Europe and United State (default) -- enda ikryssade Where are you getting this information? Windows AFAIK does not distinguish locale from language, but does have a User locale and System locale that may be different. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Eli Zaretskii wrote: cmdproxy is IMO the _only_ level where this should be done I think it is wrong to do this in cmdproxy, as cmdproxy has no knowledge about what is a filename, and what is a literal string that must be passed to the command untouched. The right place to do this is when completing file names, since we know then that we are dealing with a file name. We should never change what the user has manually typed. ___ 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
Richard Stallman wrote: > The answer is no, and I've chosen a different solution. > Please drop the subject. > If a developers mailing list cannot be used for discussing development ideas, then I think I might as well unsubscribe. Discussing an idea in a useful way does not include continuing to pressure me after I've made a decision. I'm sorry if you felt pressured, but it seemed premature to dismiss my suggestion the first time you did so, as the only alternative proposal offered was an incomplete regexp that did not cover all jpeg files. Kim and others since refined it into a better solution, and I agree that solution is a better one for most image files. I still think there is a general underlying bug here though that is not specific to image files, but to transfer of files from sources that do not preserve case (ISO format CDs, DOS/Windows machines, SD Cards, floppy disks etc). But you seem to think it is more important not to use sh-mode for .LOGIN than it is to fix this bug, so I will leave it alone now. ___ 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
Richard Stallman wrote: The answer is no, and I've chosen a different solution. Please drop the subject. If a developers mailing list cannot be used for discussing development ideas, then I think I might as well unsubscribe. ___ 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
Richard Stallman wrote: > It would handle that one case, but it would still produce false > matches. > It would only produce false matches for cases where Emacs would have defaulted to Fundamental mode. Yes, and that is a mistaken outcome. There is no reason to make such mistakes happen. When an entry should match more than one case pattern, we write it to do so. That's a small amount of work, and it gives 100% correct results. Please drop this idea. The underlying problem here is that people receive files from sources that use a case-insensitve filesystem. This can happen to ANY type of file, so should we rewrite ALL our regexps? Can you point to a single instance where doing a case-insensitve match as a fallback would be harmful? Perhaps it would be easier to eliminate any such cases by explicitly adding them to auto-mode-alist. ___ 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
Richard Stallman wrote: > Perhaps this can be solved by first doing a case-sensitive scan through > auto-mode-alist, then if that fails to find a match do a > case-insensitive scan. Brilliant! It would handle that one case, but it would still produce false matches. It would only produce false matches for cases where Emacs would have defaulted to Fundamental mode. Is that so bad, or am I missing something? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [h-e-w] image support in the newer EmacsW32 builds
Suraj Acharya wrote: The GUD icons seem to be a bit odd too - notice the wrapped go and stop icons. A number of pbm images in the etc/images/gud directory are not marked as binary. I tried running "cvs admin -kb go.pbm" myself, but it did not work, I am not sure whether it is because I don't have admin priviledges, or there is something strange about the server setup on savannah, or my client (cvsnt). The files that need to be marked as binary are (all in etc/images/gud): go.pbm next.pbm nexti.pbm pp.pbm step.pbm stepi.pbm stop.pbm ___ 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
Miles Bader wrote: I don't think they'd care in general, and might even approve. Like most people, even though I never use windows, I occasionally receive files from windows users, and there's lots of crufty old windows software that still uses DOS-like names. I think it's the special cases that you to be careful about, e.g., .c -> c-mode, .C -> c++-mode. Perhaps this can be solved by first doing a case-sensitive scan through auto-mode-alist, then if that fails to find a match do a case-insensitive scan. ___ 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
Chris Moore wrote: Is there any reason not to just treat the regexps in auto-mode-alist as case insensitive? Is there any kind of file where the case of the extension matters? .C is commonly used for c++ files where filenames are case-sensitive. ___ 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
Mathias Dahl wrote:
Richard Stallman <[EMAIL PROTECTED]> writes:
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.
I guess it is a matter of taste, but I would prefer if Emacs uses the
technique above instead of looking at the file name.
The only problem with this method is that the actual regexp you need is
more complex, as there are different versions of JFIF, and Exif to check
for (most digital cameras use the latter). image-jpeg-p has a much more
relaxed check, basically "^\xFF\xD8\xFF[\xE0-\xEF]..+(JFIF|Exif)", but
with the search for JFIF|Exif limited based on the first two bytes of
the ..+ portion - which indicate the length of the file header. If you
can't limit the search to the header, then the regexp may become too
inefficient for use in magic-mode-alist.
___
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:
Please do. I hoped it could be determined simply via the existence of
environment variables (as it is possible with ssh-agent, environment
variables $SSH_AUTHENTICATION_*), but it doesn't seem so easy. And I
also don't know a command like 'ps' which returns running processes,
in order to check whether pageant is active.
PuTTY itself uses the following code:
*int* *agent_exists*(*void*)
{
HWND hwnd;
hwnd = FindWindow(*"Pageant"*, *"Pageant"*);
*if* (!hwnd)
*return* FALSE;
*else*
*return* TRUE;
}
___
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
Lennart Borgman wrote: I know that it is important that many users build Emacs too, but the problem on MS Windows is that most users will not do that. That means that there will be fewer testers when we do not supply prebuilt binaries. The aim of a pretest has always been to get a limited number of testers who are technically skilled enough to give us meaningful bug reports. What we don't want during pretest is a flood of vague bug reports from the masses, because we don't have the bandwidth to deal with that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (make-frame-visible), doesn't
Lennart Borgman wrote: Sounds better to me, but is this only an X-window thing? I don't think so. Any windowing system that supports overlapping windows can have "visible" windows that cannot be seen by the user due to being obscured behind other windows. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: "Use font-lock-support-mode rather than calling lazy-lock-mode"
ishikawa wrote: > So I am wondering. Is there a way to print the > calling function of turn-on-lazy-lock > a la the following code snippet? > (backtrace) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: UTF-8 vs. menus
Dan Jacobson wrote: Gentlemen, $ emacs -Q 領導過胖.txt now click the "Buffers" menu at the top of the screen. I bet it doesn't know more than 256 characters. Not ready for Unicode. Yes, you mentioned you knew, but as of 20060923 version: still ugly. Can you please submit your bugs with report-emacs-bug. That way important configuration information will be included. Multilingual menus have been supported for some time, but without that configuration information, we can't tell whether what you see is due to a bug or a limitation of the toolkit you are using. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Arabic - moving cursor over text shifts characters
The same happens on MS Windows, it is caused by the underlying APIs that we use to draw text being RTL aware, while Emacs is not. So when we ask the system to draw a string of text, it is drawn correctly RTL, but when we draw it a character at a time while moving the cursor, Emacs does not have the correct idea about which character is under the cursor, so draws the wrong one - effectively reversing the order if you move the cursor right through the text. This sort of problem will eventually be solved when the emacs-bidi code is complete, but for now, it is really just a symptom of the fact that Emacs is not suitable for editing RTL languages. David Reitter wrote: When I copy&pasted a bit of arabic script into a current CVS Emacs (Carbon port), things seemed fine until I moved the cursor to the left over the text - which seemed to change (rearrange) the characters displayed. This can be seen in the screenshots attached. The second one shows the display after pasting, the third one shows what's displayed after moving the cursor over the text. The first screenshot shows what the original (on a website) looked like. Characters seem to be shifted to the right. I don't know what the significance of this is - I don't read arabic. I haven't changed the display to right-to-left (and I wouldn't know how to do that). In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0) of 2006-10-23 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution 0.9.9d X server distributor `Apple Computers', version 10.4.8 configured using `configure '--without-x' '--prefix=/usr/local'' 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: nil locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Text Minor modes in effect: delete-selection-mode: t show-paren-mode: t pc-selection-mode: t cua-mode: t smart-frame-positioning-mode: t aquamacs-styles-mode: t recentf-mode: t emulate-mac-german-keyboard-mode: t encoded-kbd-mode: t osx-key-mode: t tooltip-mode: t mac-input-method-mode: t tool-bar-mode: 0 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 column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: A-a A-v A-z A-v Recent messages: byte-code: Beginning of buffer call-interactively: Buffer is read-only: # Making completion list... Buffer is read-only: # Quit Mark set [9 times] Undo... Undo! Mark set Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: no colors in os x emacs application
; Global coloring (global-font-lock-mode) This will toggle font lock off or on, depending on the state before the call. On older versions of Emacs, font-lock was off by default, so that line would turn it on. On current development versions of Emacs, font-lock is on by default, so that line will turn it OFF! For consistent results, use: (global-font-lock-mode 1) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-correct-word does not work without windows system
emacs user wrote: From: Jason Rumney <[EMAIL PROTECTED]> flyspell-auto-correct-word seems to be more appropriate for binding to a key than flyspell-correct-word, as the latter relies not just on the mouse, but on menus as well. I see that is already bound to C-. yes, but the point was to have the specific features of flyspell-correct-word on a non-window system terminarl. Which specific feature of flyspell-correct-word is not also a feature of flyspell-auto-correct-word? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-correct-word does not work without windows system
emacs user wrote: (define-key map [(control ?\.)] 'flyspell-auto-correct-word) + (define-key map [(meta ?\^m)] 'flyspell-correct-word) map) thanks for doing this. I am getting this: Debugger entered--Lisp error: (error "flyspell-correct-word must be bound to an event with parameters") call-interactively(flyspell-correct-word) flyspell-auto-correct-word seems to be more appropriate for binding to a key than flyspell-correct-word, as the latter relies not just on the mouse, but on menus as well. I see that is already bound to C-. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Segfault and font corruption in menu under Windows
Ralf Angeli wrote: Perhaps somebody can tell me what the problem was which the check-in from 2002-02-22 was supposed to solve in order for me being able to check if this is still an issue. I could not find anything related to it in the list archives of emacs-devel or emacs-pretest-bug (the archives of which only start in December 2002). There was a resource leak when popup menus were cancelled (by pressing ESC) without selecting any option. To fix this, I initially tried freeing the resources when the WM_EXITMENULOOP message was received, but this was too early for the case where a menu action was selected, since the Lisp code was still dealing with the selection at that point. It might be possible to fix this with careful use of synchronization between the Lisp thread and the message loop, but there is already some synchronous message passing in the menu code I think, so deadlocks may be difficult to avoid. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs crashed on windows-xp
Eli Zaretskii wrote: I googled the web and found a same problem report here: http://www.ysnb.net/meadow/meadow-users-jp/2006/msg00091.html This report is in Japanese, so I cannot read it. It seems like a gnuserv problem I wonder how could gnuserv have anything to do with reading Info manuals. The gnuserv error message seems to be a symptom of a different problem in both reports. The other report was when using wanderlust (mail reader) with zipped mail folders. Zhang, Are your info files compressed? If so, it could be the same problem, but enough factors are different that it may be unrelated. The other report is from a user of Meadow, which is a derivative of Emacs which is sufficiently different that it has its own bugs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Peter Dyballa] Re: Coding system of file not recognised correctly
Peter Dyballa wrote: The reason it *had*, is that I had in load-path four ELisp files: So if I understand you correctly, this was a local configuration problem, and we can remove this bug from FOR-RELEASE? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: single-key-description no good for Japanese and Chinese chars
People didn't care for that suggestion, so I will continue to test the key itself. Perhaps I could test the key somehow with `generic-char-p' (how?), but, as Stefan pointed out, there are also other keys that cannot be trivially converted to chars. How about: (char-valid-p keymap-entry) Since all self-insert-command keys must be valid chars if inserting them is going to work. This way you don't need to test for generic-char-p, since char-valid-p returns nil for generic characters unless you give it a non-nil second arg. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: local chars displayed as numbers
Kenichi Handa wrote: At least windows-1252 doesn't cover all eight-bit bytes. There are a few invalid bytes: 0x81, 0x8c, 0x8e... 0x8c is "Latin capital ligature Oe", and 0x8e is "Latin capital letter Z with caron" according to Windows XP character map. 0x8d is missing, as is 0x90 (nbsp in latin-1). I'm not sure if the latter is just filtered out from display in character map though (0x20 space is also not displayed). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: single-key-description no good for Japanese and Chinese chars
Drew Adams wrote: I'll take your word for it; I know nothing abou this. I thought Handa was saying that an integer event indicated such an "invalid" key. If not, then I guess one is reduced to parsing the `single-key-description' - that's what I do currently. You are confusing events with entries in keymaps. An event is something that is generated by the user typing or using the mouse. A keymap maps events onto commands, but it does not necessarily do that directly by having one entry for every possible event. What Handa was saying is that an integer entry in a keymap indicates a generic character - that is, a keymap entry that maps a whole group of individual events onto a single command (self-insert-command being the most useful command to map in this way). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: local chars displayed as numbers
Kenichi Handa wrote: But, it seems that we need similay additions to the other lang. env. Do you have any suggestions? Here is a list from codepage.el that shows which language groups each Windows codepage is used for and which standard charset contains the same characters. Where it says "exact match", means the non-control character positions are an exact match. All these windows codepages contain extra characters in the 128-159 range. ;; Codepage Mapping: ;; ;; Windows-1250: ISO-8859-2 (Central Europe) - differs in some positions ;; Windows-1251: ISO-8859-5 (Cyrillic) - differs wildly ;; Windows-1252: ISO-8859-1 (West Europe)- exact match ;; Windows-1253: ISO-8859-7 (Greek) - differs in some positions ;; Windows-1254: ISO-8859-9 (Turkish)- exact match ;; Windows-1255: ISO-8859-8 (Hebrew) - exact match ;; Windows-1256: ISO-8859-6 (Arabic) - half match ;; Windows-1257: ISO-8859-4 (Baltic) - differs, future Latin-7 ;; Windows-1258: VISCII (Vietnamese) - Completely different ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: single-key-description no good for Japanese and Chinese chars
Drew Adams wrote: So what? Binding thousands of characters is something computers are good at. Binding thousands of characters is a waste of memory and time. Or are you saying that that would affect performance in an unacceptable way? If so, what's special about `self-insert-command' - why not bind them all to a different command, `foobar', which does what is needed Because self-insert-command does what is needed! Why should we introduce a new binding to do the same thing so that you can remain blissfully ignorant of the purpose of generic characters? What problems? These are not real keys, why would someone try to use them with read-kbd-macro? What indicates that they are not "real keys"? You have to parse the `single-key-description' and match against "Character set " to determine that. Or you have to test the type of the event/key. Or some such. You won't get an event/key to test the type of, because they are not real keys. There is no way to generate that events that match generic characters. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: single-key-description no good for Japanese and Chinese chars
Drew Adams wrote: My question is this: Why do these keys have as their binding `self-insert-command'? Because that is the binding for all characters of that group. I hear you saying that they are not valid keys, and you can't use them with `self-insert-command', and you can't use them (their descriptions) with `read-kbd-macro' - so why bind them to `self-insert-command'? Because doing so binds every character within that character group to self-insert-command without having to bind several thousand characters individually. and no one would have the problems of using keys with `self-insert-command' and their descriptions with `read-kbd-macro' What problems? These are not real keys, why would someone try to use them with read-kbd-macro? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: single-key-description no good for Japanese and Chinese chars
Miles Bader wrote: "Drew Adams" <[EMAIL PROTECTED]> writes: Shouldn't the `single-key-description of a Chinese etc. character simply be that Chinese character in a string? Er, perhaps I misunderstand you, but that's exactly what it appears to be: (single-key-description ?字) "字" What does (single-key-description (read-event)) say if you input that character using XIM? I think that is the only context where such a key event would arise in reality. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: single-key-description no good for Japanese and Chinese chars
Richard Stallman wrote: Shouldn't the `single-key-description of a Chinese etc. character simply be that Chinese character in a string? In an ideal world, that would be ok, but most people's terminals probably can't display the Chinese character, so they will see just a box. Such people would be unlikely to use the key, so that might not be so bad. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: single-key-description no good for Japanese and Chinese chars
Drew Adams wrote: There is nothing in the documentation that suggests that it should generate a unique value for every possible key sequence. Maybe there is nothing about that in the doc, but doesn't it seem logical? No. If that was its purpose, then it should be called something like `single-key-unique-identifier'. A "description" has never had any connotation of uniqueness in any context I have ever seen. Wouldn't the Chinese (or whatever) character itself (as a string) be the best value to use as the output of `single-key-description'? Or can't we have a string with Chinese characters in it? I don't know for sure, I would expect descriptions to be ASCII descriptions, but that does not seem to be true for the £ key on my keyboard. Again, I'm no expert on this stuff. I'm just thinking out loud and asking. I'm thinking that, logically, I should be able to do the same thing with a Chinese character that I can do with some of the other "strange" characters that are bound to `self-insert-command'. I see, for instance, lots of characters that I doubt would be associated with a key from any keyboard - and they all work OK with my code. They probably belong to ISO-*, but I'm not sure they're on any keyboard. Most iso-8859-* characters are on their respective nations' keyboards. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: single-key-description no good for Japanese and Chinese chars
Drew Adams wrote: `single-key-description' returns the exact same key description for each key in the asian character sets (Japanese, Chinese, etc.). For example, for the different input events (keys) 20864 and 20992, the exact same description is given: "Character set JISX0208.1978 (Japanese): ISO-IR-42". Are there keyboards that produce these keycodes? Or are these characters that are the result of an input method? Or are you just looping, potentially feeding single-key-description garbage? I don't think it is unreasonable for single-key-description to use the same description for these many thousands of characters especially if they are not produced directly by any keyboard in common use. There is nothing in the documentation that suggests that it should generate a unique value for every possible key sequence. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Memory leak?
Richard Stallman wrote: It is not surprising that that change would have this effect if a program uses the function this way. I'm not sure what you mean by "this way". I wonder if you are meaning the explanation of a different bug I gave last week where I discovered that the semantic-idle timer seemed to be continously running. But my explanation then was of the buggy behaviour, I had attributed the problem to a different change. From my understanding of the workaround that has been posted, it works by changing a call to cancel-timer to instead increase the timeout period to 1 hour. I think that means that cancel-timer is not actually cancelling the timer in the case where the timer is repeating due to Emacs still being idle. Or maybe cancel-timer was never supposed to deal with this case, and the author of semantic only thought it was working because idle-timer functions were only running once each time Emacs became idle anyway. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Memory leak?
Jason Rumney wrote: Andreas Roehler <[EMAIL PROTECTED]> writes: Sorry, it's not the memory, it's the CPU which is taken. Do you use semantic? There have been a couple of reports recently about semantic's idle timer functions taking 100% CPU on recent CVS versions of Emacs. The problem seems to be caused by this fix: 2006-08-20 Richard Stallman <[EMAIL PROTECTED]> * emacs-lisp/timer.el (run-with-idle-timer): Pass t to timer-activate-when-idle, so timer can run before Emacs becomes non-idle again. After reverting that fix, I see Emacs CPU usage go from 0 to 2% for a brief instant when the idle timers kick in. With that fix, the CPU usage goes to 50% and stays there until I perform an input event to break the idle loop. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: find-grep-dired can't use zgrep
Dan Jacobson <[EMAIL PROTECTED]> writes: > Naw, need complete freedom like M-x grep... So use M-x grep... we won't report you for it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: focus-follows-mouse should be nil by default on MS Windows
Eli Zaretskii <[EMAIL PROTECTED]> writes: > Okay, but I think what Emacs does now is better. Do we need to follow > bad example of Alt-TAB? I have to disagree here. If the user is using the keyboard to switch frames, then they probably want the pointer to stay out of the way, not move to the frame they switched to. Moving the pointer to the frame switched to by C-x 5 o is a hack to work around window managers that use the mouse position to determine focus (you said so yourself). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Memory leak?
Andreas Roehler <[EMAIL PROTECTED]> writes: >> Emacs consumes all the memory by time, as `top' indicates. > Sorry, it's not the memory, it's the CPU which is taken. Do you use semantic? There have been a couple of reports recently about semantic's idle timer functions taking 100% CPU on recent CVS versions of Emacs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Error on gnus-group-make-rss-group
"Andrew M. Scott" <[EMAIL PROTECTED]> writes: > nnrss: http://www.michaelhyatt.com/: Not valid XML (error XML: > (Not Well-Formed) Invalid end tag (expecting p) at pos 49598) > and w3-parse doesn't work (void-function w3-parse-buffer) You'd be better off asking for help on the gnus mailing lists, as the only bugs I see here are with the webpage you are trying to subscribe to. Since w3 is not part of Emacs, the second part of the above message is not a bug, I guess Gnus is trying to fall back on the more lenient w3 html parser when xml parsing fails so it can try to do rss auto-discovery when you give it an html page. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: focus-follows-mouse should be nil by default on MS Windows
YAMAMOTO Mitsuharu wrote: Let me confirm one thing. The value doesn't affect the behavior with respect to the mouse position on W32, either? I'm asking because I'm thinking about setting its default to nil on Mac Carbon, because if the value is t, "C-x 5 o" moves the mouse pointer to the upper-right corner of the focused frame. The same happens on W32. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Clipboard hang on w32
Richard Stallman wrote: When trying this, I found that the debugger window in (a second) Emacs was hanging after about every page of output until I pressed the mouse button. I had to do this many times, as garbage collection was in progress at the time I stopped Emacs so the stack trace was almost 4000 lines long. Why does the debugger generate so much output? I requested a stack trace (bt). As Emacs was garbage collecting at the time, the stack was very deep (almost 4000 frames). Have you requested more output than you really need? Does it have a command not to pause due to output? The pause is caused by Emacs not processing the output. The debugger just outputs to stdout continuously. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Clipboard hang on w32
Richard Stallman wrote: I have noticed today that while pasting from Emacs to other apps, the other app seems to hang until some input event occurs in Emacs (normally when I switch to it and click on the window). I suspect that the cause is the recent changes to sit-for. I cannot reproduce the problem in emacs -Q, so there is probably some code using sit-for inappropriately, but still, I think it is a bug that sit-for prevents clipboard operations from proceeding normally. This ought to be easy to investigate once you run it under a debugger. When trying this, I found that the debugger window in (a second) Emacs was hanging after about every page of output until I pressed the mouse button. I had to do this many times, as garbage collection was in progress at the time I stopped Emacs so the stack trace was almost 4000 lines long. I think this has the same cause, and is probably present on all platforms - the clipboard problem may be limited to Windows, since the clipboard is handled quite differently than other platforms. My interpretation of the problem is that the call to sit_for in read_char is allowing the idle timers to run.These idle timers (semantic-idle-core-handler) are doing a lot of work, and using input-pending-p to allow user input to interrupt them. The problem seems to be that process-output and clipboard requests are not being handled while Emacs is inside that sit_for, so we need to interrupt the idle timer with user input. I'm not sure if the process-output not appearing is a bug in Emacs, since this situation is really no different than a long running lisp operation blocking Emacs from doing other things - the only difference being that this particular code is designed to allow the user to interrupt it with input since the author knew it would be long-running and wanted to make it a background task, but maybe the author should have taken a different approach and done small chunks of work each time the idle timer was triggered then returned control to the main lisp loop. Clipboard operations though, should not be blocked by lisp code running, so I'll look at why this blocks and whether there is another way to implement it. #3829 0x010596b5 in mark_object (arg=24463841) at alloc.c:5708 #3830 0x01059579 in mark_object (arg=276082221) at alloc.c:5819 #3831 0x010596b5 in mark_object (arg=24102913) at alloc.c:5708 #3832 0x010596b5 in mark_object (arg=24102937) at alloc.c:5708 #3833 0x0105969f in mark_object (arg=277153465) at alloc.c:5706 #3834 0x01059f29 in mark_object (arg=24104964) at alloc.c:5694 #3835 0x0105acd9 in Fgarbage_collect () at alloc.c:5150 #3836 0x0100bea0 in Ffuncall (nargs=3, args=0x82eca0) at eval.c:2916 #3837 0x01109b23 in Fbyte_code (bytestr=274603859, vector=273010180, maxdepth=64) at bytecode.c:679 #3838 0x0100b5fa in Feval (form=272789861) at eval.c:2319 #3839 0x0100a22c in internal_catch (tag=274582273, func=0x100b0a2 , arg=272789861) at eval.c:1210 #3840 0x0110a14f in Fbyte_code (bytestr=274603811, vector=274586180, maxdepth=24) at bytecode.c:854 #3841 0x0100b9d6 in funcall_lambda (fun=26371108, nargs=0, arg_vector=0x82efd4) at eval.c:3169 #3842 0x0100becb in Ffuncall (nargs=1, args=0x82efd0) at eval.c:3039 #3843 0x01109b23 in Fbyte_code (bytestr=274602051, vector=26371332, maxdepth=8) at bytecode.c:679 #3844 0x0100b5fa in Feval (form=272789965) at eval.c:2319 #3845 0x0100d8cd in internal_lisp_condition_case (var=2697, bodyform=272789965, handlers=272790261) at eval.c:1414 #3846 0x0110a103 in Fbyte_code (bytestr=274602019, vector=274586052, maxdepth=24) at bytecode.c:869 #3847 0x0100b9d6 in funcall_lambda (fun=26371300, nargs=0, arg_vector=0x82f3e8) at eval.c:3169 #3848 0x0100becb in Ffuncall (nargs=1, args=0x82f3e4) at eval.c:3039 #3849 0x0100d4ad in Fapply (nargs=2, args=0x82f3e4) at eval.c:2470 #3850 0x0100c189 in Ffuncall (nargs=3, args=0x82f3e0) at eval.c:2963 #3851 0x01109b23 in Fbyte_code (bytestr=18687611, vector=18687636, maxdepth=32) at bytecode.c:679 #3852 0x0100b5fa in Feval (form=18687597) at eval.c:2319 #3853 0x0100d8cd in internal_lisp_condition_case (var=24102913, bodyform=18687597, handlers=18687669) at eval.c:1414 #3854 0x0110a103 in Fbyte_code (bytestr=18687467, vector=18687484, maxdepth=40) at bytecode.c:869 #3855 0x0100b9d6 in funcall_lambda (fun=18687428, nargs=1, arg_vector=0x82f74c) at eval.c:3169 #3856 0x0100becb in Ffuncall (nargs=2, args=0x82f748) at eval.c:3039 #3857 0x0100d0e1 in call1 (fn=24150929, arg1=279104900) at eval.c:2763 #3858 0x01049779 in timer_check (do_it_now=1) at keyboard.c:4526 #3859 0x010926ee in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=24102913, wait_proc=0x0, just_wait_proc=0) at process.c:4339 #3860 0x0108c25c in sit_for (timeout=240, reading=1, do_display=1) at dispnew.c:6543 #3861 0x01050fc3 in read_char (commandflag=1, nmaps=3, maps=0x82fb40, prev_event=24102913, used_m
Re: Clipboard hang on w32
Chong Yidong wrote: (nor is it obvious from your description that it IS a result of sit-for). I suspected that, because it was changed recently, and there had been other problems with it, including something about calling it from idle timers, which I suspected may have been the case here. Probably the easiest thing to do is find out where in your customizations the bug is coming from. The following is what is required to trigger the problem: (require 'cedet) ; CEDET 1.0pre3 from http://cedet.sourceforge.net/ (require 'jde) ; JDE 2.3.5.1 from http://jde.sunsite.dk/ C-x C-f Test.java Test.java can be a pre-exisiting or new file, it does not seem to matter. From that point on, all clipboard pastes into other applications hang if Emacs is the clipboard owner. JDE is a complicated package, and enables several features of semantic (part of CEDET), so either package could contain the cause. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
