Re: BUG in scroll-lock-mode?
* Juri Linkov (2007-06-08) writes: ,[ http://mid.gmane.org/E1Dnaf1-0007am-Cg%40neutrino.iwi.uni-sb.de ] | An open issue is the key binding for toggling the mode. If the minor | mode should be able to be activated in some major modes but not in | others, it doesn't make much sense to bind this to the Scroll Lock key | which in my understanding means to enable or disable it globally (not | just for Emacs but for other applications aware of it as well). ` I see that Scroll_Lock does nothing special on X so it's safe to bind it to this key. I doubt that this is the case for any X server. There are likely people or distributions using the key as a modifier or something else. As far as I understand the Scroll Lock key was originally supposed to toggle scroll lock globally, i.e. for the desktop as a whole, just like Caps Lock or Num Lock. There are even keyboards which provide an LED for indicating if scroll lock is active. I'm not sure if it is actually possible to configure an X server like that. (Some research on the interweb did not really reveal useful results.) But if this is the case, the behavior I'd expect would be that Emacs recognizes a globally activated scroll lock (even when not having focus) and activates Scroll Lock mode for all buffers. But as mentioned before I'd find this behavior less useful as the current one. And while I am using the Scroll Lock key for toggling Scroll Lock mode in specific buffers, I would be very careful in making that the default. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: BUG in scroll-lock-mode?
* Leo (2007-06-07) writes: I put (scroll-lock-mode t) in ~/.emacs, but it is still disabled after restart emacs. Is this a bug in scroll-lock-mode? Scroll Lock mode is a buffer-local minor mode, so your command will not enable it globally. You can enable it via a hook. For example, if you wanted the mode to be activated when browsing info files, you could do this with something like (add-hook 'Info-mode-hook 'scroll-lock-mode). -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: BUG in scroll-lock-mode?
* Leo (2007-06-07) writes: - Ralf Angeli (2007-06-07) wrote:- * Leo (2007-06-07) writes: I put (scroll-lock-mode t) in ~/.emacs, but it is still disabled after restart emacs. Is this a bug in scroll-lock-mode? Scroll Lock mode is a buffer-local minor mode, so your command will not enable it globally. You can enable it via a hook. For example, if you wanted the mode to be activated when browsing info files, you could do this with something like (add-hook 'Info-mode-hook 'scroll-lock-mode). But looks like the doc string is not clear about this. Perhaps somebody can install the following change then. 2007-06-07 Ralf Angeli [EMAIL PROTECTED] * scroll-lock.el (scroll-lock-mode): Doc fix. --- scroll-lock.el 24 Jan 2007 19:57:54 +0100 1.5 +++ scroll-lock.el 07 Jun 2007 11:57:17 +0200 @@ -50,7 +50,7 @@ ;;;###autoload (define-minor-mode scroll-lock-mode - Minor mode for pager-like scrolling. + Buffer-local minor mode for pager-like scrolling. Keys which normally move point by line or paragraph will scroll the buffer by the respective amount of lines instead and point will be kept vertically fixed relative to window boundaries -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: BUG in scroll-lock-mode?
* Leo (2007-06-07) writes: - Ralf Angeli (2007-06-07) wrote:- Scroll Lock mode is a buffer-local minor mode, so your command will not enable it globally. You can enable it via a hook. For example, if you wanted the mode to be activated when browsing info files, you could do this with something like (add-hook 'Info-mode-hook 'scroll-lock-mode). Is it a good idea to make it a global minor mode? Personally I would not find this useful, since I usually want to use scroll locking only in specific buffers or a specific class of buffers, e.g. in buffers with Info mode or View mode. If people think a global toggle would be useful, one could add something like `global-scroll-lock-mode'. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: BUG in scroll-lock-mode?
* Juri Linkov (2007-06-07) writes: I put (scroll-lock-mode t) in ~/.emacs, but it is still disabled after restart emacs. Is this a bug in scroll-lock-mode? Scroll Lock mode is a buffer-local minor mode, so your command will not enable it globally. You can enable it via a hook. For example, if you wanted the mode to be activated when browsing info files, you could do this with something like (add-hook 'Info-mode-hook 'scroll-lock-mode). Why scroll-lock-mode is not bound to scroll or Scroll_Lock key? This would be much more useful than making a global mode. ,[ http://mid.gmane.org/E1Dnaf1-0007am-Cg%40neutrino.iwi.uni-sb.de ] | An open issue is the key binding for toggling the mode. If the minor | mode should be able to be activated in some major modes but not in | others, it doesn't make much sense to bind this to the Scroll Lock key | which in my understanding means to enable or disable it globally (not | just for Emacs but for other applications aware of it as well). ` Personally I have the following in my init file: (let ((key (if (eq window-system 'w32) scroll Scroll_Lock))) (unless (lookup-key (current-global-map) (read-kbd-macro key)) (define-key (current-global-map) (read-kbd-macro key) 'scroll-lock-mode))) -- Ralf ___ 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 (2007-05-06) writes: I wonder if the problem is in x_make_frame_visible in w32term.c, because it explicitly assumes the taskbar is at the bottom. /* Adjust vertical window position in order to avoid being covered by a task bar placed at the bottom of the desktop. */ That code is not related to window maximization but to window placement in the unmaximized state. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tar-untar-buffer fails on Emacs pretest tar ball
* Chong Yidong (2007-03-03) writes: Ralf Angeli [EMAIL PROTECTED] writes: Trying to untar an Emacs pretest tar ball (22.0.94) with `tar-untar-buffer' results in the following backtrace: I checked in a fix for this. I can confirm that it is working now. Thanks very much! -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
tar-untar-buffer fails on Emacs pretest tar ball
Trying to untar an Emacs pretest tar ball (22.0.94) with `tar-untar-buffer' results in the following backtrace: Debugger entered--Lisp error: (error Invalid search bound (wrong side of point)) re-search-forward([ \n]\\([^[ \n]*\\)[]*Local Variables:[ ]*\\([^ \n]*\\)[ \n] 342875 t) find-auto-coding(/home/angeli/test/emacs-22.0.94/AUTHORS 89643) select-safe-coding-system(253232 342875 no-conversion nil /home/angeli/test/emacs-22.0.94/AUTHORS) write-region(253232 342875 emacs-22.0.94/AUTHORS) tar-untar-buffer() call-interactively(tar-untar-buffer) execute-extended-command(nil) call-interactively(execute-extended-command) When looking at the tar buffer after the error happened point is located at a new page character (^L). The bug makes it impossible to install a package containing such characters in certain files with install.el which uses `tar-untar-buffer' for the extraction of files from a package. In GNU Emacs 22.0.95.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-03-03 on neutrino X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk'' 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_US locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Tar 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: C-x C-f e m tab . tab return y M-x t a r - u n t a r tab return M-x r e p o r t - e m tab return Recent messages: File emacs-22.0.94.tar.gz is large (35MB), really open? (y or n) Loading jka-compr...done uncompressing emacs-22.0.94.tar.gz...done Loading tar-mode...done Parsing tar file...done Extracting emacs-22.0.94/AUTHORS find-auto-coding: Invalid search bound (wrong side of point) 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: No refresh of buffer before popup-menu
* Jason Rumney (2007-02-23) writes: 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. That also seems to have fixed the crash I reported in the thread titled Segfault and font corruption in menu under Windows. The string corruption is still present, however. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Emacs build does not finish
After doing an update of the sources from CVS today, `make bootstrap' does not finish anymore. The last command in the terminal is EMACSLOADPATH=/usr/src/emacs/leim/../lisp LC_ALL=C ../src/emacs -batch --no-init -file --no-site-file --multibyte -f batch-byte-compile quail/ZIRANMA.el which seems to go on forever (which was about a quarter of an hour until I aborted the build). -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs build does not finish
* Romain Francoise (2007-01-24) writes: Ralf Angeli [EMAIL PROTECTED] writes: After doing an update of the sources from CVS today, `make bootstrap' does not finish anymore. It does finish but it's *very* slow; compiling this file now takes about 5 minutes on my computer where it took only a few seconds before... ja-dic.el takes a lot of time, too. Okay, I tried again and this time I was more patient. Yes, it finishes. So, thanks for the hint and sorry for the noise. The build process, however, now is really slow. Probably twice the time it took before. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Cursor bug
* Jason Rumney (2007-01-09) writes: 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 Which would require him to set up a build environment which is not really trivial on Windows. 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. The latest version available from ftp://alpha.gnu.org/gnu/auctex/ is based on a CVS check-out from 2007-01-07, was built on the same day and does not contain any patches. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Gnus,pgg,mml2015.el] Flash of raw encrypted article
* Reiner Steib (2007-01-01) writes: On Sun, Dec 31 2006, Ralf Angeli wrote: With the setting (setq mm-verify-option 'known) the raw article will be shown for a split second before the rendered one appears when an encrypted article like [EMAIL PROTECTED] (from emacs-devel) is to be displayed in Gnus (up-to-date No Gnus). [...] (emacs-pretest-bug is probably not the ideal list for this report, JFTR: The PGG code in No Gnus (development version) and Emacs CVS differ [1]. Unless this is reproducible with Gnus 5.11, we can disregard this report with regards to the Emacs release. Not if the bug indicates a problem with `sit-for'. I know, `sit-for' isn't called with the NODISP parameter set to t in `pgg-gpg-wait-for-completion', but as I wrote before, setting it doesn't make a difference. Using `sleep-for' instead of `sit-for' in `pgg-gpg-wait-for-completion', however, makes the bug go away. but my messages to ding seem to have gone to a black hole.) How did you send it (direct mail, posting through Gmane [2], posing through news.gnus.org)? I've sent one through Gmane and then tried to subscribe (I thought it might be a problem of moderation) by sending a message to ding-request. I haven't got an answer from ding-request. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[Gnus,pgg,mml2015.el] Flash of raw encrypted article
With the setting (setq mm-verify-option 'known) the raw article will be shown for a split second before the rendered one appears when an encrypted article like [EMAIL PROTECTED] (from emacs-devel) is to be displayed in Gnus (up-to-date No Gnus). I tried to debug the problem but got stuck in `mml2015-pgg-verify'. The function is called from `mml2015-verify'. At least in my case the raw article does not show up if I remove the call to `mml2015-pgg-verify' and just let it return `handle'. So my guess is that the problem is somewhere in `mml2015-pgg-verify' or a function called from there. (emacs-pretest-bug is probably not the ideal list for this report, but my messages to ding seem to have gone to a black hole.) In GNU Emacs 22.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2006-12-31 on neutrino X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk'' 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_US locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: encoded-kbd-mode: t show-paren-mode: t savehist-mode: t recentf-mode: t iswitchb-mode: t display-time-mode: t desktop-save-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 column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-b return h a n d l e ) C-b C-M-x C-x b g r return C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 1 return return g q C-x b return C-_ C-_ C-f C-M-x C-x b m m l tab M-x r e p o r t - e m a tab return Recent messages: Opening nntp server on news.gmane.org...done Fetching headers for nntp+news.gmane.org:gmane.emacs.gnus.general...done Scoring...done Generating summary...done No more unread articles No more unread newsgroups Undo! [2 times] mml2015-verify Auto-saving...done Loading emacsbug...done -- Ralf ___ 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
* Jason Rumney (2006-08-04) writes: Ralf Angeli wrote: IIUC the next step is to look at why get_menu_item_info puts an integer into dwItemData. It's a pointer. Oh, I see. I can't reproduce the problem, For convenience reasons I am checking this by loading a LaTeX file and opening the Preview menu (which has three menu entries in a bold font). But at least on my system I can produce the same result with the test case I provided. and the line numbers in your stack traces are slightly out from what I have in a clean CVS checkout. Here is the same procedure with a fresh checkout: (gdb) b w32fns.c:3583 Breakpoint 3 at 0x1135c1a: file w32fns.c, line 3583. (gdb) run Starting program: c:/Programme/Emacs/bin/emacs.exe -geometry 80x40+0+0 (gdb) c Continuing. [Switching to thread 2836.0xb8] Breakpoint 3, w32_wnd_proc (hwnd=0xc0384, msg=43, wParam=0, lParam=552399328) at w32fns.c:3583 3583 old_font = SelectObject (hdc, menu_font); (gdb) p title $1 = 0x8609d0 G (gdb) delete Delete all breakpoints? (y or n) y (gdb) watch *(char *)0x8609d0 Hardware watchpoint 4: *(char *) 8784336 (gdb) c Continuing. Hardware watchpoint 4: *(char *) 8784336 Old value = 71 'G' New value = -18 '\356' 0x7c913105 in _libkernel32_a_iname () (gdb) bt #0 0x7c913105 in _libkernel32_a_iname () #1 0x0084 in ?? () #2 0x7c97e062 in _libkernel32_a_iname () #3 0x7c95a5d0 in _libkernel32_a_iname () #4 0x7c9368ad in _libkernel32_a_iname () #5 0x0112c345 in w32_free_submenu_strings (menu=0x4903ed) at w32menu.c:2509 #6 0x0112c31c in w32_free_submenu_strings (menu=0x1c039d) at w32menu.c:2514 #7 0x0112c38c in w32_free_menu_strings (hwnd=0xc0384) at w32menu.c:2532 #8 0x01135ead in w32_wnd_proc (hwnd=0xc0384, msg=275, wParam=3, lParam=0) at w32fns.c:3438 #9 0x77d18734 in _libkernel32_a_iname () #10 0x77d18816 in _libkernel32_a_iname () #11 0x77d1c63f in _libkernel32_a_iname () #12 0x77d1e905 in _libkernel32_a_iname () #13 0x6d18160b in _libwinspool_a_iname () #14 0x77d18734 in _libkernel32_a_iname () #15 0x77d18816 in _libkernel32_a_iname () #16 0x77d189cd in _libkernel32_a_iname () #17 0x77d196c7 in _libkernel32_a_iname () #18 0x01134941 in w32_msg_pump (msg_buf=0x113) at w32fns.c:2607 #19 0x01136a90 in w32_msg_worker (dw=0) at w32fns.c:2732 #20 0x7c80b50b in _libkernel32_a_iname () (gdb) frame 5 #5 0x0112c345 in w32_free_submenu_strings (menu=0x4903ed) at w32menu.c:2509 2509 local_free (info.dwItemData); (gdb) p info.dwItemData $2 = 8784336 (gdb) xtype Lisp_Int (gdb) xint $3 = 1098042 (gdb) -- Ralf ___ 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
* Jason Rumney (2006-08-04) writes: Ralf Angeli [EMAIL PROTECTED] writes: Hm, a Google search regarding _libkernel32_a_iname revealed nothing really interesting. iname is used to denote an unknown function, in this case it is in libkernel32 (I assume this is mingw's name for the system library kernel32.dll, or a wrapper for it). Since the system libraries have their debug symbols stripped, this is expected. Look down the stack until you find a function name that is not iname. That will most likely be the line in Emacs where the failure is occuring. Okay here is what I got: (gdb) watch *(char *)0x860930 Hardware watchpoint 4: *(char *) 8784176 (gdb) c Continuing. Hardware watchpoint 4: *(char *) 8784176 Old value = 71 'G' New value = -18 '\356' 0x7c913105 in _libkernel32_a_iname () (gdb) bt #0 0x7c913105 in _libkernel32_a_iname () #1 0x0084 in ?? () #2 0x7c97e062 in _libkernel32_a_iname () #3 0x7c95a5d0 in _libkernel32_a_iname () #4 0x7c9368ad in _libkernel32_a_iname () #5 0x0112c26e in w32_free_submenu_strings (menu=0x5038d) at w32menu.c:2503 #6 0x0112c245 in w32_free_submenu_strings (menu=0xc0353) at w32menu.c:2508 #7 0x0112c2b5 in w32_free_menu_strings (hwnd=0x40286) at w32menu.c:2526 #8 0x01135e2c in w32_wnd_proc (hwnd=0x40286, msg=275, wParam=3, lParam=0) at w32fns.c:3423 #9 0x77d18734 in _libkernel32_a_iname () #10 0x77d18816 in _libkernel32_a_iname () #11 0x77d1c63f in _libkernel32_a_iname () #12 0x77d1e905 in _libkernel32_a_iname () #13 0x6d18160b in _libwinspool_a_iname () #14 0x77d18734 in _libkernel32_a_iname () #15 0x77d18816 in _libkernel32_a_iname () #16 0x77d189cd in _libkernel32_a_iname () #17 0x77d196c7 in _libkernel32_a_iname () #18 0x011348c0 in w32_msg_pump (msg_buf=0x113) at w32fns.c:2592 #19 0x01136a0f in w32_msg_worker (dw=0) at w32fns.c:2717 #20 0x7c80b50b in _libkernel32_a_iname () (gdb) frame 5 #5 0x0112c26e in w32_free_submenu_strings (menu=0x5038d) at w32menu.c:2503 2503 local_free (info.dwItemData); (gdb) p info.dwItemData $2 = 8784176 (gdb) xtype Lisp_Int (gdb) xint $3 = 1098022 (gdb) IIUC the next step is to look at why get_menu_item_info puts an integer into dwItemData. -- Ralf ___ 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 (2006-07-27) writes: We received a bug report on the AUCTeX list about a crash of Emacs under Windows. The report including a description on how to reproduce the crash can be found at URL:http://thread.gmane.org/gmane.emacs.auctex.general/1281/focus=1286. Here is a backtrace I could produce following the recipe: [...] Program received signal SIGSEGV, Segmentation fault. [Switching to thread 2984.0x834] 0x77c17fd4 in _libkernel32_a_iname () (gdb) backtrace #0 0x77c17fd4 in _libkernel32_a_iname () #1 0x20ecefa8 in ?? () #2 0x01134e94 in w32_wnd_proc (hwnd=0x45029e, msg=44, wParam=0, lParam=552399352) at w32fns.c:3513 Here is some more information: The segfault happens when calling /* Always draw title as if not selected. */ if (unicode_append_menu) ExtTextOutW (hdc, pDis-rcItem.left + GetSystemMetrics (SM_CXMENUCHECK), pDis-rcItem.top, ETO_OPAQUE, pDis-rcItem, (WCHAR *) title, wcslen ((WCHAR *) title), NULL); It seems that the value behind `title' is incorrect. In case the value is correct, examining the value in GDB with `p title' returns the first character of the string to be drawn, e.g. Breakpoint 1, w32_wnd_proc (hwnd=0x5002e0, msg=43, wParam=0, lParam=552399328) at w32fns.c:3571 (gdb) p *title $5 = 71 'G' (gdb) p title $6 = 0x85f988 G (gdb) When the crash happened, the value behind `title', however, looks like this (control characters replaced by strings): Program received signal SIGSEGV, Segmentation fault. 0x77c17fd4 in _libkernel32_a_iname () (gdb) frame 2 #2 0x01135bc9 in w32_wnd_proc (hwnd=0x5002e0, msg=43, wParam=0, lParam=552399328) at w32fns.c:3572 (gdb) p title $7 = 0x85c9a0 \356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376\356\376... -- Ralf ___ 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
* Eli Zaretskii (2006-08-03) writes: Put a watchpoint to watch *(char *)0x85f988, and see what code modifies it. Thanks for the hint. That's what I get when playing around with it a little bit (control characters replaced by strings again): Breakpoint 1, w32_wnd_proc (hwnd=0x101f0, msg=43, wParam=0, lParam=552399328) at w32fns.c:3571 (gdb) p title $1 = 0x860720 G (gdb) delete Delete all breakpoints? (y or n) y (gdb) watch *(char *)0x860720 Hardware watchpoint 2: *(char *) 8783648 (gdb) c Continuing. Hardware watchpoint 2: *(char *) 8783648 Old value = 71 'G' New value = -18 '\356' 0x7c913105 in _libkernel32_a_iname () (gdb) c Continuing. Hardware watchpoint 2: *(char *) 8783648 Old value = -18 '\356' New value = 0 '\0' 0x7c911231 in _libkernel32_a_iname () (gdb) c Continuing. Hardware watchpoint 2: *(char *) 8783648 Old value = 0 '\0' New value = -18 '\356' 0x7c913105 in _libkernel32_a_iname () (gdb) Hm, a Google search regarding _libkernel32_a_iname revealed nothing really interesting. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Same frame-positioning bug as before: negative top/left values on Windows
* Kim F. Storm (2006-07-21) writes: Ralf Angeli [EMAIL PROTECTED] writes: + left = w32_get_arg (Qnil, Qleft, left, Left, RES_TYPE_NUMBER); + if (!EQ (left, Qunbound)) +CHECK_NUMBER (left); One gripe I have with it is that the CHECK_NUMBER macro does not seem to work. If I use a string for the `top' or `left' property no error is thrown. Does anybody know why? You pass RES_TYPE_NUMBER to w32_get_arg, which is evaluated like this: case RES_TYPE_NUMBER: return make_number (atoi (SDATA (tem))); so if the value is not a number, atoi returns zero. Oh, I see. Thanks for the info. Then I'll have to use RES_TYPE_STRING if I wanted to catch erroneous values. It's probably not worth the trouble anyway because a fallback of 0 is not too bad. The reason I even got the idea of using CHECK_NUMER is code in x_icon (in w32fns.c), which also uses w32_get_arg with RES_TYPE_NUMBER and checks with CHECK_NUMBER afterwards. I guess this is a useless check either. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Same frame-positioning bug as before: negative top/left values on Windows
* Eli Zaretskii (2006-07-22) writes: Thanks, I installed its modified version, given the discussions after you posted the change. Thanks! One additional thought regarding CHECK_NUMER: x_get_arg returning 0 for an invalid value if RES_TYPE_NUMBER is used, might just be an implementation detail. At least I don't see that behavior documented anywhere. That means CHECK_NUMBER could be useful once the implementation of x_get_arg changes. But as this seems unlikely, the question of using it or not using it is probably not very important. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Same frame-positioning bug as before: negative top/left values on Windows
* Ralf Angeli (2006-07-20) writes:
* Drew Adams (2006-07-19) writes:
This problem occurs even for emacs -Q: the initial frame is about 5cm from
the left edge and about 6cm from the top edge of the display. Before, it was
flush with both top and left display edges.
Frame positioning is now left to Windows unless you specified values
for `top' and `left' in `initial-frame-alist' or
`default-frame-alist'. The latter does not seem to be respected after
the first frame was created. I'll take a look at what the culprit is
unless someone beats me to it.
The following patch fixes this bug:
--- w32fns.c 05 Jul 2006 21:10:18 +0200 1.271
+++ w32fns.c 21 Jul 2006 22:35:40 +0200
@@ -2066,6 +2066,7 @@
{
HWND hwnd;
RECT rect;
+ Lisp_Object top, left;
rect.left = rect.top = 0;
rect.right = FRAME_PIXEL_WIDTH (f);
@@ -2081,12 +2082,20 @@
w32_init_class (hinst);
}
+ left = w32_get_arg (Qnil, Qleft, left, Left, RES_TYPE_NUMBER);
+ if (!EQ (left, Qunbound))
+CHECK_NUMBER (left);
+
+ top = w32_get_arg (Qnil, Qtop, top, Top, RES_TYPE_NUMBER);
+ if (!EQ (top, Qunbound))
+CHECK_NUMBER (top);
+
FRAME_W32_WINDOW (f) = hwnd
= CreateWindow (EMACS_CLASS,
f-namebuf,
f-output_data.w32-dwStyle | WS_CLIPCHILDREN,
- CW_USEDEFAULT,
- SW_SHOW,
+ EQ (left, Qunbound) ? CW_USEDEFAULT : XINT (left),
+ EQ (top, Qunbound) ? CW_USEDEFAULT : XINT (top),
rect.right - rect.left,
rect.bottom - rect.top,
NULL,
One gripe I have with it is that the CHECK_NUMBER macro does not seem
to work. If I use a string for the `top' or `left' property no error
is thrown. Does anybody know why?
I can provide a change log entry once this is settled.
Anyway, the patch fixes frame positioning if `top' or `left' was
specified in `default-frame-alist'. If the first frame should be
created at the correct position right away, the registry keys
`Emacs.Top' and `Emacs.Left' have to be used instead.
--
Ralf
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Same frame-positioning bug as before: negative top/left values on Windows
* Drew Adams (2006-07-19) writes: This problem occurs even for emacs -Q: the initial frame is about 5cm from the left edge and about 6cm from the top edge of the display. Before, it was flush with both top and left display edges. Frame positioning is now left to Windows unless you specified values for `top' and `left' in `initial-frame-alist' or `default-frame-alist'. The latter does not seem to be respected after the first frame was created. I'll take a look at what the culprit is unless someone beats me to it. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: startup frame position
* Eli Zaretskii (2006-06-23) writes:
One possible way of solving this would be to call SystemParametersInfo
with SPI_GETWORKAREA arg in x_make_frame_visible, and fix f-left_pos
and f-top_pos we pass to x_set_offset, if their values are inside the
task bar. I think this should be done for all frames, not just the
initial frame.
The attached patch implements window position adjustment in
`x_make_frame_visible'. Note that only the case of vertical
adjustment in case the lower part of the frame is covered by the task
bar. I haven't seen problems with frame positioning if the task bar
is located at the top or the sides of the desktop.
I am not sure if `x_make_frame_visible' is the right place for this
adjustment. Personally I'd rather do this in `w32_createwindow' right
after the call to `CreateWindow'. That way `ShowWindow' will already
get a frame with its final coordinates.
Besides, the patch does not address the problem of window placement
with a changed default face mentioned before. If you customize the
default face by giving it a smaller font size and create several new
frames with `C-x 5 2' those will get placed in a cascading manner
until the bottom of the frame relating to the original font size (not
the one in effect) hits the bottom of the usable desktop area.
A minor catch in this is that user-defined frame parameters will be
only approximately obeyed (if the specified position invades the
taskbar). I don't know if this is bad.
We could check if a `top' frame parameter is defined and don't do the
position adjustment if it is. IIUC `w32_get_arg' would be suitable to
check such a parameter. Unfortunately it is not available in
w32term.c (and no w32fns.h declaring it which could be sourced in
w32term.c). That would be another reason to do the adjustment in
`w32_createwindow'.
--
Ralf
Index: w32fns.c
===
RCS file: /sources/emacs/emacs/src/w32fns.c,v
retrieving revision 1.270
diff -u -r1.270 w32fns.c
--- w32fns.c 2 Jun 2006 21:20:44 - 1.270
+++ w32fns.c 25 Jun 2006 13:04:05 -
@@ -2085,8 +2085,8 @@
= CreateWindow (EMACS_CLASS,
f-namebuf,
f-output_data.w32-dwStyle | WS_CLIPCHILDREN,
- f-left_pos,
- f-top_pos,
+ CW_USEDEFAULT,
+ SW_SHOW,
rect.right - rect.left,
rect.bottom - rect.top,
NULL,
@@ -2107,6 +2107,11 @@
/* Do this to discard the default setting specified by our parent. */
ShowWindow (hwnd, SW_HIDE);
+
+ /* Update frame positions. */
+ GetWindowRect (hwnd, rect);
+ f-left_pos = rect.left;
+ f-top_pos = rect.top;
}
}
Index: w32term.c
===
RCS file: /sources/emacs/emacs/src/w32term.c,v
retrieving revision 1.246
diff -u -r1.246 w32term.c
--- w32term.c 5 Jun 2006 21:20:59 - 1.246
+++ w32term.c 25 Jun 2006 13:04:13 -
@@ -5665,7 +5665,22 @@
before the window gets really visible. */
if (! FRAME_ICONIFIED_P (f)
! f-output_data.w32-asked_for_visible)
- x_set_offset (f, f-left_pos, f-top_pos, 0);
+ {
+ RECT workarea_rect;
+ RECT window_rect;
+
+ /* Adjust vertical window position in order to avoid being
+ covered by a task bar placed at the bottom of the desktop. */
+ SystemParametersInfo(SPI_GETWORKAREA, 0, workarea_rect, 0);
+ GetWindowRect(FRAME_W32_WINDOW(f), window_rect);
+ if (window_rect.bottom workarea_rect.bottom
+ window_rect.top workarea_rect.top)
+ f-top_pos = max (window_rect.top
+ - window_rect.bottom + workarea_rect.bottom,
+ workarea_rect.top);
+
+ x_set_offset (f, f-left_pos, f-top_pos, 0);
+ }
f-output_data.w32-asked_for_visible = 1;
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: startup frame position
* Eli Zaretskii (2006-06-26) writes: From: Ralf Angeli [EMAIL PROTECTED] Frankly, I cannot answer this question with knowledge about how frame placement works in Windows. There simply wasn't any problem when I tried it. Are you saying that, with the task bar on the left, the original code (before the patch you sent) would place the Emacs frame to the right of the task bar? No, I was talking only about the behavior with the patch applied. Without the patch the frame would be placed below a left-aligned task bar. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: startup frame position
* Eli Zaretskii (2006-06-23) writes: From: Ralf Angeli [EMAIL PROTECTED] Date: Mon, 12 Jun 2006 23:25:46 +0200 It turned out that `x_set_offset' was called with `f-left_pos' and `f-top_pos' as arguments which have to be updated after the frame was created. The following patch works for me: [...] Unfortunately, this patch has an unpleasant effect on my system: emacs -q comes up with the mode line and the minibuffer obscured by the task bar Yes, I noticed this too (and mentioned it when sending the patch). I was trying various things debugging the problem but haven't succeeded in solving it. With the patch applied you can see another interesting effect. If you change the default face to a smaller font size and create new frames with `C-x 5 2', those will come up with a size matching the default font size before customization and instantly shrink to a size matching the new font size. This can be circumvented by using SW_HIDE instead of SW_SHOW in the ShowWindow call (as it is being done without the patch) but you will still get wrong window placements because new frames are also still created with the wrong size (with SW_HIDE one just does not see it). I am currently out of wits with respect to fixing the patch and getting reasonable placement of newly created frames. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: startup frame position
* Eli Zaretskii (2006-06-23) writes: Could you perhaps find time to try this approach? I should be able to invest some time this weekend. I'll post the outcome of this investment. Thanks for the hints. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: startup frame position
* Eli Zaretskii (2006-06-12) writes: From: Ralf Angeli [EMAIL PROTECTED] I suspect that `x_set_offset' is called somewhere with values of 0 for both offsets Correct. but I could not find the respective call. You could find that call with a debugger, by setting a breakpoint in x_set_offset. It turned out that `x_set_offset' was called with `f-left_pos' and `f-top_pos' as arguments which have to be updated after the frame was created. The following patch works for me: Index: w32fns.c === RCS file: /sources/emacs/emacs/src/w32fns.c,v retrieving revision 1.270 diff -c -r1.270 w32fns.c --- w32fns.c 2 Jun 2006 21:20:44 - 1.270 +++ w32fns.c 12 Jun 2006 21:17:34 - @@ -2085,8 +2085,8 @@ = CreateWindow (EMACS_CLASS, f-namebuf, f-output_data.w32-dwStyle | WS_CLIPCHILDREN, - f-left_pos, - f-top_pos, + CW_USEDEFAULT, + SW_SHOW, rect.right - rect.left, rect.bottom - rect.top, NULL, @@ -2106,7 +2106,12 @@ DragAcceptFiles (hwnd, TRUE); /* Do this to discard the default setting specified by our parent. */ - ShowWindow (hwnd, SW_HIDE); + ShowWindow (hwnd, SW_SHOW); + + /* Update frame positions. */ + GetWindowRect (hwnd, rect); + f-left_pos = rect.left; + f-top_pos = rect.top; } } An issue left is that the bottom of the frame may be covered by the task bar if it is placed too low on the screen. Does anybody know why `CreateWindow' or the other functions involved do not take care of this? -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: startup frame position
* Stephan Hennig (2006-05-24) writes: Emacs' frame appears in the top left corner of the screen. On Windows OS this is ok when the OS's symbol panel (Symbolleiste) is located at the bottom of the screen. If the symbol panel is located at the top of the screen part of Emacs' frame -- the title panel (Titelleiste) -- gets hidden behind the symbol panel so that you can't grab and move the frame on the desktop. FWIW, I find it at least annoying that Emacs under Windows always creates frames in the top left corner. I managed to let Windows position new frames by modifying the calls to `CreateWindow' and `ShowWindow' in `w32_createwindow'. For the `CreateWindow' call I used `CW_USEDEFAULT' instead of `f-left_pos' as third argument and `SW_SHOW' instead of `f-top_pos' as fourth argument. For the `ShowWindow' call I used `SW_SHOW' instead of `SW_HIDE' as second argument. Unfortunately newly created frames don't stay at the position they are created at but instantly move to the top left corner. I could not find out where this happens. I suspect that `x_set_offset' is called somewhere with values of 0 for both offsets, but I could not find the respective call. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: redisplay-dont-pause is not mentioned in the Emacs manual
* Eli Zaretskii (2006-06-05) writes: From: Drew Adams [EMAIL PROTECTED] Date: Sun, 4 Jun 2006 17:34:00 -0700 I'm not certain it should be, as I'm not clear on how this user option works. I don't think it should be: it's not for users. It's for Lisp programs that need special attention from the display engine. Really? I have it enabled for all my Emacs installations because I cannot stand the way buffer contents are updated during scrolling if it is not. I'd appreciate it to become a defcustom. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: redisplay-dont-pause is not mentioned in the Emacs manual
* Kim F. Storm (2006-06-05) writes: Eli Zaretskii [EMAIL PROTECTED] writes: From: Ralf Angeli [EMAIL PROTECTED] I have [redisplay-dont-pause] enabled for all my Emacs installations because I cannot stand the way buffer contents are updated during scrolling if it is not. I think that's a bug that should be reported and fixed. How? Normal redisplay is restarted whenever it is interrupted by user input. For example, pressing and holding the down-arrow key will be randomly jumpy -- depending on the speed of the computer vs. the key repeat rate of the keyboard. One should probably add that the effect is most apparent with (setq scroll-conservatively 1000) on a slow computer. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [tex-mode.el] Subscript in math not fully matched
* Stefan Monnier (2006-04-17) writes: Matching multiple characters of a complemented character alternative is really more efficient than a call to stuff like `scan-lists'? Okay there is some additional code involved as well, but anyway. Maybe you're right. * textmodes/tex-mode.el (tex-font-lock-match-suscript): New function. (tex-font-lock-keywords-3): Use it. Thanks, installed. Thanks. Meanwhile I saw that there is a misplaced paren in the patch. The following change should fix this. Sorry for the inconvenience. 2006-04-17 Ralf Angeli [EMAIL PROTECTED] * textmodes/tex-mode.el (tex-font-lock-match-suscript): Fix misplaced parenthesis. --- tex-mode.el 17 Apr 2006 12:05:39 - 1.181 +++ tex-mode.el 17 Apr 2006 13:33:34 - @@ -604,8 +604,8 @@ (narrow-to-region (point-min) limit) (condition-case nil (scan-lists (point) 1 1) (error nil) (store-match-data (if end - (list (match-beginning 0) end beg end)) - (list beg beg beg beg + (list (match-beginning 0) end beg end) + (list beg beg beg beg) t)) (defconst tex-font-lock-keywords-3 -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: void-variable c-subword-mode with debug-on-error
* Richard Stallman (2006-04-10) writes: emacs -Q -f toggle-debug-on-error test.c the following error occurs: Debugger entered--Lisp error: (void-variable c-subword-mode) It did not happen for me on GNU/Linux. (I fetched the sources today and rebuilt.) I just updated the sources, did make maintainer-clean ./configure --with-gtk make bootstrap and I am still getting the error. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Wrong type argument: arrayp, nil with LANG=C under Windows
* Eli Zaretskii (2006-04-11) writes: From: Ralf Angeli [EMAIL PROTECTED] Date: Mon, 10 Apr 2006 23:07:00 +0200 Thanks, I'll do this as soon as I will have access to a better connection again. (Or find out why cvs sends half of the repository to the server during an update.) Is it possible that the DST became in effect in your timezone since the last cvs up? Yes. If so, the problem is that, with some ports of the CVS client to Windows, the time stamps are different from what is recorded in CVS/Entries, and the server requests that the client send every single file upstream. But this should happen only once after the clock change, and again when DST is reset. With the repository in question cvs has always been sending a lot of stuff to the server during cvs up. Maybe it became worse when updating after the DST change, I don't know. I'll check what happens now as soon as I'll find the time. At least cvs status tells me that some sample files I've looked at are up-to-date. Thanks for your suggestions. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Wrong type argument: arrayp, nil with LANG=C under Windows
* Eli Zaretskii (2006-04-11) writes: From: Ralf Angeli [EMAIL PROTECTED] Date: Mon, 10 Apr 2006 23:07:00 +0200 The question is, is this a bug or a feature? That is, is it right for Emacs on MS-Windows to create Unix-style text files under LANG=C? I tend to think it's a bug, but I'm not sure. Isn't that an academic question? Are there people running Emacs intentionally under LANG=C and expecting Windows-style line endings? I don't think it's academic: you yourself found one example of running Emacs under LANG=C, albeit non-interactively. Suppose Emacs needed to create a file during that non-interactive session---is it okay for that file to be in Unix text format? I know that I'd be surprised to learn about such behavior. Taking the context of the particular example we have into account I wouldn't be surprised. All the AUCTeX files have Unix-style line endings. So I would not be surprised if a file created during the setup process had such line endings as well. In the end, LANG=C doesn't really have a meaning under Windows, does it? -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Wrong type argument: arrayp, nil with LANG=C under Windows
* Stefan Monnier (2006-04-11) writes: now as soon as I'll find the time. At least cvs status tells me that some sample files I've looked at are up-to-date. `cvs status' checks the actual contents of the file (sending the local file to the server, if needed), so it's not a good predictor for whether or not the file will be sent to the server during `cvs update'. Hm, is there a way to find out for a user at all? -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Wrong type argument: arrayp, nil with LANG=C under Windows
* Eli Zaretskii (2006-04-10) writes: From: Ralf Angeli [EMAIL PROTECTED] Date: Sun, 09 Apr 2006 13:32:35 +0200 Trying to start Emacs from an MSYS shell with the command line LANG=C drive:/path/to/emacs -Q results in Wrong type argument: arrayp, nil Thanks, I think I fixed this; please try again. Thanks, I'll do this as soon as I will have access to a better connection again. (Or find out why cvs sends half of the repository to the server during an update.) However, the behavior of Emacs on non-Posix platforms under LANG=C raises a subtle issue. Right now, when LANG=C (or Posix), set-locale-environment sets up things so that the default buffer-file-coding-system is reset to nil, and that causes Emacs to create files with Unix-style EOL conversion. This happens because the C language is mapped to ASCII, which specifies no encoding. Thus, set-language-environment resets the default coding systems to nil, and leaves it at that. Then the code which takes care of copying the EOL conversion from previous defaults doesn't do its thing. The question is, is this a bug or a feature? That is, is it right for Emacs on MS-Windows to create Unix-style text files under LANG=C? I tend to think it's a bug, but I'm not sure. Isn't that an academic question? Are there people running Emacs intentionally under LANG=C and expecting Windows-style line endings? -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Bug-AUCTeX] 11.82; flyspell-mode mouse-2 yanks as well
The following bug report originally was sent to the AUCTeX bug list.
I can sort of reproduce this with a Windows build of 2006-03-09 in
Text mode, so this is rather an Emacs issue than one of AUCTeX. I am
writing sort of because I cannot reproduce it reliably. The yank
does not happen every time when trying to correct a word.
Unfortunately I cannot check a newer build because I don't have easy
access to a broad-band connection and doing a cvs up over a modem
connection in my local repository for the Windows build takes forever
(I interrupted the update after about 50 minutes).
* Alun Pope (2006-04-06) writes:
Here is a short example file, which also explains the problem. This seems to
have to do with the
beta-version of Emacs I got for using preview with auctex. So it
seems to be about the auctex-emacs interaction which is why i have
sent it to the list.
%---example
\documentclass{article}
\begin{document}
Turn flyspell-mode on.
Then delete some stuff. Deleted text is SPURIOUS JUNK. (Deleted by
mouse-highlighting and delete key.)
Now make a spelling mistake: false.
SPURIOUS JUNK
The sequence was false was spelled flase, mouse-2 to correct, select
correct text then left-click. Then the correction is made but the extra
text SPURIOUS JUNK appears two lines further on, presumably because it
is being yanked by the mouse-2, in addition to the correct behaviour
(flyspell-mode's correct-at-point). If there is text on the line
SPURIOUS JUNK is appended.
\end{document}
%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:
%end example
Emacs : GNU Emacs 22.0.50.1 (i386-mingw-nt5.0.2195)
of 2006-01-29 on NEUTRINO
Package: 11.82
current state:
==
(setq
AUCTeX-date 2005-12-17
window-system 'w32
LaTeX-version 2e
TeX-style-path '(style auto c:/MyLatexDocs/BibFiles/style
c:/MyLatexDocs/BibFiles/auto
c:/emacs/Emacs/site-lisp/auctex/style ../var/auctex)
TeX-auto-save t
TeX-parse-self t
TeX-master h:/SGI/SGI - Premium Principles/PremiumPricing80to85
TeX-command-list '((View pdf acrord32.exe %s.pdf TeX-run-command
nil t)
(All pdf texify --pdf %s.tex TeX-run-command
nil t)
(Clean
del %s.log *.aux %s.out %s.exa %s.ilg %s.idx
%s.ind %s.lof %s.lot %s.toc %s.bbl %s.blg %s.dvi %s.ps %s.2.ps
%s.pdf TeX-run-command nil t)
(All texify --tex-opt=--src %s.tex
TeX-run-command nil
t)
(SmallGhostview gsview32.exe %s-2.ps
TeX-run-command
nil t)
(HalfSize psnup -2 %f %s-2.ps TeX-run-command
nil t)
(TeX %(PDF)%(tex) %S%(PDFout) \%(mode)\\input
%t\
TeX-run-TeX nil
(plain-tex-mode ams-tex-mode texinfo-mode) :help
Run plain TeX)
(LaTeX %l \%(mode)\\input{%t}\ TeX-run-TeX
nil
(latex-mode doctex-mode) :help Run LaTeX)
(Makeinfo makeinfo %t TeX-run-compile nil
(texinfo-mode) :help Run Makeinfo with Info
output)
(Makeinfo HTML makeinfo --html %t
TeX-run-compile nil
(texinfo-mode) :help Run Makeinfo with HTML
output)
(AmSTeX %(PDF)amstex %S%(PDFout)
\%(mode)\\input %t\
TeX-run-TeX nil (ams-tex-mode) :help Run
AMSTeX)
(ConTeXt texexec --once --texutil
%(execopts)%t
TeX-run-TeX nil (context-mode) :help Run ConTeXt
once)
(ConTeXt Full texexec %(execopts)%t
TeX-run-TeX nil
(context-mode) :help Run ConTeXt until
completion)
(ConTeXt Clean texutil --purgeall
TeX-run-interactive
nil (context-mode) :help Clean temporary ConTeXt
files)
(BibTeX bibtex %s TeX-run-BibTeX nil t :help
Run BibTeX)
(View %V TeX-run-discard t t :help Run
Viewer)
(Print %p TeX-run-command t t :help Print the
file)
(Queue %q TeX-run-background nil t :help
View the printer queue :visible
TeX-queue-command)
(File %(o?)dvips %d -o %f TeX-run-command t t
:help
Generate PostScript file)
(Index makeindex %s TeX-run-command nil t
:help
Create index file)
(Check lacheck %s TeX-run-compile nil
(latex-mode)
:help Check LaTeX file for correctness)
(Spell ignored TeX-run-ispell-on-document
nil t
:help Spell-check the document)
(Other TeX-run-command t t :help
Run an arbitrary command)
)
)
-
Dr Alun Pope
Group Credit
St.George Bank
Level 9
182 George St
Sydney NSW 2000
(T): 02 9236 1442
(F): 02 9236 1570
**
* IMPORTANT INFORMATION*
This document should be read only by those persons to whom it is
addressed and its content is not intended for use by any other
persons. If you have received this message in error, please notify
us immediately. Please also destroy and delete the message from
your computer. Any unauthorised form of reproduction of this message
Re: [Bug-AUCTeX] 11.82; flyspell-mode mouse-2 yanks as well
* Eli Zaretskii (2006-04-08) writes: From: Ralf Angeli [EMAIL PROTECTED] I can sort of reproduce this with a Windows build of 2006-03-09 [...] This bug, which was indeed specific to MS-Windows, was fixed on 2006-03-11 Argh, sooo close. (c: -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
void-variable c-subword-mode with debug-on-error
When starting Emacs with emacs -Q -f toggle-debug-on-error test.c the following error occurs: Debugger entered--Lisp error: (void-variable c-subword-mode) Ater quitting the debugger with `q' the error can be provoked as well by clicking with the mouse on a menu. (That's in fact the way I noticed this at all.) In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.8.16) of 2006-04-08 on neutrino X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--with-gtk'' 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_US locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: C/l Minor modes in effect: tooltip-mode: t auto-compression-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 line-number-mode: t abbrev-mode: t Recent input: p C-p C-SPC C-n M-w q M-x r e p o r t - m backspace e m tab return Recent messages: (emacs -Q -f toggle-debug-on-error test.c) For information about the GNU Project and its goals, type C-h C-p. Debug on Error enabled (New file) Loading cc-mode...done Loading debug...done Entering debugger... Mark set Back to top level. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Saving safe local variables garbles 8-bit characters in .emacs file
Under certain circumstances saving safe local variables permanently, i.e. answering with `!' to the respective question may garble 8-bit characters in a .emacs file. For this to happen the .emacs file has to contain UTF-8 characters and has to be saved as UTF-8. In addition Emacs has to be started in a directory with a .emacs.desktop file which has to load a LaTeX file containing 8-bit characters like umlauts, i.e. a file with a Latin-1 coding system. In addition the LaTeX file has to contain a Local Variables section with an unknown variable. As soon as Emacs is started this should pop up the question about how to deal with the variable and once you answer with `!' the .emacs file will be written. If you open the .emacs file after that 8-bit characters will be garbled (it looks like the UTF-8 characters got decomposed into their two separate bytes). Attached you can find the files I used for testing (.emacs.orig is the original .emacs file and .emacs.result the one after the safe variables stuff was written to it): (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(desktop-save (quote ask-if-exists)) '(desktop-save-mode t)) ;; → öäüß ;; Local Variables: ;; coding: utf-8 ;; End: (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(desktop-save (quote ask-if-exists)) '(desktop-save-mode t) '(safe-local-variable-values (quote ((foo) ;; â öäüà (custom-set-faces ;; custom-set-faces was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. ) ;; Local Variables: ;; coding: utf-8 ;; End: ;; -*- mode: emacs-lisp; coding: emacs-mule; -*- ;; -- ;; Desktop File for Emacs ;; -- ;; Created Mon Mar 6 17:20:28 2006 ;; Desktop file format version 206 ;; Emacs version 22.0.50.1 ;; Global section: (setq desktop-missing-file-warning nil) (setq tags-file-name nil) (setq tags-table-list nil) (setq search-ring nil) (setq regexp-search-ring nil) (setq register-alist nil) ;; Buffer section -- buffers listed in same order as in buffer list: (desktop-create-buffer 206 /home/angeli/scratch/desktop-test/test.tex test.tex 'latex-mode nil 1 '(nil nil) nil nil '((indent-tabs-mode) (buffer-file-coding-system . iso-latin-1-unix))) öäüß %%% Local Variables: %%% foo: nil %%% End: In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.8.13) of 2006-03-06 on neutrino X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--with-gtk'' 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_US locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: desktop-save-mode: t tooltip-mode: t auto-compression-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 line-number-mode: t Recent input: ! C-x C-f C-backspace C-backspace C-backspace . e m tab return M-x r e p o r tab return Recent messages: Loading regexp-opt...done Loading tex-mode...done Please type y, n, or !: Loading cus-edit... Loading easymenu...done Loading cus-edit...done Wrote /home/angeli/.emacs Desktop: 1 buffer restored. 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
Point stuck with adjacent overlays and invisibility spec
Evaluating the following form will create two adjacent overlays and point will be stuck at the top of the buffer (at least visually; there still is feedback, e.g. beeping, if you hold `C-n' long enough and hit the bottom of the buffer). (progn (pop-to-buffer (get-buffer-create *foo*)) (insert text\ntext\ntext\ntext\n) (goto-char (point-min)) (add-to-invisibility-spec '(outline . t)) (let ((ov (make-overlay (line-beginning-position 2) (line-beginning-position 3 (overlay-put ov 'display xxx)) (let ((ov (make-overlay (line-beginning-position 3) (line-end-position 3 (overlay-put ov 'invisible 'outline))) Such a constellation of overlays may occur if the folding feature of AUCTeX is used in conjunction with Outline Minor mode. Point does not get stuck in Emacs 21.4. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu item Options -- Save Options not working anymore
* Chong Yidong (2006-02-19) writes: The menu item Options -- Save Options does not work anymore. In order to check this, change one of the values in the Options menu, e.g. Blinking Cursor, click on the Save Options menu item and compare your init file with a backup you did before. In my case there are no changes written to the file. That was an oversight on my part, now fixed. Thanks. Confirmed. Thanks. I noticed, however, that the now-working Save Option saves some options that aren't really changed, like cua-mode and display-battery-mode. Apparently those are defined by define-minor-mode, so the mode variables don't have standard values, so Custom can't tell if they've been changed. ISTR that this was the old behavior of Save Options, but maybe it should be fixed somehow. I think so, too. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
C-h i fails after untabification of info/dir
The latest (Jan 27th) changes to info/dir, i.e. its untabification lead to the error byte-code: No such node or anchor: top when typing C-h i. That's because in `Info-find-node-2' the regexp \\(Node:\\|Ref:\\) *\\(top\\) *[, \n] used for finding the top node does not match anymore. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `make info' fails on cc-mode.texi with Texinfo 4.3
* Eli Zaretskii (2006-01-24) writes: From: Ralf Angeli [EMAIL PROTECTED] Date: Tue, 24 Jan 2006 16:10:30 +0100 The build process aborts if `make info' is called with Texinfo 4.3. [...] This version comes with current MSYS and does not know @headitem which was introduced with Texinfo 4.7. Texinfo 4.3 is 3 years old, which is very old. Why don't you install a Texinfo port from GnuWin32, they have v4.8 there. If it can be avoided ... (c; CC Mode says quite explicitly: @comment Note that Texinfo 4.7 (or later) is needed. So the answer to my (implicit) question about which versions of Texinfo the build process of Emacs should be compatible with is The version any Texinfo file in the distribution dictates.? If that's the case, no problem, I'll update my Texinfo installation. And I'll assume that a recent version of Texinfo can be compiled on any platform supported by Emacs. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Eli Zaretskii (2005-12-24) writes: I installed a change that should fix this problem for you. Can you sync with the repository and see if autoloads now work even with MSYS munging of the command line? Okay, now I tried again and creation of autoloads works. I checked this with MinGW's mingw32-make and MSYS' make. In both cases lisp/autoloads.el is created with only a small difference: $ diff -u build-with-mingw32-make/lisp/loaddefs.el build-with-make/lisp/loaddefs.el --- build-with-mingw32-make/lisp/loaddefs.el Wed Dec 28 20:40:22 2005 +++ build-with-make/lisp/loaddefs.el Wed Dec 28 21:29:32 2005 @@ -29910,7 +29910,7 @@ ;; url/url-vars.el url/vc-dav.el vc-hooks.el vcursor.el ;; version.el vms-patch.el vmsproc.el vt-control.el ;; vt100-led.el w32-fns.el w32-vars.el widget.el window.el -;; x-dnd.el) (17330 63506 99000)) +;; x-dnd.el) (17331 923 346000)) ;;;*** I don't know if this is significant, though. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Eli Zaretskii (2005-12-24) writes: I installed a change that should fix this problem for you. Can you sync with the repository and see if autoloads now work even with MSYS munging of the command line? Thanks for your efforts. I did a fresh checkout into a new directory, ran `configure ...' and while doing `mingw32-make bootstrap' the following error occurred: --8---cut here---start-8--- ./../bin/emacs.exe -batch --no-init-file --no-site-file --multibyte -l autoload \ --eval '(setq find-file-hook nil find-file-suppress-same-file-warnings t)' \ -f w32-batch-update-autoloads D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp/loaddefs.el . calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes url Wrong type argument: symbolp, 0 mingw32-make[1]: *** [autoloads] Error -1 mingw32-make[1]: Leaving directory `D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp' mingw32-make: *** [bootstrap-gmake] Error 2 --8---cut here---end---8--- In order to get a backtrace I set `debug-on-error' to t via the --eval statement above. That means I edited lisp/makefile.w32-in accordingly and ran `configure' again. Interestingly the error did not occur with this change. I tried this both in the directory where the make call failed with the original makefile.w32-in and in a directory which had not seen a make call before. Same results. Then I tried to run `mingw32-make bootstrap' in a freshly checked out and configured directory including the patch I proposed for lisp/makefile.w32-in and got the same error as above. Let-binding `debug-on-error' to t made the error vanish again. Now I don't really know where to look for the cause of the error. Anyway, in the directories where the build succeeded I did a `diff -u loaddefs.el ldefs-boot.el' which showed no differences between the files. The build I did about a week ago (with the patch I proposed) shows lots of differences between the files. So I am not really sure if loaddefs.el was generated correctly. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Eli Zaretskii (2005-12-18) writes: However, I cannot accept your patch as it stands. First, you missed the important WARNING in the comment just preceding the commands you wanted to patch, Oh great, then I'll probably have to do another upload to alpha.gnu.org. At least because of the usage of $(lisp). But I'll have to check how bad the consequences of missing autoloads are when relocating the Emacs installation directory. Thanks for the hint. and thus your modified command lines will break with make 3.81 (which is about to be released) and later, due to the incompatible change in its behavior regarding backslash-newline sequences. You mean the changes you described in the patch to make.texi in URL:http://lists.gnu.org/archive/html/help-make/2005-12/msg00031.html? In what way is this a problem. For example it does not make a difference if I pass emacs -eval (message \ \foo\) or emacs -eval (message \foo\) to the Bash 3.1.0 on my Debian system directly from a terminal. Is this relevant for Windows systems only? Does it mean that portable Makefile files all have to put their `emacs -eval ...' stuff into a single line? I am not sure about the conditions because the comment in lisp/makefile.w32-in mentions $(ARGQUOTE) and the patch in the email references above is mangled and reads [...]However, note that +backslash-newline sequences inside command-line arguments quoted with [EMAIL PROTECTED]'...'} are not removed by the shell.[...] Is there any reasonable chance that MSYS maintainers will fix this? Could you check with them, or maybe try their latest snapshot of ported Bash and see if the problem went away? I reported the issue back in July, see URL:http://thread.gmane.org/[EMAIL PROTECTED]. So they are aware of it but I don't know if this is fixed yet. I've been waiting for ages for a new release of MSYS. IIRC I checked a beta version of Bash 2.05 for MSYS back in July which did not solve the problem. Unfortunately I cannot find that beta on their download page anymore for testing. And the last beta of MSYS itself is from April 2004. If they don't intend to fix that any time soon, we will need to find a much simpler solution, one for which we could know with high probability that it will not break anything else. I'll give it a thought while you talk to the MSYS people. Well, I am. (c: -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Ralf Angeli (2005-07-08) writes: * Ralf Angeli (2005-07-07) writes: Using this for bootstrapping with `mingw32-make bootstrap' from a DOS prompt in the nt/ directory I get the following error: [...] Opening output file: invalid argument, d:/software/windows/unix/src/emacs/lisp/D;C:Programmemsys☺.0 oftwarewindowsunix rc←macslisploaddefs.el mingw32-make[1]: *** [autoloads] Error -1 mingw32-make[1]: Leaving directory `D:/software/windows/unix/src/emacs/lisp' mingw32-make: *** [bootstrap-gmake] Error 2 Okay, with the following patch (thanks, David, for reminding me of the technique) I can build Emacs under Windows using mingw32-make (MinGW 4.1.0) with MSYS' (1.0.10) sh.exe either present or not. 2005-07-08 Ralf Angeli [EMAIL PROTECTED] * makefile.w32-in (autoloads): Do not let autoload file name be mangled by the shell. I'd like to followup on this because until now nothing has happened and I've been bitten by this problem again, namely the build process failed to update the autoloads but instead of aborting with an error, it completed successfully. This happens with MSYS' `make' and `sh'. The patch mentioned above allowed me to build successfully, i.e. with updated autoloads, with `mingw32-make' and MSYS' `sh'. After the inclusion of MH-E a similar statement like the one for building the autoloads for Emacs in general is used for MH-E as well. That means the patch mentioned above does not work anymore. Below you can find an updated version. I'd very much appreciate it if this patch were applied or the build process be aborted if the autoloads cannot be updated. Index: makefile.w32-in === RCS file: /sources/emacs/emacs/lisp/makefile.w32-in,v retrieving revision 1.53 diff -u -r1.53 makefile.w32-in --- makefile.w32-in 17 Dec 2005 17:27:35 - 1.53 +++ makefile.w32-in 18 Dec 2005 15:47:21 - @@ -158,8 +158,14 @@ autoloads: $(lisp)/loaddefs.el doit @echo Directories: . $(WINS) $(emacs) -l autoload \ - --eval $(ARGQUOTE)(setq find-file-hook nil find-file-suppress-same-file-warnings t generated-autoload-file $(DQUOTE)$(lisp)/loaddefs.el$(DQUOTE))$(ARGQUOTE) \ - -f batch-update-autoloads . $(WINS) + --eval $(ARGQUOTE)(let ((find-file-hook nil) \ + (find-file-suppress-same-file-warnings t) \ + (generated-autoload-file \ + (expand-file-name (pop command-line-args-left \ + (mapcar (function update-directory-autoloads) \ +command-line-args-left) \ + (save-buffers-kill-emacs t))$(ARGQUOTE) \ + $(lisp)/loaddefs.el $(lisp) $(WINS) $(lisp)/subdirs.el: $(MAKE) $(MFLAGS) update-subdirs @@ -310,11 +316,16 @@ rm pre-mh-loaddefs.el-$(SHELLTYPE) $(EMACS) $(EMACSOPT) \ -l autoload \ - --eval (setq generate-autoload-cookie \;;;###mh-autoload\) \ - --eval (setq generated-autoload-file \$(lisp)/mh-e/mh-loaddefs.el\) \ - --eval (setq find-file-suppress-same-file-warnings t) \ - --eval (setq make-backup-files nil) \ - -f batch-update-autoloads $(lisp)/mh-e + --eval $(ARGQUOTE)(let ((find-file-hook nil) \ + (find-file-suppress-same-file-warnings t) \ + (make-backup-files nil) \ + (generate-autoload-cookie ;;;###mh-autoload) \ + (generated-autoload-file \ + (expand-file-name (pop command-line-args-left \ + (mapcar (function update-directory-autoloads) \ + command-line-args-left) \ + (save-buffers-kill-emacs t))$(ARGQUOTE) \ + $(lisp)/mh-e/mh-loaddefs.el $(lisp)/mh-e pre-mh-loaddefs.el-SH: echo ;;; mh-loaddefs.el --- automatically extracted autoloads $@ -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding problem with Euro sign
* Reiner Steib (2005-12-15) writes: On Wed, Dec 14 2005, Ralf Angeli wrote: would it be possible for Emacs to figure out the right coding system by itself in the case at hand? That means without me having to specify coding systems explicitely by means of preferred coding system options, coding cookies, or `C-x RET c' and similar. No. A program cannot distinguish iso-8859-1 from iso-8859-2 or -15 reliably. Same for windows-1252 vs. windows-1258 (0x80 in your example file). Heuristic approaches[1] might be possible, though. Well, although the iso-8859 encodings you mentioned cannot be distinguished, Emacs chooses one of them for files falling into the respective category. (I assume that Emacs looks at the language environment as a hint for making the final decision.) But for Windows codepages it seems that Emacs does not even try. So if this class of encodings could be distinguished from others like ISO, Mac, UTF, Whatsitsname encodings (that's the first question), could Emacs make a similar guess to decide between e.g. windows-1252 and windows-1258 without horrible consequences? -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Quoted lambda expressions in manuals
There are some quoted lambda expressions in the manuals: find . -type f -print0 | xargs -0 -e grep -nH -e '(lambda ./custom.texi:905: '(lambda () ./custom.texi:1392: '(lambda () ./custom.texi:: '(lambda () (auto-fill-mode 1))) ./emacs-xtra.texi:215: #'(lambda (optional noconfirm) 'fast)) ./gnus.texi:3020: '(lambda nil (local-set-key d (local-key-binding n Maybe those could be removed eventually in order to prevent bad karma (as Stefan puts it). In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.6.10) of 2005-12-14 on neutrino X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--with-gtk'' 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_US locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: desktop-save-mode: t display-time-mode: t iswitchb-mode: t recentf-mode: t show-paren-mode: t encoded-kbd-mode: t auto-compression-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 column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: M-x r e p o r t - e m tab return Recent messages: Loading time...done Loading desktop...done Loading rng-auto (source)...done Loading /usr/local/share/emacs/site-lisp/tex-site.el (source)...done Loading easy-mmode...done Loading edmacro...done No desktop file. For information about the GNU Project and its goals, type C-h C-p. Loading cl-seq...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding problem with Euro sign
* David Hansen (2005-12-13) writes: On Tue, 13 Dec 2005 13:12:02 +0100 Ralf Angeli wrote: Attached you can find a file with two 8-bit characters I extracted from a file produced by Visual Studio under Windows. The characters should be u umlaut and the Euro sign. Emacs does not seem to be able to find the right coding system for it and displays it with raw-text-dos. I could not get the file displayed correctly by loading it with iso-latin-1, iso-latin-9, or cp1251. And I am not sure if this is a problem of Emacs or if Visual Studio simply produced garbage. The \200 (0x80) is EUR in windows-1252. But i have no clue what the 0xc2 is doing there. The 0xc2 seems to have gotten into the file while sending it. It is not there in the original and can be deleted without affecting the outcome of choosing a coding system. With -*- coding: windows-1252; -*- in the first line or when you open the file with C-x RET c windows-1252 RET C-x C-f test.txt RET the EUR gets displayed but there's still this 0xc2 (latin capital letter A with circumflex in latin-1/9 or windows-1252). Really? In my case this results in , | character: ь (01212154, 332908, 0x5146c, U+044C) | charset: [mule-unicode-0100-24ff] | (Unicode characters of the range U+0100..U+24FF.) | code point: [40 108] | syntax: wwhich means: word |category: y:Cyrillic | buffer code: 0x9C 0xF4 0xA8 0xEC | file code: 0xFC (encoded by coding system windows-1251-dos) | display: by this font (glyph code) | -Misc-Fixed-Bold-R-Normal--18-120-100-100-C-90-ISO10646-1 (0x44C) ` for the u umlaut and , | character: Ђ (01212042, 332834, 0x51422, U+0402) | charset: [mule-unicode-0100-24ff] | (Unicode characters of the range U+0100..U+24FF.) | code point: [40 34] | syntax: wwhich means: word |category: y:Cyrillic | buffer code: 0x9C 0xF4 0xA8 0xA2 | file code: 0x80 (encoded by coding system windows-1251-dos) | display: by this font (glyph code) | -Misc-Fixed-Bold-R-Normal--18-120-100-100-C-90-ISO10646-1 (0x402) ` for the Euro sign. For the record, the following is what I get if I load the file without specifying a coding system before (i.e. when it ends up being displayed with raw-text-dos): , | character: ü (0374, 252, 0xfc) | charset: [eight-bit-graphic] (8-bit graphic char (0xA0..0xFF)) | code point: [252] | syntax: which means: whitespace | buffer code: 0xFC | file code: 0xFC (encoded by coding system raw-text-dos) | display: by display table entry [?ü] (see below) | | The display table entry is displayed by these fonts (glyph codes): | ü: -Bitstream-Terminal-Medium-R-Normal--18-140-100-100-C-110-ISO8859-1 (0xFC) ` , | character: (0200, 128, 0x80, U+0080) | charset: [eight-bit-control] (8-bit control code (0x80..0x9F)) | code point: [128] | syntax: which means: whitespace | buffer code: 0x80 | file code: 0x80 (encoded by coding system raw-text-dos) | display: by this font (glyph code) | -Bitstream-Terminal-Medium-R-Normal--18-140-100-100-C-110-ISO8859-1 (0x80) ` -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding problem with Euro sign
* David Hansen (2005-12-14) writes: On Tue, 13 Dec 2005 23:42:02 +0100 Ralf Angeli wrote: | file code: 0xFC (encoded by coding system windows-1251-dos) ^ ^ It for me it's file code: 0xFC (encoded by coding system windows-1252-unix) ^ ^ Sure you didn't made a typo in the coding system? Argh, yes, that was the problem. Not so much a typo, I simply used the wrong coding system. Thanks for setting me right (twice). -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: CUA mode: C-S-c as prefix does not work
* Kim F. Storm (2005-12-08) writes: Ralf Angeli [EMAIL PROTECTED] writes: ;; - use the SHIFT key with the prefix key, i.e. C-X or C-C The last option does not seem to work (at least with the examples I tried). As an example, Thanks. I have installed a fix. Thanks. I'll go and inform the user who originally reported this. By the way, it would probably be a good idea to move the documentation which can be found in cua-base.el to the Emacs manual which already contains a section about CUA mode. RMS is concerned about the size of the (printed) Emacs Manual, so I think the description of cua-mode in the Emacs manual is sufficient as is (I already expanded it compared to what was there originally). Hm, I think that the stuff about the prefix keys is very useful. It's a pity that it is hidden in the Lisp file. But cua-mode definitely deserves a manual (cua.texi) on its own to describe all of its features. I will probably write it eventually, but if anybody would like to write it (or just start drafting a manual for it), I would appreciate it very much. Of course, I will help as much as I can... If I actually used CUA mode and if I had not enough to do with AUCTeX ... (c; -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
CUA mode: C-S-c as prefix does not work
Documentation of CUA mode in cua-base.el contains the following text:
;; If you really need to perform a command which starts with one of
;; the prefix keys even when the region is active, you have three options:
;; - press the prefix key twice very quickly (within 0.2 seconds),
;; - press the prefix key and the following key within 0.2 seconds, or
;; - use the SHIFT key with the prefix key, i.e. C-X or C-C
The last option does not seem to work (at least with the examples I
tried). As an example,
* start Emacs with `emacs -Q',
* type `M-x tex-mode RET' and `M-x cua-mode RET',
* insert a random word and mark it (e.g. with `C-a C-SPC C-e'), and
* type `C-S-c {' which should translate to `C-c {' and insert braces
around the word.
But in fact the binding is reported to be undefined.
By the way, it would probably be a good idea to move the documentation
which can be found in cua-base.el to the Emacs manual which already
contains a section about CUA mode.
In GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, GTK+ Version 2.6.10)
of 2005-12-02 on pacem, modified by Debian
X server distributor `The X.Org Foundation', version 11.0.60802000
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.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.0.50/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.0.50/leim'
'--with-x=yes' '--with-x-toolkit=gtk' 'CFLAGS=-DDEBIAN -g -Wno-pointer-sign
-O2' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu''
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_US
locale-coding-system: iso-latin-1
default-enable-multibyte-characters: t
Major mode: LaTeX
Minor modes in effect:
cua-mode: t
tooltip-mode: t
auto-compression-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
line-number-mode: t
transient-mark-mode: t
Recent input:
M-x t e x - m o d tab return f o o M-x c u a -
m o d e return C-a C-SPC C-e C-c C-c { C-_ C-a C-SPC
C-e C-S-c { M-x r e p o r t - e m tab return
Recent messages:
For information about the GNU Project and its goals, type C-h C-p.
Loading tex-mode...
Loading regexp-opt...done
Loading tex-mode...done
Loading cua-base...done
Mark set
Loading skeleton...done
Undo!
Mark activated
Loading emacsbug...done
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
smtpmail.el: PLAIN authentication fails
The SMTP PLAIN authentication mechanism doesn't seem to work in smtpmail.el. At least it didn't when I tried it with smtp.web.de. Here is an SMTP trace (hostname and IP address obfuscated): --8---cut here---start-8--- 220 smtp07.web.de ESMTP WEB.DE V4.105#333 Mon, 05 Dec 2005 20:10:04 +0100 EHLO my.host 250-smtp07.web.de Hello my.host [xxx.xxx.xxx.xxx] 250-SIZE 69920427 250-PIPELINING 250-AUTH PLAIN LOGIN 250-STARTTLS 250 HELP AUTH PLAIN 535 Incorrect authentication data QUIT 221 smtp07.web.de closing connection Process SMTP deleted --8---cut here---end---8--- I could not find an RFC describing exactly the syntax of the AUTH command for PLAIN authentication but in all the examples I found on the net the credentials are passed along with the AUTH PLAIN string. That means instead of AUTH PLAIN smtpmail.el should submit AUTH PLAIN base64-encoded credentials to the server. With the following change to smtpmail.el I could be authenticated at the SMTP server and send a mail: 2005-12-05 Ralf Angeli [EMAIL PROTECTED] * mail/smtpmail.el (smtpmail-try-auth-methods): Send credentials together with AUTH PLAIN command. Use manually entered password for PLAIN authentication if respective element in `smtpmail-auth-credentials' is nil. --8---cut here---start-8--- --- /home/angeli/scratch/smtpmail.el~ 2005-12-05 20:17:39.0 +0100 +++ /home/angeli/scratch/smtpmail.el2005-12-05 20:18:46.0 +0100 @@ -560,16 +560,13 @@ (= (car ret) 400)) (throw 'done nil))) ((eq mech 'plain) - (smtpmail-send-command process AUTH PLAIN) - (if (or (null (car (setq ret (smtpmail-read-response process - (not (integerp (car ret))) - (not (equal (car ret) 334))) - (throw 'done nil)) - (smtpmail-send-command process (base64-encode-string + (smtpmail-send-command process + (concat AUTH PLAIN + (base64-encode-string (concat \0 (smtpmail-cred-user cred) \0 - (smtpmail-cred-passwd cred + passwd (if (or (null (car (setq ret (smtpmail-read-response process (not (integerp (car ret))) (not (equal (car ret) 235))) --8---cut here---end---8--- Also note, that `passwd' is used in the string for the credentials instead of `(smtpmail-cred-passwd cred)' which can be nil. `passwd' will contain the correct value in any case. In GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, GTK+ Version 2.6.10) of 2005-12-02 on pacem, modified by Debian 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.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.0.50/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.0.50/leim' '--with-x=yes' '--with-x-toolkit=gtk' 'CFLAGS=-DDEBIAN -g -Wno-pointer-sign -O2' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu'' 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_US locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: desktop-save-mode: t display-time-mode: t iswitchb-mode: t recentf-mode: t show-paren-mode: t encoded-kbd-mode: t auto-compression-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 column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: ESC x r e p o r t - e m TAB RET Recent messages: Loading recentf...done Loading /home/angeli/.recentf...done Cleaning up the recentf list...done (0 removed) Loading iswitchb...done Loading time...done Loading desktop...done No desktop file. For information about the GNU Project and its goals, type C-h C-p. Loading cl-seq...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell + longlines: hang/wait
* David Reitter (2005-10-27) writes: On 27 Oct 2005, at 02:31, Richard M. Stallman wrote: A paragraph is NOT meant to be a single line, and if it appears as one, that is very inconvenient. Let me give you two examples. - I've been doing some work in Python lately. Python enforces strict formatting, and you don't have the option of inserting a newline at almost arbitrary (whitespace) positions like in C, for example. Of course there is such an option. Just put a backslash in front of the linebreak. See URL:http://www.python.org/doc/2.4.2/ref/explicit-joining.html. - LaTeX. Sometimes I edit my document with a narrow frame, sometimes with a larger one. Screen real-estate is limited, and I often like to have several things open to copy/paste etc. Therefore, I'd like text to be rewrapped to use up the screen. Personally I think the longer text lines become the more readability decreases. So for me a 70-something character limit is desirable even in a wide frame. Anyway, keep in mind that the buffer size of TeX is limited. And that means the maximal line length which can be processed is limited as well. Depending on the value of the limit this can make problems if you save your LaTeX files with long lines. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: show-paren-mode indicates mismatch for escaped parentheses
* Juri Linkov (2005-10-25) writes: Your patch doesn't look right. I think it is correct that `show-paren-mode' indicates mismatches on escaped parentheses in latex-mode, because according to the syntax table of latex-mode, these parentheses are not matched. So when you type in latex-mode, for example, C-M-f (forward-sexp) on them, you will get the error Unbalanced parentheses. `show-paren-mode' just indicates the same fact in a more visible way. You are right, if there is a bug, `show-paren-mode' is not the right place to fix it. So you rather may try to change the syntax table of latex-mode to allow it matching such parentheses. I still think that it would make more sense to not regard opening or closing parens as start or end of sexps respectively if they are escaped. The description of the syntax class `/' used for backslashes in LaTeX mode suggests this as well (from the Elisp manual): -- Syntax class: character quote A character quote character (designated by `/') quotes the following character so that it loses its normal syntactic meaning. This differs from an escape character in that only the character immediately following is ever affected. To me it looks like the syntax table is fine, but `forward-sexp' (i.e. `scan_lists') is disregarding it. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
show-paren-mode indicates mismatch for escaped parentheses
In LaTeX escaped parentheses like \(a^2+b^2=c^2\) are used for marking inline math. `show-paren-mode' indicates mismatches when moving point over the opening or closing parentheses. In order to prevent this, I think, it should not try to match an escaped paren in the first place. The following patch achieves this by performing the search for a matching paren only if an even number of escape chars or none is found before the character in question: *** Paren.el 10 Aug 2005 15:24:59 +0200 1.64 --- paren.el 18 Oct 2005 11:28:58 +0200 *** *** 144,151 (defun show-paren-function () (if show-paren-mode (let ((oldpos (point)) ! (dir (cond ((eq (syntax-class (syntax-after (1- (point 5) -1) !((eq (syntax-class (syntax-after (point))) 4) 1))) pos mismatch face) ;; ;; Find the other end of the sexp. --- 144,158 (defun show-paren-function () (if show-paren-mode (let ((oldpos (point)) ! (dir (cond ((and (eq (syntax-class (syntax-after (1- (point 5) ! (zerop (mod (save-excursion ! (backward-char) ! (skip-syntax-backward \\/)) 2))) ! -1) ! ((and (eq (syntax-class (syntax-after (point))) 4) ! (zerop (mod (save-excursion ! (skip-syntax-backward \\/)) 2))) ! 1))) pos mismatch face) ;; ;; Find the other end of the sexp. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.6.10) of 2005-10-18 on neutrino X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--with-gtk'' 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_US locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: LaTeX Minor modes in effect: reftex-mode: t desktop-save-mode: t display-time-mode: t iswitchb-mode: t recentf-mode: t show-paren-mode: t encoded-kbd-mode: t mouse-wheel-mode: t auto-compression-mode: t menu-bar-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 column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-x C-f s c tab v e r b tab 8 tab return down down down down down down down down down down left return return a SPC \ ( b \ ) SPC c right left left left left up right C-x C-s C-x C-f C-a C-k / d a tab s h o tab return C-n C-n C-M-x C-x b return C-f C-f C-f C-f C-f C-f C-f C-f C-f SPC ( d ) SPC e C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-x C-s M-x r e p o r tab return Recent messages: Starting new Ispell process... Loading reftex...done Loading reftex-auc...done Loading reftex-dcr...done Automatic display of crossref information was turned on Loading skeleton...done Wrote /home/angeli/scratch/verbatim-test8.tex show-paren-function Wrote /home/angeli/scratch/verbatim-test8.tex Loading emacsbug...done ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
outline-mark-subtree does not activate mark
With Transient Mark mode enabled I expected a section like
--8---cut here---start-8---
\section{foo}
Some text.
--8---cut here---end---8---
in a LaTeX buffer to be highlighted after typing `M-x
outline-mark-subtree RET'. Unfortunately this does not happen because
the `push-mark' call in `outline-mark-subtree' does not request for
the mark to be activated. Shouldn't it do this?
In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.6.9)
of 2005-08-23 on neutrino
X server distributor `The X.Org Foundation', version 11.0.60802000
configured using `configure '--with-gtk''
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_US
locale-coding-system: iso-latin-1
default-enable-multibyte-characters: t
Major mode: LaTeX/FM
Minor modes in effect:
reftex-mode: t
TeX-fold-mode: t
LaTeX-math-mode: t
show-paren-mode: t
encoded-kbd-mode: t
iswitchb-mode: t
display-time-mode: t
desktop-save-mode: t
mouse-wheel-mode: t
auto-compression-mode: t
menu-bar-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
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f
C-f C-f C-f C-f C-f C-f SPC t C-n C-n C-p C-x C-e C-x
b return M- C-n C-n C-n C-n C-n C-n C-n C-n M-x
M-p return C-h f p u s h - m a r k return C-x 0
C-x k return C-x b return C-p C-f C-f C-d n i l
SPC t C-n C-x C-e C-x b return C-n C-n C-n C-n M-x
M-p return C-g M-x r e p o r t - m e backspace
backspace e m tab return
Recent messages:
Mark set
Undo!
Mark set
outline-mark-subtree
Mark set
Type C-x 1 to remove help window. C-M-v to scroll the help.
outline-mark-subtree
Mark set
Quit
Loading emacsbug...done
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Overlays disappearing during line-by-line scrolling
* Kim F. Storm (2005-07-15) writes: For one thing, I introduced a redisplay loop that should be fixed now. But fixing the loop meant that I had to eliminated part of the original fix, so pls. test whether things still works ok. Looks good. I could not find any regression. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Overlays disappearing during line-by-line scrolling
* Kim F. Storm (2005-07-13) writes: I have installed some changes to fix this and other problems related to line-move around such multi-line overlay strings. Cool! Thank you very much! I was plowing through the code in xdisp.c and dispnew.c but didn't really know where to start. Maybe I can learn something from your changes if I find the time to study them. (c: The changes touches on some tricky low-level move_it_... functions so I may have broken other things... Some cursory testing did not reveal any breakage but I will report back in case I find anything. The behavior now is much better, i.e. the overlay strings don't disappear anymore and scrolling does not get stuck. Scrolling may look a bit strange because overlays with multi-line overlay strings are skipped as a whole and not displayed anymore. So if you have something like this first line first line [overlay overlay overlay overlay overlay overlay overlay overlay overlay] second line second line and do `C-u 1 C-v' until the first line is scrolled out of the window, the first window line then will only contain second line second line missing the start of the overlay on the second line of the example. Anyway, your last change resulted in a big improvement, so thanks again. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Eli Zaretskii (2005-07-09) writes: From: Ralf Angeli [EMAIL PROTECTED] + --eval $(ARGQUOTE)(let ((find-file-hook nil) \ + (find-file-suppress-same-file-warnings t) \ + (generated-autoload-file \ + (expand-file-name (pop command-line-args-left \ + (mapcar (function update-directory-autoloads) \ + command-line-args-left) \ + (save-buffers-kill-emacs t))$(ARGQUOTE) \ + $(lisp)/loaddefs.el $(lisp) $(WINS) Good God! Can you please explain why we need such a monstrosity with MSYS, and why the original version fails (i.e., why is the file name mangled)? I don't know exactly. I suspect that the MSYS shell regards the colon as a path separator and tries to replace it by a semi-colon and a path prefix. In order to find out I asked on the MSYS mailing list about it but haven't got an answer about this specific issue yet. You can find the thread at URL:http://thread.gmane.org/gmane.comp.gnu.mingw.msys/2715. It's hard to argue about this patch without understanding that much, and it's harder still to try to figure out whether it might hamper other build environments. (FWIW, my environment is identical to yours except that the shell is not the one from MSYS. I have no problems with the original command, although I use the same port of Make.) The patch simply makes sure that the path will not get altered by the shell. Like this it doesn't matter if the behavior of the MSYS shell is correct or not. Otherwise, if you wanted to build Emacs with both MinGW and MSYS installed, you would have to rename sh.exe before calling mingw32-make which will then fall back to comspec. With the patch it doesn't matter, so the build process should be more robust. Btw, isn't MinGW 4.1.0 a development snapshot, not a released version? If so, perhaps it's a bug in that version of MinGW (I have 3.7 on my box). On MinGW's download page 4.1.0 is listed under Current. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Eli Zaretskii (2005-07-09) writes: It's strange: MinGW-4.1.0.exe is under Current, but MinGW Runtime is still at version 3.7. What is inside MinGW-X.Y.Z.exe---isn't it the runtime plus the compiler and Binutils? I don't remember what was packaged with it. And as I am currently enjoying my GNU system I don't want to ruin my day by booting Windows. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Ralf Angeli (2005-07-07) writes: Using this for bootstrapping with `mingw32-make bootstrap' from a DOS prompt in the nt/ directory I get the following error: [...] Opening output file: invalid argument, d:/software/windows/unix/src/emacs/lisp/D;C:Programmemsys☺.0 oftwarewindowsunix rc←macslisploaddefs.el mingw32-make[1]: *** [autoloads] Error -1 mingw32-make[1]: Leaving directory `D:/software/windows/unix/src/emacs/lisp' mingw32-make: *** [bootstrap-gmake] Error 2 Okay, with the following patch (thanks, David, for reminding me of the technique) I can build Emacs under Windows using mingw32-make (MinGW 4.1.0) with MSYS' (1.0.10) sh.exe either present or not. 2005-07-08 Ralf Angeli [EMAIL PROTECTED] * makefile.w32-in (autoloads): Do not let autoload file name be mangled by the shell. --- makefile.w32-in 4 Jul 2005 23:08:56 - 1.44 +++ makefile.w32-in 8 Jul 2005 20:52:06 - @@ -149,11 +149,14 @@ autoloads: loaddefs.el doit @echo Directories: $(WINS) $(emacs) -l autoload \ - --eval $(ARGQUOTE)(setq find-file-hook nil \ - find-file-suppress-same-file-warnings t \ - generated-autoload-file \ - $(DQUOTE)$(lisp)/loaddefs.el$(DQUOTE))$(ARGQUOTE) \ - -f batch-update-autoloads $(lisp) $(WINS) + --eval $(ARGQUOTE)(let ((find-file-hook nil) \ + (find-file-suppress-same-file-warnings t) \ + (generated-autoload-file \ + (expand-file-name (pop command-line-args-left \ + (mapcar (function update-directory-autoloads) \ + command-line-args-left) \ + (save-buffers-kill-emacs t))$(ARGQUOTE) \ + $(lisp)/loaddefs.el $(lisp) $(WINS) subdirs.el: $(MAKE) $(MFLAGS) update-subdirs -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Ralf Angeli (2005-07-06) writes: loaddefs.el in a Windows build checked out and compiled yesterday doesn't seem to include all autoloads. For example the autoloads for latexenc.el are missing. I suspect this is the cause for LaTeX files in a Windows build of Emacs being opened with a raw-text-dos coding system (which prevents character code conversion and therefore leads to other problems). Maybe I should add that these problems manifest themselves in duplicated ^M line endings every time a file is edited, saved and reopened if there are non-ASCII characters in the buffer. That means after doing this a few times one will end up with ^M^M^M^M^M^M. So Windows users editing (La)TeX files and using non-ASCII characters in these files should either take precautions not to end up with raw-text buffers or stay away from CVS Emacs until this is fixed. Another error which is likely caused by the incomplete loaddefs.el is that Makefile mode (makefile-gmake-mode in particular) cannot be activated when a Makefile is opened. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Jason Rumney (2005-07-07) writes: Can you please try to debug what has caused this on your machine. I do not have this problem, and noone else has reported it either. Okay, I inserted a `sleep 60' at the end of the `autoloads' target of lisp/makefile and this is what I could observe during a `make bootstrap': --8---cut here---start-8--- make[1]: Entering directory `/d/software/windows/unix/src/emacs/lisp' /d/software/windows/unix/src/emacs/lisp/../update-subdirs /d/software/windows/unix/src/emacs/lisp; \ for file in calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url; do \ /d/software/windows/unix/src/emacs/lisp/../update-subdirs $file; \ done; Directories: calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url ./../bin/emacs.exe -batch --no-init-file --no-site-file --multibyte -l autoload \ --eval '(setq find-file-hook nil \ find-file-suppress-same-file-warnings t \ generated-autoload-file \ /d/software/windows/unix/src/emacs/lisp/loaddefs.el)' \ -f batch-update-autoloads /d/software/windows/unix/src/emacs/lisp calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url Opening output file: no such file or directory, d:/d/software/windows/unix/src/emacs/lisp/loaddefs.el --8---cut here---end---8--- So there is a superfluous d: in front of the path. The problem will probably vanish if a drive:/dir/ syntax was used all along. But I don't know how to do this. As updating loaddefs.el fails, the loaddefs.el which remains in the lisp/ directory has the same contents as ldefs-boot.el which was copied by the bootstrap-clean target. Obviously ldefs-boot.el does not include autoloads for latexenc and Makefile mode stuff. For configuring and building Emacs I opened a DOS prompt entered the nt/ subdirectory, did a configure --with-gcc --prefix=d:/software/windows/unix/emacs and after that a make bootstrap All of this was done with recent versions of MSYS, MinGW and GnuWin32 libraries. The version of make is GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i686-pc-msys -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loaddefs.el on Windows incomplete
* Jason Rumney (2005-07-07) writes: The fact that you have no drive letters in the paths suggests to me that you are using cygwin or msys make, which corrupts DOS paths to look like unix paths in a way that only cygwin or msys tools can understand. From my former message: The version of make is GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i686-pc-msys So yes, I am using MSYS make. There wasn't a warning about MSYS make in nt/INSTALL and the build process did not stop with an error, so I thought this would be safe. Now, after looking at URL:http://ourcomments.org/Emacs/w32-build-emacs.html which is mentioned in nt/INSTALL I actually saw that the very same problem I got is described there with a similar snippet of the make output. I have to apologize for not reading this web page before, but maybe one can spare other people this hassle by adding a warning about MSYS make to nt/INSTALL and let the build process abort if loaddefs.el cannot be updated. This is not good behaviour for make, please try a different version. There are non-MSYS versions of mingw make available that use native paths. Okay, MinGW comes with a mingw32-make.exe which identifies itself as mingw32-make --version GNU Make 3.80 Using this for bootstrapping with `mingw32-make bootstrap' from a DOS prompt in the nt/ directory I get the following error: --8---cut here---start-8--- mingw32-make[1]: Entering directory `D:/software/windows/unix/src/emacs/lisp' D:/software/windows/unix/src/emacs/lisp/../update-subdirs D:/software/windows/unix/src/emacs/lisp; \ for file in calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url; do \ D:/software/windows/unix/src/emacs/lisp/../update-subdirs $file; \ done; Directories: calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url ./../bin/emacs.exe -batch --no-init-file --no-site-file --multibyte -l autoload \ --eval '(setq find-file-hook nil \ find-file-suppress-same-file-warnings t \ generated-autoload-file \ D:/software/windows/unix/src/emacs/lisp/loaddefs.el)' \ -f batch-update-autoloads D:/software/windows/unix/src/emacs/lisp calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url Opening output file: invalid argument, d:/software/windows/unix/src/emacs/lisp/D;C:Programmemsys☺.0 oftwarewindowsunix rc←macslisploaddefs.el mingw32-make[1]: *** [autoloads] Error -1 mingw32-make[1]: Leaving directory `D:/software/windows/unix/src/emacs/lisp' mingw32-make: *** [bootstrap-gmake] Error 2 --8---cut here---end---8--- The same happens if I rename mingw32-make.exe to make.exe. Via Google I could find the same error documented at URL:http://www.emacswiki.org/cgi-bin/emacs-en/BuildingTwentyOneThreeWThirtyTwoMingw together with some dubious workaround. I'm stumped. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
loaddefs.el on Windows incomplete
loaddefs.el in a Windows build checked out and compiled yesterday doesn't seem to include all autoloads. For example the autoloads for latexenc.el are missing. I suspect this is the cause for LaTeX files in a Windows build of Emacs being opened with a raw-text-dos coding system (which prevents character code conversion and therefore leads to other problems). -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [features request] String transformation in replacement
* Daniel Dehennin (2005-07-06) writes: Le 4326 Septembre 1993, Lute Kamstra a tapoté: (let ((s ONE TWO)) (string-match \\t\\(\\w+\\) s) (replace-match (downcase (match-string 1 s)) t t s 1)) Well, in interactive replacement like query-replace-regexp, I can not make lisp call in the replacement part :-( With a CVS Emacs: C-M-% \(some-regexp\) RET \,(downcase \1) RET See (info (emacs)Regexp Replace). -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problems with non-zero scroll-margin
* Richard M. Stallman (2005-07-05) writes: Besides GDB another easy to use testcase is ielm. Type `M-x ielm RET' and press RET until the prompt reaches the bottom of the window. When this happens point will be placed in the middle of the screen. This problem does not happen for me after my last change. Neither do I see it. However, I think that is be a bug. If (recenter -1) puts point inside the scroll margins, the scroll margin code must be broken. I will fix it to put point just within the specified margin. Okay. If this doesn't prevent the last line from jumping up and down like one can observe it now in the ielm case, the following change on the Lisp level might be an idea as well: --- comint.el 04 Jul 2005 10:21:17 +0200 1.325 +++ comint.el 05 Jul 2005 09:54:31 +0200 @@ -1818,7 +1818,7 @@ (= (point) (point-max))) (save-excursion (goto-char (point-max)) - (recenter -1))) + (recenter (- -1 scroll-margin (select-window selected) nil t)) (set-buffer current @@ -1852,7 +1852,7 @@ Put the end of the buffer at the bottom of the window. (interactive) (goto-char (point-max)) - (recenter -1)) + (recenter (- -1 scroll-margin))) (defun comint-get-old-input-default () Default for `comint-get-old-input'. I could do this for move-to-window-line also, and I wrote the code to do that, but it might be incorrect to install it. move-to-window-line is supposed to move point to the text now on a certain line, and if it moves point to some other place, that feels like a bug to me. So the programs that are calling move-to-window-line probably should take account of scroll-margin's value in some way. In case of Gnus I could mostly fix article scrolling with the following changes: --- gnus-art.el 02 Jul 2005 15:02:32 +0200 1.82 +++ gnus-art.el 05 Jul 2005 10:22:51 +0200 @@ -5160,7 +5160,7 @@ If end of article, return non-nil. Otherwise return nil. Argument LINES specifies lines to be scrolled up. (interactive p) - (move-to-window-line -1) + (move-to-window-line (max (- -1 scroll-margin) (- -1 (window-body-height (if (save-excursion (end-of-line) (and (pos-visible-in-window-p) ;Not continuation line. @@ -5189,13 +5189,13 @@ (end-of-buffer ;; Long lines may cause an end-of-buffer error. (goto-char (point-max) - (move-to-window-line 0)) + (move-to-window-line (min scroll-margin (window-body-height (defun gnus-article-prev-page (optional lines) Show previous page of current article. Argument LINES specifies lines to be scrolled down. (interactive p) - (move-to-window-line 0) + (move-to-window-line (min scroll-margin (window-body-height))) (if (and gnus-page-broken (bobp) (not (save-restriction (widen) (bobp ;Real beginning-of-buffer? @@ -5209,7 +5209,7 @@ (scroll-down lines) (beginning-of-buffer (goto-char (point-min - (move-to-window-line 0) + (move-to-window-line (min scroll-margin (window-body-height))) (defun gnus-article-only-boring-p () Decide whether there is only boring text remaining in the article. Unfortunately, although the arguments supplied to `move-to-window-line' are limited to the value of `(window-body-height)', scrolling still fails in case the value of `scroll-margin' is greater than the window body height. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problems with non-zero scroll-margin
* Kim F. Storm (2005-07-05) writes: I would be VERY surprised if M-0 M-r suddenly started to scroll the window. What do you mean with started? Emacs 21 already behaves like this in case `scroll-margin' has a non-zero value. The description of `scroll-margin' in the Elisp manual also mentions this behavior, see (info (elisp)Textual Scrolling). Since move-to-window-line moves _point_ in the current window _without_ scrolling, I don't understand why it would ever consider scroll-margin. But of course, the strict interpretation of scroll-margin's doc string says that point may never occur in these margins. I think that is too restrictive. It can be too restrictive if, for example, one wants to calculate an amount of screen lines with code like (count-screen-lines (save-excursion (move-to-window-line 0) (point)) (point)) I don't know if the redisplay code is able to force point out of the margin during its execution, though. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
scroll-preserve-screen-position and tall lines
When `scroll-preserve-screen-position' is set to `always' Emacs doesn't manage to keep the vertical position of point relative to window boundaries if tall lines are involved. Here is a testcase: (progn (setq scroll-preserve-screen-position 'always) (pop-to-buffer (get-buffer-create *test*)) (dotimes (i 50) (insert (concat (number-to-string i) \n))) (insert TALL\n) (put-text-property (line-beginning-position 0) (line-end-position 0) 'face '(:height 2.0 :inherit variable-pitch)) (dotimes (i 50) (insert (concat (number-to-string (+ i 50)) \n))) (search-backward TALL)) After executing it, scroll the buffer by one line with `C-u 1 C-v'. Notice that point does not keep its vertical position but moves upwards together with the string TALL. (`scroll-down' does not seem to be affected.) In the functionality of `scroll-preserve-screen-position' is implemented in Elisp, it is working as intended. You can try it by executing the following function while having point on the TALL string in the *test* buffer generated from the code above. (defun scroll-up-test () (interactive) (setq scroll-preserve-screen-position nil) (let ((orig-window-line (count-screen-lines (save-excursion (move-to-window-line 0) (point)) (point (scroll-up 1) (move-to-window-line orig-window-line))) In GNU Emacs 22.0.50.2 (i686-pc-linux-gnu, GTK+ Version 2.6.8) of 2005-07-04 on neutrino X server distributor `The XFree86 Project, Inc', version 11.0.4031 configured using `configure '--with-gtk'' 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_US locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: desktop-save-mode: t display-time-mode: t iswitchb-mode: t show-paren-mode: t encoded-kbd-mode: t mouse-wheel-mode: t auto-compression-mode: t menu-bar-mode: t global-font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t next-error-follow-minor-mode: Fol Recent input: C-n C-y C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-b C-x C-e C-u 1 C-v C-x o C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-b C-x C-e C-x o M-x s c r o l l - u p - t e tab return M-x M-p return M-x M-p return C-p C-p C-p C-p M-x M-p return M-x M-p return M-x r e p o r t - e m tab return Recent messages: Loading edmacro...done No desktop file. Loading jit-lock...done For information about the GNU Project and its goals, type C-h C-p. Loading cl-seq...done Mark set Loading cl-macs...done 141 scroll-up-test Loading emacsbug...done ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problems with non-zero scroll-margin
* Richard M. Stallman (2005-07-02) writes: at least broke scrolling of articles with RET in Gnus and makes using GDB in Emacs (gud-mode) very inconvenient if the value of `scroll-margin' is non-zero. I don't use GNUS and I cannot test it. Besides GDB another easy to use testcase is ielm. Type `M-x ielm RET' and press RET until the prompt reaches the bottom of the window. When this happens point will be placed in the middle of the screen. Both GDB (gud-mode) and ielm use Comint mode. And that calls `(recenter -1)' as in the following sample: (progn (setq scroll-margin 1) (pop-to-buffer (get-buffer-create *test*)) (dotimes (i 100) (insert (number-to-string i) \n)) (recenter -1)) The crucial question is, is Emacs redisplay behaving incorrectly, or is Gnus using it wrong? Both, Gnus (with `(move-to-window-line 0)') and Comint mode (with `(recenter -1)') are trying to put point to a place where it is not allowed according to the setting of `scroll-margin' and the reaction of Emacs now is to put it to the middle of the window. You could argue that the code in Gnus and Comint mode is not supposed to do things violating scroll margins but maybe Emacs could react a little more graceful in such conditions. I think before the change we are talking about Emacs scrolled the buffer when the next redisplay event happened in order to get the scroll margin right again. This sometimes looked peculiar because such scrolling (i.e. redisplay) did not happen immediately but at quite random points in time. That's exactly what the scroll margin is supposed to do: not let point end up in the specified margin. So I don't think there is a bug. Well, then Gnus and Comint mode would have to be fixed. And probably other code setting point to lines near window boundaries I don't know of yet. Therefore it might still be a good idea to let Emacs handle this more gracefully. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Problems with non-zero scroll-margin
As far as I can see the changset 2005-06-25 Richard M. Stallman [EMAIL PROTECTED] * macfns.c (Fx_show_tip): Pass new arg to try_window. * w32fns.c (Fx_show_tip): Pass new arg to try_window. * xfns.c (Fx_show_tip): Pass new arg to try_window. * xdisp.c (try_window): New arg CHECK_MARGINS. Calls changed. (redisplay_window): Handle try_window reporting point in scroll margin. * dispextern.h (try_window): Declare new arg. at least broke scrolling of articles with RET in Gnus and makes using GDB in Emacs (gud-mode) very inconvenient if the value of `scroll-margin' is non-zero. In case of Gnus the article won't be scrolled and point will end up in the middle of the window. In case of GDB typing RET e.g. for stepping through a function will make point end up in the middle of the window as well, which means you have to move it manually to the prompt again. Here is a test case which mimics the behavior of Gnus: (progn (setq scroll-margin 1) (pop-to-buffer (get-buffer-create *test*)) (dotimes (i 100) (insert (number-to-string i) \n)) (goto-char (point-min)) (scroll-up 1) (move-to-window-line 0)) You should see that point will not be placed on the first window line but in the middle of the window. In GNU Emacs 22.0.50.9 (i686-pc-linux-gnu, GTK+ Version 2.6.8) of 2005-07-01 on neutrino X server distributor `The XFree86 Project, Inc', version 11.0.4031 configured using `configure '--with-gtk'' 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_US locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: desktop-save-mode: t display-time-mode: t iswitchb-mode: t show-paren-mode: t encoded-kbd-mode: t mouse-wheel-mode: t auto-compression-mode: t menu-bar-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 column-number-mode: t line-number-mode: t transient-mark-mode: t next-error-follow-minor-mode: Fol Recent input: SPC C-e backspace down tab down tab down left right backspace right down return up up up C-k C-p C-p C-p C-y down down down down down down down down left C-x C-e C-x k return C-x o C-p C-a C-k down left C-x C-e C-x k return C-x o C-_ down down left C-x C-e C-x k return C-x o down down right up up up up up up up up up C-SPC down down down down down down down down down M-w M-x r e p o r t - m e backspace backspace e m tab return Recent messages: nil 0 [2 times] call-interactively: End of buffer Mark set 0 [2 times] Undo! 0 call-interactively: End of buffer Mark set Loading emacsbug (compiled; note, source file is newer)...done -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Overlays disappearing during line-by-line scrolling
* Kim F. Storm (2005-06-27) writes: However, when I try it with the code above, it beeps in line-move-1 when I move backwards with C-p (for every 4th C-p or so). This is because (one of the instances of) the following code is triggered. (unless noerror (signal (if ( arg 0) 'beginning-of-buffer 'end-of-buffer) nil))) But I don't see how (bobp) would normally return true in the middle of a buffer. Can anybody see why? AFAICS it's rather the following code which produces the beeps: (and (not done) (not line-done) (zerop (vertical-motion -1)) (if (not noerror) (signal 'beginning-of-buffer nil) (setq done t The beeps occur when `C-p' moves over an overlay in the testcase. When this happens, (vertical-motion -1) returns 0 even though it moves point up one screen line. So it could be a problem in `vertical-motion'. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Overlays disappearing during line-by-line scrolling
* Ralf Angeli (2005-06-16) writes: After executing the code move point upwards with `C-p'. After point hit the top of the window further movement will scroll the buffer line by line. This will make the overlays disappear occasionally, i.e. instead of the XXX\nXXX strings one will see the strings again. After some investigation I found out that Emacs hasn't had this bug before 2005-04-26. The following change caused the regression: 2005-04-26 Richard M. Stallman [EMAIL PROTECTED] * simple.el (line-move-1): Avoid using vertical-motion in easy cases. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Overlays disappearing during line-by-line scrolling
It seems that Emacs has problems keeping the display of multi-line overlays correct when scrolling line by line. Here is an example you can use in an Emacs started with `emacs -Q': (progn (switch-to-buffer (get-buffer-create *test*)) (set (make-local-variable 'scroll-conservatively) 1000) (dotimes (i 100) (insert ..\n)) (goto-char (point-min)) (let ((i 2)) (while (= i 98) (let ((ov (make-overlay (1+ (line-beginning-position i)) (line-beginning-position (+ i 2) (overlay-put ov 'display XXX\nXXX)) (setq i (+ i 6 (goto-char (point-max))) After executing the code move point upwards with `C-p'. After point hit the top of the window further movement will scroll the buffer line by line. This will make the overlays disappear occasionally, i.e. instead of the XXX\nXXX strings one will see the strings again. Note that this happens only if the overlays start and stop within a line. That means if you remove the `1+' call in the code above the effect does not occur. I found this bug actually while scrolling through a buffer with folded LaTeX macros while scrolling downwards (not upwards) but was not able to construct a testcase which showed the behavior with downward movement. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.6.7) of 2005-06-16 on neutrino Distributor `The XFree86 Project, Inc', version 11.0.4031 configured using `configure '--with-gtk'' 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_US locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: mouse-wheel-mode: t tooltip-mode: t auto-compression-mode: t menu-bar-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t next-error-follow-minor-mode: Fol Recent input: up up up up up up up up up up up up up up up C-x k return C-_ down down C-x C-e up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-x k return C-n return C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p M-x r e p o r t - e m a tab return Recent messages: Mark set Undo! nil Mark set 5901 [2 times] Undo! [5 times] 5901 Undo! 5901 Loading emacsbug...done ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problems with unicode chars in GTK menus
* jhd (2005-06-12) writes: This has been resolved now as a WONTFIX: --- Additional Comments From Owen Taylor 2005-06-12 00:05 --- This is working as intended - Pango has no real way of knowing that you weren't writing greek text and thus wanted punctuation from the greek font. Okay, thanks for the information. One workaround is to change the positions: (easy-menu-define test-menu (current-local-map) doc `(xxx (,(concat \\Gamma (string (decode-char 'ucs 915 (\\Gamma G))) Hm, the unicode characters in AUCTeX's math menus should help people find the needed symbol more easily. The menus entries are usually read from left to right, so placing the more easily recognizable unicode char after the LaTeX macro will defeat the purpose of those chars to some extent. I guess we just have to live with some peculiar backslashes. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Wrong display and hang with zero-length overlay display string
* Eli Zaretskii (2005-06-11) writes: From: Ralf Angeli [EMAIL PROTECTED] Date: Thu, 09 Jun 2005 00:52:54 +0200 On MS Windows the following code will generate a buffer which displays aaa and after that a lot of whitespace. If you scroll around a bit Emacs will hang with 100% CPU usage. Typing `C-g' does not help. [...] When was your binary compiled? I checked this with an Emacs provided by nqmacs.sf.net which is from end of January and with one from crasseux.com which is from mid-April. Both showed this behavior. I don't see this problem with today's CVS. That'll teach me to report bugs based on outdated binaries. To my excuse I can say that I am using Windows only for gaming purposes and therefore haven't had the development tools installed, but nevertheless wanted to help a user who reported the bug on an AUCTeX mailing list. Could you please try the current codebase and see if the problem is still there? Okay, installed MSYS/MinGW, compiled a current checkout, and I don't see the problem either. So it seems to be fixed. BTW, the configure.bat script told me to execute `gmake' in order to build. But actually `make bootstrap' was required. Maybe the script could be a bit more verbose about this. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (void-variable flyspell-mode)
* Lute Kamstra (2005-06-09) writes: Ralf Angeli [EMAIL PROTECTED] writes: emacs -Q -eval '(setq debug-on-error t)' a debugger window with the following message pops up: Debugger entered--Lisp error: (void-variable flyspell-mode) Yesterday, I changed flyspell.el. As a result the var flyspell-mode is not autoloaded anymore. Apparently, some naughty code references that var without loading flyspell.el. I'm not sure which code though... In loaddefs.el there are some references to the variable `flyspell-mode' in code related to menus. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [make-mode.el] Infinite loop
* Richard Stallman (2005-06-05) writes: Suppose you have a Makefile with the following contents: FOO = bar \ xxx/xxx.xx xxx/xxx.xx If you put the cursor at the start of the second line and type `M-: (looking-at makefile-dependency-regex) RET' Emacs will enter an infinite loop. I tried this. It was not an infinite loop, but it took absurdly long. Does this give good results for you? Yes, it does. Thanks. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problems with unicode chars in GTK menus
* Jan D. (2005-06-06) writes: This is a GTK thing, I can reproduce it with a tiny GTK program. If the default font does not have the character (gamma) GTK tries another font and that may look different than the default one. I am not sure why the \ looks different though. I've filed a GTK bug on that: Thanks! -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Loop in x-file-dialog under MS Windows
AUCTeX calls `read-file-name' (and consequently `x-file-dialog') with the string default as argument for the default file name. We have various reports where this call, when invoked from a menu, led to a loop which made Emacs unresponsive until `C-g' was typed. This happens only under MS Windows. The simplest testcase I can come up with is this: (x-file-dialog default) -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Problems with unicode chars in GTK menus
After executing the following code (easy-menu-define test-menu (current-local-map) doc `(xxx (,(concat (string (decode-char 'ucs 915)) \\Gamma)) (G \\Gamma))) in an Emacs compiled with support for GTK menus, there will be a new xxx menu with two entries. I expected the first menu entry to show an upper case gamma, a space and the string \Gamma. But the space and the backslash don't come out right. The characters look similar to a normal space and backslash, but appear too wide. You should see this by comparing the first menu entry with the second. The latter shows a normal space and backslash. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.6.4) of 2005-05-18 on iwi71 Distributor `The XFree86 Project, Inc', version 11.0.4031 configured using `configure '--with-gtk'' 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_US locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: desktop-save-mode: t display-time-mode: t iswitchb-mode: t show-paren-mode: t encoded-kbd-mode: t mouse-wheel-mode: t auto-compression-mode: t menu-bar-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 column-number-mode: t line-number-mode: t transient-mark-mode: t next-error-follow-minor-mode: Fol Recent input: down down down down down down down C-k C-k C-k C-x C-s left left C-x C-e C-h v t e s t - m e n u return help-echo M-x r e p o r t - m e backspace backspace e m a tab return Recent messages: For information about the GNU Project and its goals, type C-h C-p. Loading jit-lock...done Loading cl-seq...done Wrote /home/angeli/menu-test.el Loading easymenu...done ((menu-item xxx (keymap xxx (\ \\Gamma menu-item \\Gamma (keymap \\Gamma)) (G\ \\Gamma menu-item G \\Gamma (keymap G \\Gamma) Loading help-fns...done Loading pp...done Type C-x 1 to remove help window. C-M-v to scroll the help. Loading emacsbug...done ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Makefile font locking errors
The new font locking code for Makefile mode produces a lot of errors (see below in Recent messages) because of the element (nil (0 nil)) in `font-lock-keywords' which corresponds to ,(if negation `(,negation (1 font-lock-negation-char-face prepend) (2 font-lock-negation-char-face prepend t))) in make-mode.el. In addition the resulting fontification is quite erroneous and does not seem to serve a sensible purpose. What is the rationale for giving most of the code preceded by whitespace a pink background? This is especially odd in cases like (taken from lisp/Makefile) AUTOGENEL = loaddefs.el \ cus-load.el \ finder-inf.el \ subdirs.el \ eshell/esh-groups.el where the background of the first line is unchanged and only the following lines have a pink background. Taking lisp/Makefile as an example again, there are a lot of lines which seem to be underlined for no good reason; for example in the $(lisp)/loaddefs.el target. It would probably also be a good idea to do such changes more carefully when it comes to changing face properties. For example, why was it necessary to change the fontification of make targets so drastically? In GNU Emacs 22.0.50.1 (i386-unknown-freebsd5.4, GTK+ Version 2.6.7) of 2005-05-14 on neutrino.iwi.uni-sb.de Distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--with-gtk'' 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_US.ISO8859-1 locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Makefile Minor modes in effect: desktop-save-mode: t display-time-mode: t iswitchb-mode: t show-paren-mode: t encoded-kbd-mode: t mouse-wheel-mode: t auto-compression-mode: t menu-bar-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 column-number-mode: t line-number-mode: t transient-mark-mode: t next-error-follow-minor-mode: Fol Recent input: return C-x C-f backspace backspace backspace backspace backspace backspace backspace e m tab M a k tab return next next next next next next up up up up next next next next next next next next next next next next next prior prior prior prior prior prior prior prior prior prior prior prior prior prior prior prior prior prior prior prior prior prior prior prior prior prior C-x C-f l i s tab / M a k tab return next prior down down down down down down down down down down x M-x r e p o r tab return Recent messages: Mark set Mark saved where search started Note: file is write protected Error during redisplay: (void-function nil) [57 times] call-interactively: End of buffer call-interactively: Beginning of buffer [8 times] Note: file is write protected Error during redisplay: (void-function nil) [6 times] Buffer is read-only: #buffer Makefile2 Loading emacsbug...done ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu filter triggered too early
* Stefan Monnier (2005-05-07) writes: I expected the filter function to be called only when the menu is being activated. In many circumstances, the whole menu is computed even when the purpose is only to refresh the menu-bar itself. This is not really considered as a bug, just a misfeature. Hm, this might be a knock-out criterion for the usage of menu filters or hooks in order to ask the user for a master file of a multi-file LaTeX document. OTOH, you say that the filter is run during easy-menu-define, which sounds very odd and would most likely be a bug. Are you sure that's what happens? No, because I don't know how to debug the filter function. If it would produce a backtrace or debugging buffer upon putting (error) or (debug) into the filter function, I could see where it is called. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu filter triggered too early
* Stefan Monnier (2005-05-07) writes:
Hm, this might be a knock-out criterion for the usage of menu filters
or hooks in order to ask the user for a master file of a multi-file
LaTeX document.
Indeed. Why do you want to do it from a menu-filter? It sounds like an odd
idea to start with.
The menu holds a list of environment types which the user can use to
insert environments. The content of this list depends on certain
LaTeX classes or packages being present in the LaTeX document. That
means, if the document includes for example a \usepackage{paralist},
there would be compactitem, compactenum etc. in this list in addition
to the standard environments.
When the user opens a file which is part of a multi-file document and
which does not specify the master file as a local variable, she has to
be asked for the master file, in order to get this list (and other
things) right. One could do this is soon as the file is being opened,
but this can become rather annoying if the user simply wants to look
into a couple of files without actually editing anything.
So we searched for a way to delay the question about the master file
until this information is actually needed in the editing process. One
of these events is when the user opens the menu for inserting a LaTeX
environment or macro.
We are currently using a different approach where the question is only
asked for new files which has its own set of problems. But IMO less
than the way via menu filters.
Well, you may not be able to tell when it's done, but you can tell whether
it's done at one specific place or not: add a `message' before
easy-menu-define and another after and see whether your filter's message
occurs between the two or not.
Okay, I did this with the example I provided, and the Hello! message
is displayed _after_ the message placed after the `easy-menu-define'
call.
In any case I guess it just takes place as part of the first redisplay after
easy-menu-define.
Yes, the test above seems to prove this. Thanks for the hint.
--
Ralf
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell.el: down-mouse-2 leads to unwanted text insertion
* Kim F. Storm (2005-04-27) writes: Ralf Angeli [EMAIL PROTECTED] writes: The symptoms are the following: When pressing mouse-2 on a misspelled word, the flyspell menu will appear as soon as mouse-2 is released and will stay opened. I can close it again by clicking with mouse-1 somewhere in the buffer. As soon as this happens, text will get yanked at the point of the original mouse-2 click. This behavior only happens if clicking and releasing the mouse button is done fast. Does it happen if you set mouse-1-click-follow-link to nil ? Yes. Also, increasing the value in `mouse-1-click-follows-link' does not have any effect on the time it takes for the menu to show up when I keep the mouse button pressed. So this seems to be unrelated. Could this be an interaction problem with GTK? I noticed that e.g. in The Gimp a fast click/release with mouse-3 opens a context menu which stays after releasing the mouse button. But if you keep the mouse button pressed for some time, releasing it will make the menu disappear. BTW, it would be nice if e.g. the font selection menu one gets with S-down-mouse-1 would behave this way as well. Currently it will get closed as soon as the mouse button is released no matter how fast you click/release. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: BibTeX-mode: Key generation when latin-1 characters appear in author field
* Christian Schlauer (2005-04-12) writes: [BibTeX keys] There is one more questionmark, though: should these keys contain non-ASCII characters? [...] So it would be safer to ``strip accents'', I guess? You can customize `bibtex-autokey-name-change-strings' for this purpose: , | bibtex-autokey-name-change-strings's value is shown below. | | Alist of (OLD-REGEXP . NEW-STRING) pairs. | Any part of a name matching OLD-REGEXP is replaced by NEW-STRING. | Case is significant in OLD-REGEXP. All regexps are tried in the | order in which they appear in the list. | See `bibtex-generate-autokey' for details. | | You can customize this variable. | | Defined in `bibtex'. ` Maybe it would be possible to add umlauts and accented characters to the default? I don't know what would happen in unibyte mode with stuff like this, though. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Inherited face appears as a function in customize-face buffer
* David PONCE (2005-04-05) writes: It looks clean to me. I have never understood widgets very well, so I don't know whether it is correct. But if it seems to work better than the present code, it must be a step forward. I wish someone here had enough expertise to be able to assure us it is correct--but I think nobody does. So would someone please install the change? And thanks. I installed the change. Thanks! I just compared this functionality in CVS Emacs with Emacs 21. In Emacs 21 it is easier to select a face because there is this Select Face button which presents you with a minibuffer prompt including auto-completion of face names. Additionally you can change the faced used for inheritance right away. The latter functionality is not so important for me and can lead to strange results if click on all the Show buttons for faces with multiple nested inheritance (the `font-latex-title-*-face' faces in AUCTeX are an example for this). But it would be very nice to have the completion mechanism back and maybe a link to the face used for inheritance in case it should not be displayed right away as in Emacs 21. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
flyspell.el: down-mouse-2 leads to unwanted text insertion
If you have flyspell-mode enabled, click with mouse-2 on a highlighted word not in the dictionary and choose Save word. After that, text currently in the kill ring will be yanked into the buffer. This was probably introduced by changing mouse-2 to down-mouse-2 in `flyspell-mode-map' because the problem does not show up with mouse-2. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.6.2) of 2005-03-30 on neutrino Distributor `The XFree86 Project, Inc', version 11.0.4031 configured using `configure '--with-gtk'' 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_US locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: LaTeX Minor modes in effect: mouse-wheel-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t flyspell-mode: t Recent input: backspace backspace backspace backspace backspace backspace backspace # ' f l y s p e l l - c o r r e c t - w o r d return help-echo help-echo help-echo down-mouse-2 mouse-2 right down down down up up up up right right right right right right right right right right right right right right right right left left left left left left left left left left left left left right right right right right right right right left right M-x r e p o r t - m e backspace backspace e m a tab return Recent messages: Undo! Loading help-fns...done Loading pp...done Type C-x 1 to remove help window. C-M-v to scroll the help. ignore Mark set Undo! flyspell-correct-word Personal dictionary saved. Loading emacsbug...done ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Standard faces not working with font-lock-keywords
[I haven't received an email of your answer, so I am replying via Gmane.] * Stefan Monnier (2005-03-27) writes: (setq font-lock-keywords '((foo . bold))) This shouldn't be a face symbol but an expression (whose value is typically a face symbol). I.e.: (setq font-lock-keywords '((foo (0 'bold Oh, thank you for this information. I wasn't aware of this distinction. Does this mean using an expression is the canonical way of referring to faces in `font-lock-keywords' and using a symbol is only supported for reasons of backward compatibility by faces with an associated variable? -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Standard faces not working with font-lock-keywords
Executing the following example code (with-temp-buffer (insert foo) (setq font-lock-keywords '((foo . bold))) (font-lock-fontify-keywords-region (point-min) (point-max))) will result in an error that the variable `bold' is void. If you use, for example, `font-lock-comment-face' instead of `bold' it is working. Shouldn't the standard faces be used in `font-lock-keywords' or is this a bug? I am asking because in AUCTeX you can set up your own lists for keyword fontification and associate faces with them. And this fails if the user tries to use one of the standard faces. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.6.2) of 2005-03-25 on neutrino Distributor `The XFree86 Project, Inc', version 11.0.4031 configured using `configure '--with-gtk'' 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_US locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: display-time-mode: t iswitchb-mode: t show-paren-mode: t encoded-kbd-mode: t mouse-wheel-mode: t menu-bar-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 column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-y C-b C-x C-e q up right up up up C-SPC down down down down M-w M-x r e p o r t - e m tab return Recent messages: Loading byte-opt...done Loading semantic-el...done Loading cl-seq...done Loading jit-lock...done Mark set Loading debug...done Entering debugger... Back to top level. Mark activated Loading emacsbug...done ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Mistakes in documentation of remove-list-of-text-properties
There are some small mistakes in the Elisp manual's description of
`remove-list-of-text-properties'. I think the description should look
like this:
--- text.texi 07 Mar 2005 16:48:51 +0100 1.95
+++ text.texi 11 Mar 2005 08:34:59 +0100
@@ -2619,9 +2619,9 @@
@end defun
@defun remove-list-of-text-properties start end list-of-properties optional
object
-Like @code{remove-list-properties} except that
[EMAIL PROTECTED] is a list property names only, not an
-alternating list of property values.
+Like @code{remove-text-properties} except that @var{list-of-properties}
+is a list of property names only, not an alternating list of property
+names and values.
@end defun
@defun set-text-properties start end props optional object
In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.6.2)
of 2005-03-09 on neutrino
Distributor `The XFree86 Project, Inc', version 11.0.4031
configured using `configure '--with-gtk''
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_US
locale-coding-system: iso-latin-1
default-enable-multibyte-characters: t
Major mode: Diff
Minor modes in effect:
display-time-mode: t
iswitchb-mode: t
show-paren-mode: t
encoded-kbd-mode: t
mouse-wheel-mode: t
menu-bar-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
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
i tab return down left C-left down C-left
C-left C-left C-left M-d t e x t down C-right
C-right C-right C-right SPC o f M-q C-p C-p C-p
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p
C-p C-p C-p C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n up up up up C-left n a m e s SPC a n
d SPC C-x C-s C-x v = M-x r e p o r t - e m tab
return
Recent messages:
Loading tex-info...done
(No files need saving)
Running cvs update ...
CVS process has completed in *cvs*2
Undo!
Type M-x switch-to-buffer-other-window RET to restore the other window. C-M-v
to scroll the help.
Saving file /usr/src/emacs/lispref/text.texi...
Wrote /usr/src/emacs/lispref/text.texi
Loading vc...done
Loading emacsbug...done
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: character syntax fixes needed
* Kenichi Handa (2005-03-09) writes:
In article [EMAIL PROTECTED], Dave Love [EMAIL PROTECTED] writes:
The guillemets , , and should all be punctuation. The single
ones currently have word syntax, and the double ones are treated as
parens in latin-{1,5,9}.el.
As I don't use those characters, I don't know what is
correct. But, it seems that they are used as a pair; isn't
it convenient if we give them paren syntax?
The problem is that they may be paired differently. In German texts
they may be used as quotation marks like this and in French texts
like that.
--
Ralf
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
mouse-1-click-follows-link is hard to use
As I am not really a fan of mouse-2 I was very delighted that support for mouse-1 clicks on certain links was added. Now after using it for quite some time I must say that I tend to revert to mouse-2 because clicking with mouse-1 succeeds in only about 50% of cases for me. One reason for this is that I am sometimes not releasing the mouse button fast enough. Okay, this could be remedied by customizing `mouse-1-click-follows-link'. The second reason is the delay until the action associated with the click is actually performed and that one has to keep the mouse pointer over the link in order for the action to happen. Besides the delay being annoying, I often move the cursor off the link area before the action is carried out. I hope I don't start another of these endless discussions about this feature but for being useful, I think, it should behave more like in other applications. That means the action should be carried out without any delay as soon as mouse-1 is released. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.6.2) of 2005-03-01 on neutrino Distributor `The XFree86 Project, Inc', version 11.0.4031 configured using `configure '--with-gtk'' 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_US locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: display-time-mode: t iswitchb-mode: t show-paren-mode: t encoded-kbd-mode: t mouse-wheel-mode: t menu-bar-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 column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: M-x r e p o r t - e m tab return Recent messages: (emacs) Loading disp-table...done Loading tooltip...done Loading encoded-kb...done Loading image...done Loading cl-macs...done Loading derived...done Loading jit-lock...done Loading cl-seq...done Loading emacsbug...done ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: menu-bar-update-hook run very often
* Ralf Angeli (2005-02-28) writes: [menu-bar-update-hook] I will update the documentation. Meanwhile, do you think the current behavior is a problem? If people deduct from the current doc string that the hook is only called when the menubar is used, this could make them disregard performance issues with the function to be put into the hook. And it could slow down Emacs if the function is called very often during editing. The changed doc string is not so misleading in this regard. Thanks for adapting it. I just noticed that the description of `menu-bar-update-hook' in lispref/keymaps.texi needs an update as well. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Excessive highlighting of overlay with display property
* Kim F. Storm (2005-02-22) writes: Ralf Angeli [EMAIL PROTECTED] writes: (let (ov) (insert \n\nxxx) (setq ov (make-overlay (line-beginning-position) (point))) (overlay-put ov 'mouse-face 'highlight) (overlay-put ov 'display yyy)) Okay, I poked around a bit and the following change fixes the problem for me: Many thanks for finding the location of the error. That is a big help, even though your patch had problems. Oh well, as I didn't fully understand the code, I was happy that I managed to alter the behavior in some favorable direction at all. (c: I have just installed a fix. Thanks! -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Error with MetaPost mode and transient-mark-mode
* David Kastrup (2005-02-18) writes: Does the following patch fix it? Yes, it does. Thanks! -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
