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.

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

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

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

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)))

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

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

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

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]

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

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

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

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-: