Re: Carbon: Unicode keyboard layouts does not work properly
On 19 Feb 2007, at 01:24, YAMAMOTO Mitsuharu wrote: On Sun, 18 Feb 2007 13:09:42 +, David Reitter [EMAIL PROTECTED] said: The symptom I am experiencing is that trying to invoke the emacs command of `insert-parentheses´ I want to press Meta+Shift+8. When using the danish latin keyboard layout, I get what I want (ie. M-() but with a unicode keyboard layout, emacs claims I am pressing M-* as it would have been on an american keyboard. Thanks for the report. I could reproduce it. Actually, I'm not sure why the current code does not work. But the Keyboard Layout Services API, which is available on Mac OS X 10.2 and later, seems to solve the problem. Could you try the following patch? I've installed the patch in the Aquamacs CVS - Christian, please try it out and report back, it should be available in tomorrow's nightly build. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
auto-insert help-buffer
emacs -q M-x auto-insert Prompt for keyword C-h opens a help-buffer with descriptions, but without the corresponding keywords visible. This buffer vanishes, when clicked by mouse. = scroll-bar-toolkit-scroll: Wrong type argument: window-live-p, #window 7 Clicking the scroll-bar once also produced a segmentation fault. (error-message was in German: Speicherzugriffsfehler) So far __ Andreas Roehler Suse 10.0 In GNU Emacs 22.0.93.4 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-02-18 on kiste X server distributor `The X.Org Foundation', version 11.0.60802000 Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: 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: - i n s e r t return a s d M-x up return return up M-x up return C-x C-w e i l . e l return y M-x up return return C-h help-echo mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 M-x r e p o r t - e m a c s - b u g return backspace backspace backspace backspace backspace backspace backspace C-g M-x C-g up up up up up M-x up return return C-h help-echo down-mouse-1 drag-mouse-1 C-g M-x r e p o r t - e m tab return Recent messages: Loading help-mode...done scroll-bar-toolkit-scroll: Wrong type argument: window-live-p, #window 7 call-interactively: Command attempted to use minibuffer while in minibuffer Quit [2 times] mouse-drag-region: Wrong type argument: window-live-p, #window 9 mouse-minibuffer-check: Wrong type argument: window-live-p, #window 9 Quit 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
C-u beginning/end-of-buffer.
In GNU Emacs 22.0.93.6 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-02-19 on escpc40 X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk'' Both C-u M- and C-u M- have forward-line calls that check for arg but not (consp arg). Therefore, C-u M- leaves point not at the beginning of the buffer, but from the docstring C-u is only supposed to affect whether the mark is set at the previous position. Thanks, Matt ___ 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
Drew Adams [EMAIL PROTECTED] writes: And replacing two em-dash characters with \u2014 is hardly making extraordinary efforts. I think if you're going to fix two of them you may as well go the extra mile and replace all three of them to prevent us having to have this argument at a later point about the remaining em-dash character. ___ 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
As far as I remember scrolling was always problematic (in the same way?) in W32 Emacses, so this is not a new bug? I just installed some changes to _improve_ on those scroll-bar issues. Can you -- and other W32 users -- please try out the latest CVS and tell me ASAP if there are still _severe_ problems with it. At least it seems to work a lot better than before, but we need as much testing as possible BEFORE to the release (which *is* very close now!!). So, also tell me if you tested it, and didn't find any problems! Thanks. -- 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: vertical scrollbar error on MS Windows
On 2/19/07, Kim F. Storm [EMAIL PROTECTED] wrote: Can you -- and other W32 users -- please try out the latest CVS and tell me ASAP if there are still _severe_ problems with it. Hard to say what is a severe problem. With the sample file (scroll.txt): - Make the frame's height 30 lines. - Visit scroll.txt - Move point to eob. - Scroll up to bob. - Release the mouse button. - Scroll down. I can't get past line 46. Juanma ___ 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
Kim F. Storm wrote: As far as I remember scrolling was always problematic (in the same way?) in W32 Emacses, so this is not a new bug? I just installed some changes to _improve_ on those scroll-bar issues. Can you -- and other W32 users -- please try out the latest CVS and tell me ASAP if there are still _severe_ problems with it. At least it seems to work a lot better than before, but we need as much testing as possible BEFORE to the release (which *is* very close now!!). So, also tell me if you tested it, and didn't find any problems! Thanks. I have uploaded a new unpatched version Emacs+EmacsW32 for those who want to test: http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl ___ 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
Yes, I know you're arguing that buff-menu.el contains just one non-ASCII char and it would be friendlier to use an escape (It's me who added the comment line just above the one which is causing you so much grief.) Perhaps you're right. But you said yourself your fix wouldn't work for packages with lots of Unicode chars. Where do you intend to put the line? At ten chars? A thousand? Who cares? This sort of argument is no reason not to install a simple change that will avoid problems. ___ 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
On 2/19/07, Richard Stallman [EMAIL PROTECTED] wrote: Who cares? This sort of argument is no reason not to install a simple change that will avoid problems. Nor was I implying that. Juanma ___ 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
Eli Zaretskii wrote: Date: Sun, 18 Feb 2007 23:48:29 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Eli Zaretskii wrote: Date: Sun, 18 Feb 2007 23:32:01 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org 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? I think the problem is simply that IE, like Emacs, needs to be told the encoding explicitly, when its defaults are wrong. There's no magic wand here. Maybe, I just do not understand why IE6 just does not save the bytestream it recieves. For the same reason Emacs doesn't do that with non-ASCII text: it doesn't treat it as a byte stream, it treats it as an encoded text. Yes, and I guess they do that for a reason, see below. If I understand things correctly here this thread was mostly about downloading an elisp file. It looks to me like if you are trying to save what the web browser shows then it will save something it can show again, not the original downloaded file. When the web browser downloads the file it usually has some extra information from the mime headers. That information helps it display the file. My guess is that when the web browser saves the file that is displayed it tries to merge that information with the downloaded file. Therefore the file changed in this way is different from the downloaded file. So instead of saving what is viewed in the browser the user need to download the file directly to his disk. There use to be something like right click and choose Save Link As or something similar in the web browsers for this. Would it suffice to tell the users how to download the files? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
unclear doc for existence of mark
emacs -Q C-h i, choose Elisp manual, g Mark This text is not clear: Each buffer has its own value of the mark that is independent of the value of the mark in other buffers. When a buffer is created, the mark exists but does not point anywhere. We consider this state as the absence of a mark in that buffer. Once the mark exists in a buffer, it normally never ceases to exist. The notion of mark existence is unclear here. In a virgin buffer, it says, the mark exists. Yet, in this state the mark is absent. So, the last sentence presumably wants to talk about lack of absence (i.e. presence), rather than existence. Otherwise, it contradicts the first statement that the mark exists from the beginning, as well as its own statement that the mark never ceases to exist (if it has always existed and it always will exist, then once the mark 'exists' says nothing useful. The first statement, that the mark exists from the beginning but points nowhere, could be kept as the consistent point of view throughout, but that is not currently the case. In that case, instead of absence and then, later, existence (presence), we would speak of the mark pointing nowhere and then pointing somewhere. Alternatively, the starting point of the explanation could be changed, to say that in the beginning the mark does not exist. The rest would follow more or less as is, with non-existence/existence replacing absence/presence (no need for two terms, which increases confusion). Either of these approaches would be consistent; the current text is not consistent, and is confusing. My own preference is the second alternative: Don't say that the mark exists from the beginning. We might want to introduce the function `mark' here, saying that when (mark t) returns nil it means that the mark does not yet exist - that is, it indicates that virgin state. Also, quotation marks should not be used in this text, in any case - they add nothing but more confusion. New terms that are defined can be put in a different font (e.g. bold), but should not be between quotation marks. I don't know what the Emacs doc convention is on this. In any case, even if the Emacs doc convention were to quote the defining occurrence of a new term, the sections quoted here should not be quoted. In that case, only absence would be quoted. Certainly, exists should not be quoted in the last sentence cited. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu re port-emacs-bug Recent messages: (C:\Emacs-22-2007-01-25\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ 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
Kim F. Storm schrieb: As far as I remember scrolling was always problematic (in the same way?) in W32 Emacses, so this is not a new bug? I just installed some changes to _improve_ on those scroll-bar issues. Glad to hear about that! So, also tell me if you tested it, and didn't find any problems! Unfortunately, I have only a dial-up connection and can't give immediate feedback on new Emacs versions. Thanks again for looking into this! Best regards, Stephan Hennig ___ 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
So, also tell me if you tested it, and didn't find any problems! Unfortunately, I have only a dial-up connection and can't give immediate feedback on new Emacs versions. One advantage of using CVS over tarballs is that you only need to download the (compressed) _changes_. Even with a dial-up connection that shouldn't take a long time. -- 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: 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: please use ?\u2014 instead of the unicode character inbuff-menu.el
Jason Rumney wrote: 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). Thanks, that makes things more clear to me. Then the things that differ is the mime headers sent and the interpretation of those. I think that is where the problem arise as I said in a later message. 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. I agree. There are more simple solutions. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: c-mode imenu: Stack overflow in regexp matcher
Stefan Monnier wrote: Yes, I saw that, but it's still not clear to me what's going on here. E.g. the match any non-identifier char can match a parenthesis, is that correct? I guess a quick fix is to replace [^()] by [^()\n]. Ping, anyone in CC land? The problematic [^()]* part was installed 12-Dec-99, before which it was just ^\\.*. If it really needs to match across newlines, maybe it could match up to some finite number. 1999-12-12 Martin Stjernholm [EMAIL PROTECTED] * cc-menus.el (cc-imenu-c++-generic-expression): Match classes with nonhanging open braces. Don't match the throws clause that might follow the function prototype in C++. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: c-mode imenu: Stack overflow in regexp matcher
G I guess a quick fix is to replace [^()] by [^()\n]. Ping, anyone in CC land? Don't know about CC land, but I'd say there are a few in la-la land. -- 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: please use ?\u2014 instead of the unicode character inbuff-menu.el
I don't think this a real life problem that is worth making the code less readable over. I agree. There are more simple solutions. Please explain why 1) is more readable than 2): 1) ;; Use U+2014 (EM DASH) to underline if possible, else U+002D (HYPHEN-MINUS) (if (char-displayable-p ?-) ?- ?-))) 2) (if (char-displayable-p ?\u2014) ?\u2014 ?-))) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
use-file-dialog and use-dialog-box on w32
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: *** I have been downloading the emacs version 22.** + auctex binaries since 22.0.50 and in none of them has the file dialog worked when clicking on the options under File on the menu bar. C-h v use-file-dialog and use-dialog-box reveals that both are set to t System is msw 98. *** In GNU Emacs 22.0.93.1 (i386-mingw-windows98.) of 2007-01-26 on NEUTRINO X server distributor `Microsoft Corp.', version 4.10. configured using `configure --with-gcc (3.4) --cflags -Ic:/Programme/GnuWin32/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: enu locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Help Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t view-mode: t Recent input: down-mouse-1 help-echo mouse-movement mouse-movement drag-mouse-1 help-echo help-echo help-echo M-w help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar file kill-buffer help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug help-echo help-echo C-g C-h v f i l e tab tab help-echo backspace backspace backspace backspace backspace u s e tab tab down-mouse-2 mouse-2 help-echo help-echo help-echo help-echo down-mouse-1 mouse-movement mouse-movement drag-mouse-1 M-w help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-b ug Recent messages: Loading pp...done Type C-x 1 to remove help window. Making completion list... call-interactively: Buffer is read-only: #buffer *Completions* [2 times] Making completion list... Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done Quit Making completion list... [2 times] *** E-Mail body has been placed on clipboard, please paste them here! *** ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
GTK Toolbar Annoyance
I have this in my .emacs: (custom-set-variables '(tool-bar-mode nil)) I start emacs with emacs-snapshot-gtk -g 80x40, and the frame that opens is 80x37 (I presume it is made 3 shorter due to the toolbar removal). Then I press C-x 5 2, and a new frame is spawned with the proper 80x40. If I do this with emacs-snapshot-x -g 80x40 (non-gtk emacs snapshot) the first frame opens with 80x40, and C-x 5 2 spawn the new frame with 80x40 as well. Which I presume is the right behavior. In GNU Emacs 22.0.93.1 (i486-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-02-17 on pacem, modified by Debian (Debian emacs-snapshot package, version 1:20070217-1) X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/22.0.93/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.0.93/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.0.93/leim' '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_DK.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: down-mouse-1 mouse-1 help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)... Skipping dictionaries-common setup for emacs-snapshot Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done Loading gnus...done Loading advice...done For information about the GNU Project and its goals, type C-h C-p. [2 times] Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done call-interactively: End of buffer ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Emacs splash screen trouble
# echo foo1 foo1 # echo foo2 foo2 # emacs foo* The splash window is now in the bottom part of the frame, and the foo1 is in the upper part. If I select to foo1 window it is cursorless, I do a C-x 1 (by habbit), and now I either have to wait for the splash code to time out, or find the secret splash buffer and click in it. Possible solution: Any selection of a window, or buffer editing expires the splash screen. In GNU Emacs 22.0.93.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-02-17 on pacem, modified by Debian (Debian emacs-snapshot package, version 1:20070217-1) X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/22.0.93/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.0.93/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.0.93/leim' '--with-x=yes' '--with-x-toolkit=athena' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_DK.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: down-mouse-1 mouse-1 help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Loading 00debian-vars...done Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)... Skipping dictionaries-common setup for emacs-snapshot Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done Loading gnus...done Loading advice...done For information about the GNU Project and its goals, type C-h C-p. [2 times] 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
Re: vertical scrollbar error on MS Windows
Juanma Barranquero [EMAIL PROTECTED] writes: On 2/19/07, Kim F. Storm [EMAIL PROTECTED] wrote: Can you -- and other W32 users -- please try out the latest CVS and tell me ASAP if there are still _severe_ problems with it. Hard to say what is a severe problem. With the sample file (scroll.txt): - Make the frame's height 30 lines. - Visit scroll.txt - Move point to eob. - Scroll up to bob. - Release the mouse button. - Scroll down. I can't get past line 46. That's right, but still it is not worse than before. I don't see an easy fix for this, so let's leave it for after the release. -- 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: vertical scrollbar error on MS Windows
Hi, thanks for the quick fix! I tried latest Emacs W32 (U070219) and for me it seems to be OK: I haven't found any problems with vscrolling. Br, P 2007/2/19, Lennart Borgman (gmail) [EMAIL PROTECTED]: Kim F. Storm wrote: Can you -- and other W32 users -- please try out the latest CVS and tell me ASAP if there are still _severe_ problems with it. At least it seems to work a lot better than before, but we need as much testing as possible BEFORE to the release (which *is* very close now!!). So, also tell me if you tested it, and didn't find any problems! I have uploaded a new unpatched version Emacs+EmacsW32 for those who want to test ___ 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
On 2/19/07, Kim F. Storm [EMAIL PROTECTED] wrote: That's right, but still it is not worse than before. Aha. I didn't know, I always work without scroll bars. I don't see an easy fix for this, so let's leave it for after the release. Agreed. Juanma ___ 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
On 2/19/07, Drew Adams [EMAIL PROTECTED] wrote: Please explain why 1) is more readable than 2): 1) ;; Use U+2014 (EM DASH) to underline if possible, else U+002D (HYPHEN-MINUS) (if (char-displayable-p ?-) ?- ?-))) 2) (if (char-displayable-p ?\u2014) ?\u2014 ?-))) In 1), the code is straightforward (a fact obscured in the e-mail because em dash got changed to hyphen-minus), and the comment clearly says what's happening, and even identifies *both* characters involved. In 2), \u2014 does not mean anything per se, so the user hasn't the foggiest idea why some random unicode char would be used instead of -. You'll need the same comment as before to clarify that (and, in fact, Stefan didn't remove the comment when changing the code). You can convince me that 2) will get less trouble than 1) for people with broken tools; but not that 2) is more legible. Juanma ___ 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 don't think this a real life problem that is worth making the code less readable over. I agree. There are more simple solutions. Please explain why 1) is more readable than 2): 1) ;; Use U+2014 (EM DASH) to underline if possible, else U+002D (HYPHEN-MINUS) (if (char-displayable-p ?-) ?- ?-))) 2) (if (char-displayable-p ?\u2014) ?\u2014 ?-))) Check the current code. It's a mix of the two. I changed it not because of any web server/client issue, but simply because the resulting code is more readable. Stefan ___ 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
Please explain why 1) is more readable than 2): 1) ;; Use U+2014 (EM DASH) to underline if possible, else U+002D (HYPHEN-MINUS) (if (char-displayable-p ?-) ?- ?-))) 2) (if (char-displayable-p ?\u2014) ?\u2014 ?-))) Check the current code. It's a mix of the two. I changed it not because of any web server/client issue, but simply because the resulting code is more readable. Yes, thank you. That's in fact what I meant. It helps that the two characters appear different, and the comment makes it clear what the intention is. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs splash screen trouble
Thomas Christensen [EMAIL PROTECTED] writes: # echo foo1 foo1 # echo foo2 foo2 # emacs foo* The splash window is now in the bottom part of the frame, and the foo1 is in the upper part. If I select to foo1 window it is cursorless, I do a C-x 1 (by habbit), and now I either have to wait for the splash code to time out, or find the secret splash buffer and click in it. Thanks for pointing this out. Is the following a satisfactory solution? *** emacs/lisp/startup.el.~1.426.~ 2007-01-28 10:49:26.0 -0500 --- emacs/lisp/startup.el 2007-02-19 21:32:12.0 -0500 *** *** 1388,1393 --- 1388,1394 (save-selected-window (select-frame frame) (switch-to-buffer GNU Emacs) + (make-local-variable 'cursor-type) (setq splash-buffer (current-buffer)) (catch 'stop-splashing (unwind-protect ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: use-file-dialog and use-dialog-box on w32
From: Edward Casey [EMAIL PROTECTED] Date: Sun, 18 Feb 2007 13:11:43 -0600 I have been downloading the emacs version 22.** + auctex binaries since 22.0.50 and in none of them has the file dialog worked when clicking on the options under File on the menu bar. C-h v use-file-dialog and use-dialog-box reveals that both are set to t System is msw 98. Strange. What does happen when you click on File-Open File from the menu bar? In GNU Emacs 22.0.93.1 (i386-mingw-windows98.) of 2007-01-26 on NEUTRINO This indicates that you built the binary yourself, is that true? If so, what version of MinGW runtime do you have installed? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs splash screen trouble
Chong Yidong [EMAIL PROTECTED] writes: Thanks for pointing this out. Is the following a satisfactory solution? Yes, it works. The only thing I spot is that it seems to be inside a recursive-edit until the time expires. Thomas ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
move-end-of-line in comint buffers
Please describe exactly what actions triggered the bug and the precise symptoms of the bug: 1) Type `M-x shell RET' 2) Type in a command (or any random junk) that wraps to the next visible line 3) Type `C-p'. The point should now be at the beginning of the prompt. 4) Type `C-e'. The point is now at the end of the prompt / beginning of the command. 5) Type `C-e'. The point is now at the end of the visible line. 6) Type `C-e'. The point is now at the end of the actual line. Behavior (5) above is unexpected. I could not find information about this in either the Emacs manual, the Elisp manual, or NEWS. The behavior may be desireable, but if so, should be documented. 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 /usr/local/share/emacs/22.0.93/etc/DEBUG for instructions. In GNU Emacs 22.0.93.1 (i686-pc-linux-gnu, X toolkit) of 2007-02-20 on maru X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--without-toolkit-scroll-bars'' 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: C locale-coding-system: nil default-enable-multibyte-characters: t Major mode: Shell Minor modes in effect: display-time-mode: t shell-dirtrack-mode: t erc-autojoin-mode: t erc-button-mode: t erc-ring-mode: t erc-pcomplete-mode: t erc-track-mode: t erc-match-mode: t erc-fill-mode: t erc-stamp-mode: t erc-netsplit-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo C-x C-f n e tab backspace backspace p r o j tab n e tab / t r tab s i tab s r tab s e n tab return M-x s h e l l return C-y C-a C-p C-e C-e C-e C-x 5 2 switch-frame C-h i switch-frame M-x r e p o r t - e m tab return Recent messages: Loading /home/md5i/src/elisp/nxml-mode/rng-auto.el (source)...done Loading time...done Loading /home/md5i/.emacs-custom...done Loading server...done nil [2 times] Loading ansi-color...done Mark set Loading info...done Composing main Info directory...done Loading emacsbug...done -- Michael Welsh Duggan ([EMAIL PROTECTED]) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
