Re: Error during ask-user-about-lock
Richard Stallman skrev: I was afraid your question was going to be WHY does Emacs get a drag'n'drop event?, because I don't know the answer (and it doesn't make much sense to me). It is an interesting question, because if you didn't try to do a drag'n'drop, the event could reflect a bug. But you COULD have done a real drag'n'drop, and generated a legitimate drag-and-drop event. So the question of how to handle one still exists. I will install my patch if no one objects in the next few days. I think the problem is elsewhere. The dnd code has a flaw in it, it generates dnd-events (lisp events) for wrong ClientMessages (X events), in this case a _MOTIF_WM_MESSAGES ClientMessage. These non-real dnd events gets filtered out in x-dnd-handle-drag-n-drop-event (x-dnd.el) so they have no impact normally. I didn't realize they could interfere in other ways. I'll rework the generation of dnd lisp events so they are generated for genuine X dnd events only. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
YAMAMOTO Mitsuharu skrev: On Thu, 10 Aug 2006 13:17:03 +0200, Jan Djärv [EMAIL PROTECTED] said: My intention was that the above scenario would be avoided with BLOCK_INPUT around functions that may call malloc-related functions. It does not help if the calling thread is one of the Gnoem threads. But a signal delivered to a non-main thread is redirected to the main thread by SIGNAL_THREAD_CHECK. A signal yes, but I was thinking of this scenario: A Gnome thread does malloc, gets the mutex lock and enters the malloc code. A signal is delivered (in the main thread as you point out) and enters malloc also. This situation is exactly like the one with the lockup, but here we can't use BLOCK_INPUT around the malloc related functions because they are in the Gnome code. How about just changing the order of lock/unlock and BLOCK_INPUT/UNBLOCK_INPUT in the previous version of BLOCK_INPUT_ALLOC/UNBLOCK_INPUT_ALLOC? That would mean that lock/unlock mutex functions are called in the signal handler context, which is not allowed according to the documentation. Yes, pthread_mutex_(un)lock is not async-signal-safe. But we are already using such functions as malloc in the signal handler context (with the help of BLOCK_INPUT). I guess calling pthread_mutex_(un)lock in the signal handler context is safe in reality unless the interrupted thread is also executing pthread_mutex_(un)lock for the same mutex. I think it's better than the current one, i.e., not protecting shared resources such as __malloc_hook in the signal handler context. I agree with your assumtion that the lockuo occurs because the signal handler and the interrupted therad are calling pthread_mutex_(un)lock for the same mutex. But BLOCK_INPUT does not help, because Gnome code does not have it. So I tried to do the next best thing, i.e. block SIGIO in non-main threads. The problem with this is that I can't block SIGIO before taking the mutex, because if I hang when taking the mutex, SIGIO would remain blocked. One could use trylock and some sort of busy loop, but I don't think that is usable. (Of course SYNC_INPUT is the right direction, but the current plan is not enabling it in the next release as far as I understand.) Unless someone comes up with a supersafe scheme I think we have to live with this race condition until then. But it is better now than before, SIGIO and the main thread executing the sam (un)lock should not lockup. But if the signal handler is executing in one thread one one processor and a Gnome thread is executing on another processor, there could be a lockup. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes: Yes, pthread_mutex_(un)lock is not async-signal-safe. But we are already using such functions as malloc in the signal handler context (with the help of BLOCK_INPUT). I guess calling pthread_mutex_(un)lock in the signal handler context is safe in reality unless the interrupted thread is also executing pthread_mutex_(un)lock for the same mutex. I guess ... safe in reality unless ... Maybe I have been around programmers too long, but I don't find this exactly reassuring. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
On Fri, 11 Aug 2006 08:36:39 +0200, Jan Djärv [EMAIL PROTECTED] said: A signal yes, but I was thinking of this scenario: A Gnome thread does malloc, gets the mutex lock and enters the malloc code. A signal is delivered (in the main thread as you point out) and enters malloc also. This situation is exactly like the one with the lockup, but here we can't use BLOCK_INPUT around the malloc related functions because they are in the Gnome code. I think such a case just behaves like a usual mutual exclusion between multiple threads: one thread acquires a mutex, and the other blocks until it is released. I agree with your assumtion that the lockuo occurs because the signal handler and the interrupted therad are calling pthread_mutex_(un)lock for the same mutex. But BLOCK_INPUT does not help, because Gnome code does not have it. That's not a problem because Gnome threads (non-main threads) never execute pthread_mutex_(un)lock in the signal hander context. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
On Fri, 11 Aug 2006 09:04:34 +0200, David Kastrup [EMAIL PROTECTED] said: YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes: Yes, pthread_mutex_(un)lock is not async-signal-safe. But we are already using such functions as malloc in the signal handler context (with the help of BLOCK_INPUT). I guess calling pthread_mutex_(un)lock in the signal handler context is safe in reality unless the interrupted thread is also executing pthread_mutex_(un)lock for the same mutex. I guess ... safe in reality unless ... Maybe I have been around programmers too long, but I don't find this exactly reassuring. Yeah. IEEE Std 1003.1 provides a table of async-signal-safe functions (those can be called safely within a signal handler), and neither malloc nor pthread_mutex_(un)lock is such functions. All functions not in the above table are considered to be unsafe with respect to signals. In the presence of signals, all functions defined by this volume of IEEE Std 1003.1-2001 shall behave as defined when called from or interrupted by a signal-catching function, with a single exception: when a signal interrupts an unsafe function and the signal-catching function calls an unsafe function, the behavior is undefined. (http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html) We already have malloc calls in the signal handler context with the assumption that it is safe to call unless the signal interrupts malloc-related functions. So I think it's not that bad to also put reasonable assumptions to pthread_mutex_(un)lock. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting ~/Application Data gets ~ instead
Eric Hanchrow wrote: (setenv HOME (getenv USERPROFILE)) This will not affect how Emacs interprets ~/, since you are changing the environment variable HOME after Emacs has already initialized. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
On Fri, 11 Aug 2006 10:09:49 +0200, Jan Djärv [EMAIL PROTECTED] said: That's not a problem because Gnome threads (non-main threads) never execute pthread_mutex_(un)lock in the signal hander context. That does not help, the main thread executes in signal handler context sometimes. And in that case, both the Gnome thread and the signal handler may be executing (un)lock_mutex on the same mutex. I don't think this causes a problem. The signal handler is executed in the main thread that is different from the Gnome thread. And as I quoted from IEEE Std 1003.1 in another message, a pthread_mutex_(un)lock call in the signal hander context should work as usual unless the signal interrupted an unsafe function. The condition unless the signal interrupted an unsafe function is too strict in reality. My guess was that it could be relaxed to unless the signal interrupted a pthread_mutex_(un)lock call for the same mutex. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Multiple runs of menu-bar-update-hook
You can see that both calls have come via redisplay(); the difference is their callers. (Of course both runs of the hook are unnecessary, they have been carried out because windows_or_buffers_changed = 1.) Normally, windows_or_buffers_changed gets cleared near the end of redisplay_internal. Did the first call to redisplay_internal do that? If not, why not? If it did that, where did it get set again before the second call to redisplay? Well, debugging gets a bit weird here. I had to debug it from a second X session, rather than in the same X session in which the debugged emacs is displayed. Otherwise, having the watchpoint seemed to interfere with the sequence of events somehow, and the first break in update_menu_bar() never occurred. Anyhow, with the usual breakpoints wherever the hook is run, and mouse-1 at point in the selected-frame where the buffer is shown in the other frame, I get: (gdb) watch windows_or_buffers_changed Hardware watchpoint 6: windows_or_buffers_changed (gdb) c Continuing. Hardware watchpoint 6: windows_or_buffers_changed Old value = 0 New value = 1 0x001b0868 in modify_overlay (buf=0x481c00, start=27, end=27) at buffer.c:3654 (gdb) list 3649 we must do other windows. */ 3650 if (buf != XBUFFER (XWINDOW (selected_window)-buffer)) 3651windows_or_buffers_changed = 1; 3652 /* If multiple windows show this buffer, we must do other windows. */ 3653 else if (buffer_shared 1) 3654windows_or_buffers_changed = 1; 3655 /* If we modify an overlay at the end of the buffer, we cannot 3656 be sure that window end is still valid. */ 3657 else if (end = ZV start = ZV) 3658windows_or_buffers_changed = 1; (gdb) p buffer_shared $1 = 2 (gdb) where #0 0x001b0868 in modify_overlay (buf=0x481c00, start=27, end=27) at buffer.c:3654 #1 0x001b0f9c in Fmove_overlay (overlay=5796370, beg=216, end=216, buffer=4725764) at buffer.c:3744 #2 0x0024ab58 in Ffuncall (nargs=4, args=0xffbedaf8) at eval.c:2992 #3 0x002a2cb8 in Fbyte_code (bytestr=3724931, vector=3724948, maxdepth=32) at bytecode.c:679 #4 0x0024b5b8 in funcall_lambda (fun=3724876, nargs=4, arg_vector=0xffbeddc4) at eval.c:3169 #5 0x0024ad30 in Ffuncall (nargs=5, args=0xffbeddc0) at eval.c:3028 #6 0x002a2cb8 in Fbyte_code (bytestr=3725379, vector=3725396, maxdepth=48) at bytecode.c:679 #7 0x0024b5b8 in funcall_lambda (fun=3725324, nargs=2, arg_vector=0xffbee094) at eval.c:3169 #8 0x0024ad30 in Ffuncall (nargs=3, args=0xffbee090) at eval.c:3028 #9 0x002a2cb8 in Fbyte_code (bytestr=3724235, vector=3724252, maxdepth=40) at bytecode.c:679 #10 0x0024b5b8 in funcall_lambda (fun=3724196, nargs=1, arg_vector=0xffbee384) at eval.c:3169 #11 0x0024ad30 in Ffuncall (nargs=2, args=0xffbee380) at eval.c:3028 #12 0x00243528 in Fcall_interactively (function=7566081, record_flag=4687873, keys=4747268) at callint.c:880 #13 0x00190a7c in Fcommand_execute (cmd=7566081, record_flag=4687873, keys=4687873, special=4687873) at keyboard.c:9797 #14 0x0017b290 in command_loop_1 () at keyboard.c:1790 #15 0x00246eb4 in internal_condition_case (bfun=0x17910c command_loop_1, handlers=4752009, hfun=0x178734 cmd_error) at eval.c:1469 #16 0x00178dd8 in command_loop_2 () at keyboard.c:1326 #17 0x00246644 in internal_catch (tag=4746241, func=0x178dac command_loop_2, arg=4687873) at eval.c:1210 #18 0x00178d50 in command_loop () at keyboard.c:1305 #19 0x00178280 in recursive_edit_1 () at keyboard.c:1003 #20 0x001784e0 in Frecursive_edit () at keyboard.c:1064 #21 0x001760a4 in main (argc=2, argv=0xffbeecb4) at emacs.c:1794 Lisp Backtrace: move-overlay (0x587212) mouse-move-drag-overlay (0x587212) mouse-drag-track (0x67e525) mouse-drag-region (0x67e525) call-interactively (0x737301) (gdb) c Continuing. Breakpoint 5, update_menu_bar (f=0x6d9200, save_match_data=0, hooks_run=0) at xdisp.c:9195 (gdb) where #0 update_menu_bar (f=0x6d9200, save_match_data=0, hooks_run=0) at xdisp.c:9195 #1 0x000806ac in prepare_menu_bars () at xdisp.c:9073 #2 0x00085810 in redisplay_internal (preserve_echo_area=1) at xdisp.c:10902 #3 0x0008745c in redisplay_preserve_echo_area (from_where=6) at xdisp.c:11512 #4 0x001809cc in tracking_off (old_value=4687873) at keyboard.c:3474 #5 0x0024bf70 in unbind_to (count=27, value=4687873) at eval.c:3337 #6 0x00180a80 in Ftrack_mouse (args=3725805) at keyboard.c:3499 #7 0x00248fe8 in Feval (form=3725797) at eval.c:2260 #8 0x00244430 in Fprogn (args=3725789) at eval.c:435 #9 0x0024b554 in funcall_lambda (fun=3725773, nargs=0, arg_vector=0xffbeddc4) at eval.c:3162 #10 0x0024ae14 in Ffuncall (nargs=1, args=0xffbeddc0) at eval.c:3039 #11 0x002a2cb8 in Fbyte_code (bytestr=3725379, vector=3725396, maxdepth=48) at bytecode.c:679 #12 0x0024b5b8 in funcall_lambda (fun=3725324, nargs=2, arg_vector=0xffbee094) at eval.c:3169 #13 0x0024ad30 in Ffuncall (nargs=3, args=0xffbee090) at eval.c:3028 #14 0x002a2cb8 in Fbyte_code (bytestr=3724235,
Re: visiting ~/Application Data gets ~ instead
From: Eric Hanchrow [EMAIL PROTECTED] Date: Thu, 10 Aug 2006 17:49:58 -0700 * paste or type this into the *scratch* buffer, and hit C-x C-e (progn (setenv HOME (getenv USERPROFILE)) ;;(setq abbreviated-home-dir nil) (let ((home (find-file-noselect ~/)) (ad (find-file-noselect ~/Application Data/))) (when (eq home ad) (error Aha. We found the bug.)) (message I guess the bug is fixed or hidden.))) I predict you'll see the error Aha. We found the bug. I think this is a bug because I've changed the HOME variable to be c:/Documents and Settings/erich/ setenv only changes the environment passed to child processes that Emacs runs, but does not change Emacs's own environment. So this behavior is quite intentional. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Error during ask-user-about-lock
I was afraid your question was going to be WHY does Emacs get a drag'n'drop event?, because I don't know the answer (and it doesn't make much sense to me). It is an interesting question, because if you didn't try to do a drag'n'drop, the event could reflect a bug. But you COULD have done a real drag'n'drop, and generated a legitimate drag-and-drop event. So the question of how to handle one still exists. I will install my patch if no one objects in the next few days. I don't have any strong objection to the patch other than the fact that it feels wrong: DND events are normal user-initiated commands so I think they should be handled normally. The special-event-map seems to me more intended to handle internal events that do not correspond to user actions (or do correspond, but only indirectly). Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting ~/Application Data gets ~ instead
(let ((home (find-file-noselect ~/)) (ad (find-file-noselect ~/Application Data/))) (when (eq home ad) (error Aha. We found the bug.)) [...] setenv only changes the environment passed to child processes that Emacs runs, but does not change Emacs's own environment. So this behavior is quite intentional. This doesn't explain why (find-file-noselect ~/) and (find-file-noselect ~/Application Data/) return the same buffer. Shouldn't they be differnet no matter what ~ expands to? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting ~/Application Data gets ~ instead
[EMAIL PROTECTED] wrote: This doesn't explain why (find-file-noselect ~/) and (find-file-noselect ~/Application Data/) return the same buffer. Shouldn't they be differnet no matter what ~ expands to? find-file-noselect calls (abbreviate-file-name (expand-file-name FILE)), where expand-file-name is implemented in C and uses egetenv(HOME) to expand ~, while abbreviate-file-name compares against lisp variable abbreviated-home-dir, so if HOME is changed from inside Emacs, these two functions are not going to be consistent with each other. This doesn't explain the above by itself, but I'm sure if you dived deeper you would find the explanation. The question is - is this worth fixing? Is it reasonable for the user to change the environment variable HOME from within Emacs? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting ~/Application Data gets ~ instead
From: Eric Hanchrow [EMAIL PROTECTED] Date: Fri, 11 Aug 2006 06:37:49 -0700 But it does affect expand-file-name: (getenv HOME) /home/erich (expand-file-name ~) /home/erich (setenv HOME squawk) squawk (expand-file-name ~) squawk Maybe this is the bug: maybe setting HOME shouldn't affect expand-file-name. (Although I admit that it sounds quite unusual to me that someone would like to redirect HOME from within Emacs.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ibuffer's s v doesn't redraw buffer
* I started emacs with emacs -Q * I loaded ibuffer: M-x load-libraryreturnibufferreturn * I ran ibuffer: M-x ibufferreturn * I sorted the buffer by major mode: s m I note that after I type the m, the buffer is immediately redrawn, with the entries in their new order. * I sorted the buffer by recency: s v I note that the buffer hasn't changed. * I force the buffer to change: g Now the buffer looks the way I'd expect it to. If emacs crashed, and you have the emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /usr/local/src/emacs-cvs/etc/DEBUG for instructions. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-07-27 on debian X server distributor `The X.Org Foundation', version 11.0.7000 configured using `configure '--enable-maintainer-mode'' 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.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: M-x r e p o r t - e m a c s - b u f tab return backspace g tab return Recent messages: (/usr/local/src/emacs-cvs/src/emacs -Q) For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done -- Two degrees in be-bop, a Ph.D. in swing -- Lowell George, Fred Martin ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting ~/Application Data gets ~ instead
Eli == Eli Zaretskii [EMAIL PROTECTED] writes: Eli Maybe this is the bug: maybe setting HOME shouldn't affect Eli expand-file-name. At least, if that were the case, Emacs would be consistent, and I wouldn't have been seduced into setting it from within Emacs in the first place. Eli (Although I admit that it sounds quite unusual to me that Eli someone would like to redirect HOME from within Emacs.) (I forgot to send this to the list (I merely hit the reply key in my mailer, so it went only to Jason)): For what it's worth, here's why I did just that: I didn't like Emacs' default choice for HOME -- %USERPROFILE%\Application Data. And I didn't want to set that variable in the environment globally, because I was afraid it would screw up other programs (I can't remember which programs, exactly, but I suspect I may have been thinking of Cygwin). And since I prefer coding in Emacs Lisp to writing Windows batch files, I chose to set the variable in elisp, rather than writing a batch file wrapper for Emacs that first sets HOME and then invokes Emacs. It never occurred to me that there'd be this subtle and hidden inconsistency between find-file-noselect and abbreviated-home-dir. -- When I just need to kick back after a long day of changing 1.s into 0.s and 0.s into 1.s, nothing satisfies my primal fish urge better than a can of Genova [tuna]. -- Ben Collins-Sussman ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
desktop file isn't loaded at startup
I created a desktop file like this: $ cd $ /usr/local/src/emacs-cvs/src/emacs -Q -nw C-x C-f find-file RET /tmp/x RET M-x desktop-save RET /~/ RET C-x C-x Note that I do have a file named /tmp/x, and that it's readable by me. I confirmed that the desktop file existed and had reasonable-looking contents: $ cd $ head .emacs.desktop ;; -*- mode: emacs-lisp; coding: emacs-mule; -*- ;; -- ;; Desktop File for Emacs ;; -- ;; Created Fri Aug 11 10:35:27 2006 ;; Desktop file format version 206 ;; Emacs version 22.0.50.1 ;; Global section: (setq desktop-missing-file-warning nil) I started Emacs once again: $ /usr/local/src/emacs-cvs/src/emacs -Q -nw I then checked to see if the file /tmp/x had been loaded; it hadn't. I looked in the *Messages* buffer for evidence of the desktop having gotten loaded, but I didn't see any; I merely saw (/usr/local/src/emacs-cvs/src/emacs -Q) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. I suspect the manual is simply wrong when it says When Emacs starts, it looks for a saved desktop in the current directory. If emacs crashed, and you have the emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /usr/local/src/emacs-cvs/etc/DEBUG for instructions. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-07-27 on debian configured using `configure '--enable-maintainer-mode'' 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.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: encoded-kbd-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: ESC x r e p o e DEL r t - e m a c s - b u g RET Recent messages: (/usr/local/src/emacs-cvs/src/emacs -Q) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. 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: Error during ask-user-about-lock
I don't have any strong objection to the patch other than the fact that it feels wrong: DND events are normal user-initiated commands so I think they should be handled normally. The idea of special-event-map is to handle events that are solitaries and could arrive in the middle of a key sequence. I think this case fits. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Multiple runs of menu-bar-update-hook
Breakpoint 5, update_menu_bar (f=0x6d9200, save_match_data=0, hooks_run=0) at xdisp.c:9195 (gdb) where #0 update_menu_bar (f=0x6d9200, save_match_data=0, hooks_run=0) at xdisp.c:9195 #1 0x000806ac in prepare_menu_bars () at xdisp.c:9073 #2 0x00085810 in redisplay_internal (preserve_echo_area=1) at xdisp.c:10902 #3 0x0008745c in redisplay_preserve_echo_area (from_where=6) at xdisp.c:11512 Lisp Backtrace: track-mouse (0x38d9ed) 0x38d9cd Lisp type 5 mouse-drag-track (0x67e525) mouse-drag-region (0x67e525) call-interactively (0x737301) (gdb) c Continuing. Breakpoint 5, update_menu_bar (f=0x6d9200, save_match_data=0, hooks_run=0) at xdisp.c:9195 (gdb) where #0 update_menu_bar (f=0x6d9200, save_match_data=0, hooks_run=0) at xdisp.c:9195 #1 0x000806ac in prepare_menu_bars () at xdisp.c:9073 #2 0x00085810 in redisplay_internal (preserve_echo_area=0) at xdisp.c:10902 #3 0x00083ecc in redisplay () at xdisp.c:10491 #4 0x0017dba4 in read_char (commandflag=1, nmaps=2, maps=0xffbee3d8, For cases like this, typing `c' does not get precise information. If you see foo called from bar each time, you can't tell if it is the same call to bar, or a second call to bar. To find that out, use the `finish' command frame by frame, or use stepping. In trying to anwswer your question as to why redisplay_internal() did not reset windows_or_buffers_changed, I tried breakpoints in various places in redisplay_internal() and redisplay(). This proved difficult, as it was not easy to put a breakpoint where it would not repeatedly be triggered. Don't use breakpoints for a job like this! Use stepping! Lisp Backtrace: track-mouse (0x38d9ed) 0x38d9cd Lisp type 5 mouse-drag-track (0x553c05) mouse-drag-region (0x553c05) call-interactively (0x737301) (gdb) c Continuing. Hardware watchpoint 6: windows_or_buffers_changed Old value = 0 New value = 1 That might be what we need to know. mouse-drag-region has to call delete-overlay. So it isn't a bug. Just the lack of optimization in this case. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
doc string of mouse-position doesn't say what X and Y are
Here's the doc string. There is nothing here that tells you the X is across the screen (horizontal) and Y is down the screen (vertical). All it says is that X,Y=0,0 is at the top left. Yes, you can look up other doc to find out what is meant by position and character cell, but this explanation might as well be self-contained. Return a list (FRAME X . Y) giving the current mouse frame and position. The position is given in character cells, where (0, 0) is the upper-left corner. If Emacs is running on a mouseless terminal or hasn't been programmed to read the mouse position, it returns the selected frame for FRAME and nil for X and Y. If `mouse-position-function' is non-nil, `mouse-position' calls it, passing the normal return value to that function as an argument, and returns whatever that function returns. In GNU Emacs 22.0.50.1 (i386-msvc-nt5.1.2600) of 2006-07-19 on BOS-CTHEWLAP2 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-msvc (12.00)' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: help-echo help-echo down-mouse-1 mouse-1 C-h f m o s backspace backspace o u s e - p o s i t i o n return help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-b ug Recent messages: (C:\Emacs-22-2006-07-19-Fran\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done Loading help-fns...done Type C-x 1 to remove help window. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [PATCH] another possible behavior for ido-enter-matching-directory
Matthieu Moy [EMAIL PROTECTED] writes:
./XXX/{XXX-aaa,XXX-bbb,XXX-ccc,XXX}
and I have no fast way to open XXX itself, while it would have been
trivial to open it without ido.
C-j
I propose a new possible value for ido-enter-matching-directory, which
enters the directory when there is an exact match, whether or not it's
the first. In the case above, I type the slash after having typed XXX
which is the exact name of a directory, so we enter this directory. If
we want to open another directory, we have to type some more
characters before typing the slash. Below is a patch implementing
this.
Thanks for the idea. I'll consider it.
--- ido.el.orig
+++ ido.el
@@ -742,11 +742,15 @@
If value is 'first, enter first matching sub-directory when typing a slash.
If value is 'only, typing a slash only enters the sub-directory if it is
the only matching item.
+If value is 'exact, enter the directory if it is an exact match (even
+ if there are other possibilities and even if the match is not the
+ first choice).
If value is t, automatically enter a sub-directory when it is the only
matching item, even without typing a slash.
:type '(choice (const :tag Never nil)
(const :tag Slash enters first directory first)
(const :tag Slash enters first and only directory only)
+(const :tag Slash enters directory on exact match exact)
(other :tag Always enter unique directory t))
:group 'ido)
@@ -4180,6 +4184,13 @@
(ido-set-current-directory
(concat ido-current-directory (file-name-directory contents)))
(setq refresh t))
+ ((and (eq ido-enter-matching-directory 'exact)
+ (member contents ido-matches))
+(ido-trace exact match (car ido-matches))
+(ido-set-current-directory
+ (concat ido-current-directory contents))
+(setq ido-exit 'refresh)
+(exit-minibuffer))
(t
(ido-trace try single dir)
(setq try-single-dir-match t
--
Matthieu
--
Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Error during ask-user-about-lock
I don't have any strong objection to the patch other than the fact that it feels wrong: DND events are normal user-initiated commands so I think they should be handled normally. The idea of special-event-map is to handle events that are solitaries and could arrive in the middle of a key sequence. I think this case fits. Hmm... I thought that was exactly my point: DND events, being user-initiated, should *not* arrive in the middle of a key sequence. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting ~/Application Data gets ~ instead
This doesn't explain why (find-file-noselect ~/) and (find-file-noselect ~/Application Data/) return the same buffer. Shouldn't they be differnet no matter what ~ expands to? find-file-noselect calls (abbreviate-file-name (expand-file-name FILE)), where expand-file-name is implemented in C and uses egetenv(HOME) to expand ~, while abbreviate-file-name compares against lisp variable abbreviated-home-dir, so if HOME is changed from inside Emacs, these two functions are not going to be consistent with each other. This doesn't explain the above by itself, but I'm sure if you dived deeper you would find the explanation. That sounds credible, although it may be completely unrelated. E.g. I can't reproduce the problem on my GNU/Linux machine. The question is - is this worth fixing? Is it reasonable for the user to change the environment variable HOME from within Emacs? Of course it is reasonable. Maybe not an important case, tho, Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting ~/Application Data gets ~ instead
Stefan == Stefan Monnier [EMAIL PROTECTED] writes: I didn't like Emacs' default choice for HOME -- %USERPROFILE%\Application Data. Stefan Since when is that the default? * Changes in Emacs 22.1 on non-free operating systems +++ ** The HOME directory defaults to Application Data under the user profile. -- When a cryptographer and a symbologist get together, it usually ends in tears. A. O. Scott, reviewing 'The Da Vinci Code' in the New York Times ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting ~/Application Data gets ~ instead
For what it's worth, this patch seems to make Emacs work as I'd
expect:
--- w32.c 21 Jul 2006 10:27:34 -0700 1.105
+++ w32.c 11 Aug 2006 16:04:12 -0700
@@ -999,10 +999,10 @@
if (get_folder_path != NULL)
{
- profile_result = get_folder_path (NULL, CSIDL_APPDATA, NULL,
+ profile_result = get_folder_path (NULL, CSIDL_PROFILE, NULL,
0, default_home);
- /* If we can't get the appdata dir, revert to old behaviour. */
+ /* If we can't get the profile dir, revert to old behaviour. */
if (profile_result == S_OK)
env_vars[0].def_value = default_home;
}
--
I hope to get back to work on Arc soon.
-- Paul Graham, quoted in ACM Crossroads, no date given
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting ~/Application Data gets ~ instead
Stefan == Stefan Monnier [EMAIL PROTECTED] writes: I didn't like Emacs' default choice for HOME -- %USERPROFILE%\Application Data. Stefan Since when is that the default? revision 1.95 date: 2005-07-14 22:31:57 +; author: jasonr; state: Exp; lines: +37 -2 (init_environment): Default HOME directory to user's appdata directory if possible. -- It has been suggested that this article or section be merged into Fried dough. (Discuss) -- Seen on Wikipedia ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: reproducible cygwin memory problems
Eli, is this relevant? http://www.cygwin.com/ml/cygwin/1999-04/msg00513.html From: Eli Zaretskii [EMAIL PROTECTED] Reply-To: Eli Zaretskii [EMAIL PROTECTED] To: emacs user [EMAIL PROTECTED] CC: emacs-pretest-bug@gnu.org Subject: Re: reproducible cygwin memory problems Date: Thu, 10 Aug 2006 22:33:42 +0300 From: emacs user [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Bcc: Date: Thu, 10 Aug 2006 01:06:22 -0400 #kill it #(clear-image-cache t) I am here1 I am here2 I am here4 I am here5 I am here6 I am here5 I am here6 Okay, thanks. This shows that free_image does get called. What image types did you try till now? If you tried with only one image type, please see if other image types exhibit the same problem (i.e. that memory is not returned to system when an image is killed and the image cache cleared). If you already tried all the supported image types, I cannot think of any reason but one: that the Cygwin implementation of malloc/free does not return freed memory to the OS. If this is the conclusion, then it should probably be taken up with Cygwin maintainers on their mailing list. _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting ~/Application Data gets ~ instead
I didn't like Emacs' default choice for HOME -- %USERPROFILE%\Application Data. Stefan Since when is that the default? * Changes in Emacs 22.1 on non-free operating systems +++ ** The HOME directory defaults to Application Data under the user profile. Huh? I thought we had agreed to use %USERPROFILE% instead (which is usually closer to Unix's $HOME). Jason? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: reproducible cygwin memory problems
Dear cygwin friends, while debugging some emacs related problem, we seem to come to the conclusion that there is a cygwin issue here. can someone please comment on this? From: Eli Zaretskii [EMAIL PROTECTED] From: emacs user [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Bcc: Date: Thu, 10 Aug 2006 01:06:22 -0400 #kill it #(clear-image-cache t) I am here1 I am here2 I am here4 I am here5 I am here6 I am here5 I am here6 Okay, thanks. This shows that free_image does get called. What image types did you try till now? If you tried with only one image type, please see if other image types exhibit the same problem (i.e. that memory is not returned to system when an image is killed and the image cache cleared). problem occurs with both jpeg and gif. I didnt try others If you already tried all the supported image types, I cannot think of any reason but one: that the Cygwin implementation of malloc/free does not return freed memory to the OS. If this is the conclusion, then it should probably be taken up with Cygwin maintainers on their mailing list. cygwin list copied above _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
