Re: Point of wrong window used in read-from-minibuffer?
As I said, I agree with the general idea that save-window-excursion shouldn't affect point, but I indeed think it's more important that it shouldn't cause any window's cursor to move. Copying the value of one window's point to another window's point is (to me) always a bug. So, yes, I really think it should be changed. I doubt it's risky, but there's no hurry, so we can keep it for post-22. I am sure it is risky. There is, or was, code that depended on the precise details of this behavior. Perhaps none will break with the specific change that you have in mind. Or perhaps yes some will break. We don't know--so it is risky. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
I have a hard time believing you tyhink this behavior is desirable. So just to double check: you do realize I'm talking about the window's cursor. I am not sure if that statement is meaningful. Remember, the window's point value is never in use for the selected window. It is relevant only in windows that are nonselected. save-window-excursion is currently defined to preserve the buffer's point value even when it switches windows. This is indeed somewhat strange, since ordinarily switching windows swaps the buffer's point value into the old window and swaps the new window's point value into the buffer. Maybe it should be changed. But changing it is somewhat risky, too. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
I have a hard time believing you tyhink this behavior is desirable. So just to double check: you do realize I'm talking about the window's cursor. I am not sure if that statement is meaningful. Remember, the window's point value is never in use for the selected window. I know the two are intricately linked, of course. But then trying to come up with a sensible spec, I think it's best to start by separating those concerns. I'm *not* talking so much about operational details of the behavior as about the general user-level behavior. From the users's perspective point barely exists (most users only care about the windows's cursors), and users have no clue that the window's point value is never in use for the selected window. save-window-excursion is currently defined to preserve the buffer's point value even when it switches windows. This is indeed somewhat strange, since ordinarily switching windows swaps the buffer's point value into the old window and swaps the new window's point value into the buffer. Maybe it should be changed. But changing it is somewhat risky, too. As I said, I agree with the general idea that save-window-excursion shouldn't affect point, but I indeed think it's more important that it shouldn't cause any window's cursor to move. Copying the value of one window's point to another window's point is (to me) always a bug. So, yes, I really think it should be changed. I doubt it's risky, but there's no hurry, so we can keep it for post-22. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
I'm saying that changing it to (save-excursion (save-window-excursion (select-window (next-window ought to solve the problem too, and the approach is less risky. That's true. But what about: (save-window-excursion (forward-char 1) (select-window (next-window))) I'd expect this to move the window's cursor by one char. No, that is not what it should do. (select-window (next-window)) positions point at the position for the other window, and that is the value that should remain in effect. So I think there is no bug here. I have a hard time believing you tyhink this behavior is desirable. So just to double check: you do realize I'm talking about the window's cursor. Not the buffer's point. Whether the buffer's point is changed or not doesn't bother me. Another way to look at the problem: A save-selected-window around a save-window-excursion is redundant because save-window-excursion saves/restores the selected window. I.e. (save-selected-window (save-window-excursion BODY)) == (save-window-excursion BODY) Yet the reverse is not true (with the current code): (save-window-excursion (save-selected-window BODY)) =/= (save-window-excursion BODY) I find this very unintuitive at least, and inconvenient in the above case. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
I'm saying that changing it to (save-excursion (save-window-excursion (select-window (next-window ought to solve the problem too, and the approach is less risky. That's true. But what about: (save-window-excursion (forward-char 1) (select-window (next-window))) I'd expect this to move the window's cursor by one char. No, that is not what it should do. (select-window (next-window)) positions point at the position for the other window, and that is the value that should remain in effect. So I think there is no bug here. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
I think I agree now that the patch you installed is a bug fix and correct. Good, thanks. The problem that point moves after (save-window-excursion (select-window (next-window))) That's the problem I saw reported. No, the problem is not that point is moved, but that the window's cursor is moved. The two are clearly related, of course. I'm saying that changing it to (save-excursion (save-window-excursion (select-window (next-window ought to solve the problem too, and the approach is less risky. That's true. But what about: (save-window-excursion (forward-char 1) (select-window (next-window))) I'd expect this to move the window's cursor by one char. With the current behavior, the cursor is moved to the same spot as the one on the other window, which is not what we want, and wrapping it with save-excursion is not what we want either. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
If you try my example again: % emacs -Q [ type in some random text] C-x 2 [ move point elsewhere ] M-: (save-window-excursion (select-window (next-window))) RET you'll see that at the end the second window's point is being set to the value of the first window's point. I see what behavior you mean, but that is not the way to understand it. It doesn't concern the second window's point, or the first window's point, because neither of them is in use at the time in question. Before exit from the save-window-excursion, the first window's point is not in use, because it's the selected window. The current buffer's own value of point is the one that takes effect. After exit from the save-window-excursion, the second window is selected, so its point value is not in use. The current buffer's own value of point continues to be the one that takes effect. It happens that the current buffer's own value of point is unchanged through this process, because save-window-excursion is not supposed to restore that. It is supposed to leave that value alone, and it does. (Or rather, it did so before you made a change.) I agree that the current behavior is counterintuitive in this case. Perhaps a different behavior would be better. However, in order to consider a different behavior, we have to have a clear picture of it. What behavior does your patch result in? We need to be able to document it clearly and in general. Also, there's the possibility that this change will break some code. Some uses of save-window-excursion expect to do (goto-char ...) inside the save-window-excursion and have point still be at that place outside the save-window-excursion. That's the kind of case that this patch could break. Maybe there are no cases that in fact would break. Maybe the places that do that don't switch windows in a way that could cause trouble. But it leads me to ask: does putting (save-excursion ...) around the call to save-window-excursion fix the problem? ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
the patch fixes the reduced error, but not the original problem.
Can you try the patch below instead?
It seems to fix it for me *and* it explains why font-lock-mode is
a necessary ingredient.
Stefan
--- window.c02 mar 2005 22:20:12 -0500 1.496
+++ window.c12 avr 2005 08:17:51 -0400
@@ -5589,6 +5591,17 @@
{
if (XBUFFER (new_current_buffer) == current_buffer)
old_point = PT;
+ else
+ /* BUF_PT (XBUFFER (new_current_buffer)) gives us the position of
+ point in new_current_buffer as of the last time this buffer was
+ used. This can be non-deterministic since it can be changed by
+ things like jit-lock by mere temporary selection of some random
+ window that happens to show this buffer.
+ So if possible we want this arbitrary choice of which point to
+ be the one from the to-be-selected-window so as to prevent this
+ window's cursor from being copied from another window. */
+ if (EQ (XWINDOW (data-current_window)-buffer, new_current_buffer))
+ old_point = XMARKER (XWINDOW (data-current_window)-pointm)-charpos;
else
old_point = BUF_PT (XBUFFER (new_current_buffer));
}
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
On Tue, Apr 12, 2005 at 08:27:17AM -0400, Stefan Monnier wrote: Can you try the patch below instead? It seems to fix it for me *and* it explains why font-lock-mode is a necessary ingredient. Yes, it works perfectly. Thanks a lot! Ulf -- Jabber-ID: [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
I don't know how to fix it, but I've traced it to the following problem: % emacs -Q [ type in some random text] C-x 2 [ move point elsewhere ] M-: (save-window-excursion (select-window (next-window))) RET after the M-: command, point in the second window is set back to the same position as it is in the first window. This is not a bug. It is actually documented: DEFUN (current-window-configuration, Fcurrent_window_configuration, Scurrent_window_configuration, 0, 1, 0, doc: /* Return an object representing the current window configuration of FRAME. If FRAME is nil or omitted, use the selected frame. This describes the number of windows, their sizes and current buffers, and for each displayed buffer, where display starts, and the positions of point and mark. An exception is made for point in the current buffer: its value is -not- saved. This feature is somewhat inconsistent, and one could argue for changing it. Removing this exception would certainly make things simpler. ISTR that I arrived at this exception in the late 80s as I was trying to aim for consistent and predictable behavior. One argument in favor of the exception is that you can always put save-excursion around the save-window-excursion, if you want to save the current buffer's point value. Thus, the existence of this exception makes it easy to get both behaviors. One argument in favor of removing the exception is that perhaps the current behavior of save-window-excursion isn't useful. Perhaps removing the exception would make everyone happier. Another argument is that the places which benefitted from not saving and restoring point could now use save-selected-window (which did not exist back then). And maybe they already do. However, there is a risk this change would break who-knows-what. I think it is better to play safe and not change this. I added comments to the code which I think will make this clearer. So could you fix the original bug by adding a call to save-excursion? ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
I don't know how to fix it, but I've traced it to the following problem:
% emacs -Q
[ type in some random text]
C-x 2
[ move point elsewhere ]
M-: (save-window-excursion (select-window (next-window))) RET
after the M-: command, point in the second window is set back to the same
position as it is in the first window.
This is not a bug. It is actually documented:
DEFUN (current-window-configuration, Fcurrent_window_configuration,
Scurrent_window_configuration, 0, 1, 0,
doc: /* Return an object representing the current window
configuration of FRAME.
If FRAME is nil or omitted, use the selected frame.
This describes the number of windows, their sizes and current buffers,
and for each displayed buffer, where display starts, and the positions of
point and mark. An exception is made for point in the current buffer:
its value is -not- saved.
This feature is somewhat inconsistent, and one could argue for
changing it. Removing this exception would certainly make things
simpler. ISTR that I arrived at this exception in the late 80s
as I was trying to aim for consistent and predictable behavior.
I don't think the behavior in my above example is consistent
and predictable: it doesn't happen if the two windows displaying the buffer
are on different frames, it doesn't happen if current-buffer is displayed
in one or zero windows on the frame, ...
The patch below fixes the above buggy behavior.
I think it preserves the current behavior in all other cases.
Stefan
--- window.c02 mar 2005 22:20:12 -0500 1.496
+++ window.c11 avr 2005 00:50:28 -0400
@@ -5589,7 +5589,20 @@
else
{
if (XBUFFER (new_current_buffer) == current_buffer)
+ {
+ /* The code further down is careful to preserve point in current
+buffer (if current-buffer is equal to new_current_buffer), but
+that ends up moving the window's point if the selected-window
+before and after both display current-buffer but aren't the
+same window. So to work around this, in this specific case we
+restore the selected window first. */
+ if (XBUFFER (XWINDOW (data-current_window)-buffer)
+ == current_buffer
+ WINDOWP (selected_window)
+ XBUFFER (XWINDOW (selected_window)-buffer) == current_buffer)
+ Fselect_window (data-current_window, Qnil);
old_point = PT;
+ }
else
old_point = BUF_PT (XBUFFER (new_current_buffer));
}
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
Hi, Stefan Monnier [EMAIL PROTECTED] schrieb am 05.04.05 00:52:22: - Load a vhdl file - Divide emacs into two windows vertically, both showing the same buffer - Jump to the end of the buffer in the upper window - Switch to the lower window, near the beginning - Type signal (with a space afterwards), this triggers the template insertion mechanism for a signal - type any name at the minibuffer prompt, eg. test and press return. - type any type at the minibuffer prompt, eg. std_logic and press return. - ! The region between the signal and the point in the other buffer is deleted ! - type any initialization value at the minibuffer prompt and press return. - Error message: byte-code: Invalid search bound (wrong side of point) Can't reproduce it here. I tried a few different cases but can't seem to trigger the behavior you describe. Looking at the code, the only place that might look suspicious is the TAB expansion in the prompt, but even that seems to work fine. Can you try and give an even more precise recipe starting from emacs -Q ~/tmp/newfile.vhdl ? Yes, the error does not occur with -Q. I analyzed my .emacs to find the offending setting, the problem is triggered by the following initialization: (custom-set-variables '(global-font-lock-mode t nil (font-lock)) ) A colleague tried it and came to the same conclusion: the problem occurs as soon as global font-lock is used. Ulf __ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
The problem is triggered in vhdl-template-field, it seems that read-from-minibuffer switches to the point position of the wrong window. I don't know how to fix it, but I've traced it to the following problem: % emacs -Q [ type in some random text] C-x 2 [ move point elsewhere ] M-: (save-window-excursion (select-window (next-window))) RET after the M-: command, point in the second window is set back to the same position as it is in the first window. If we do M-: (save-window-excursion (let ((win (selected-window))) (select-window (next-window)) (select-window win))) RET instead, it works correctly. So it seems to be a problem in set-window-configuration, but the code there is sufficiently tricky that I can't find the problem off hand. And I won't have time to delve into it any time soon. Can someone else take a look at it? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
