From: martin rudalics <rudalics@gmx.at>
To: Steve Hafner <steve.b.hafner@gmail.com>
Cc: 12208@debbugs.gnu.org
Subject: bug#12208: yes-or-no-p escapes with-current-buffer
Date: Fri, 17 Aug 2012 14:09:38 +0200 [thread overview]
Message-ID: <502E3482.5060300@gmx.at> (raw)
In-Reply-To: <CAOy7MZJFxyF4JrZr9ep7RacZs=-Kayzc_uGUiRhZU=U6LniWeA@mail.gmail.com>
> Thanks for the examples.
I wrote them as a first step in order to uncouple the behavior you
observed from `yes-or-no-p'.
> If I understand correctly,
> save-window-excursion ends with among other things restoring the
> window points; and each time a window point is set, the buffer point
> is set as well.
Conceptually, for any non-selected window, it should restore
`window-point' but leave `point' for that window's buffer alone. For
the selected window, it should leave `point' where it is. The problem
seems to occur only when the selected window's buffer is not current at
the time the configuration is saved.
> And while the current buffer is restored,
> save-window-excursion does not restore the point in the current
> buffer, leaving it at the position set by the window point restore, if
> there was one.
Did you read the code? Can you tell me where it does do that "window
point restore" which also sets the buffer's `point'?
> What I don't understand is the rationale for not
> restoring the current buffer point. Perhaps it's just windows have
> precedence in a restore.
I've never been able to fully understand neither the purpose nor the
actual implementation of this. The patch below seems to make it go away
in your case but I have no idea whether it breaks something else.
martin
=== modified file 'src/window.c'
--- src/window.c 2012-08-16 07:58:24 +0000
+++ src/window.c 2012-08-17 11:56:55 +0000
@@ -5636,8 +5636,9 @@
/* As documented in Fcurrent_window_configuration, don't
restore the location of point in the buffer which was
current when the window configuration was recorded. */
- if (!EQ (p->buffer, new_current_buffer)
- && XBUFFER (p->buffer) == current_buffer)
+ if (EQ (p->buffer, new_current_buffer))
+ Fgoto_char (make_number (old_point));
+ else if (XBUFFER (p->buffer) == current_buffer)
Fgoto_char (w->pointm);
}
else if (!NILP (w->buffer)
next prev parent reply other threads:[~2012-08-17 12:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 4:37 bug#12208: yes-or-no-p escapes with-current-buffer Steve Hafner
2012-08-16 9:38 ` martin rudalics
2012-08-16 20:36 ` Steve Hafner
2012-08-17 12:09 ` martin rudalics [this message]
2012-08-17 15:18 ` martin rudalics
2012-08-17 20:24 ` Steve Hafner
2012-08-18 2:55 ` Steve Hafner
2012-08-18 13:15 ` martin rudalics
2012-08-18 16:39 ` Steve Hafner
2012-08-18 17:38 ` martin rudalics
2012-08-27 9:15 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=502E3482.5060300@gmx.at \
--to=rudalics@gmx.at \
--cc=12208@debbugs.gnu.org \
--cc=steve.b.hafner@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).