From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Tue, 08 Jun 2010 15:06:48 +0200 Message-ID: <4C0E4068.1000604@gmx.at> References: <4BB4CF6B.2000007@alice.it> <87vdb2qo82.fsf@mail.jurta.org> <4BE27C17.3030005@gmx.at> <87vdav4vx5.fsf@mail.jurta.org> <4BE900E7.3090402@gmx.at> <87r5liqv8f.fsf@mail.jurta.org> <4BEA74DC.2060103@gmx.at> <87y6fns8qo.fsf@mail.jurta.org> <4BECF4D6.9030707@gmx.at> <87632na2af.fsf@mail.jurta.org> <4C03F1B5.8040708@gmx.at> <4C04D1BF.9070902@gmx.at> <87zkzcse1j.fsf@mail.jurta.org> <4C08B53C.7040304@gmx.at> <877hmezpvu.fsf@mail.jurta.org> <4C0A47BF.7010202@gmx.at> <87d3w5nuki.fsf@mail.jurta.org> <4C0B7AA6.2090400@gmx.at> <4C0CF6EB.8010705@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1276003274 22888 80.91.229.12 (8 Jun 2010 13:21:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 8 Jun 2010 13:21:14 +0000 (UTC) Cc: Juri Linkov , Emacs To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 08 15:21:13 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OLyjr-0002MG-D6 for ged-emacs-devel@m.gmane.org; Tue, 08 Jun 2010 15:21:07 +0200 Original-Received: from localhost ([127.0.0.1]:35907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OLyjq-0001L1-L6 for ged-emacs-devel@m.gmane.org; Tue, 08 Jun 2010 09:21:06 -0400 Original-Received: from [140.186.70.92] (port=57378 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OLyWx-0004kN-H7 for emacs-devel@gnu.org; Tue, 08 Jun 2010 09:11:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OLyWC-0000sf-EI for emacs-devel@gnu.org; Tue, 08 Jun 2010 09:07:08 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:38096) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OLyWC-0000sM-17 for emacs-devel@gnu.org; Tue, 08 Jun 2010 09:07:00 -0400 Original-Received: (qmail invoked by alias); 08 Jun 2010 13:06:57 -0000 Original-Received: from 62-47-54-87.adsl.highway.telekom.at (EHLO [62.47.54.87]) [62.47.54.87] by mail.gmx.net (mp024) with SMTP; 08 Jun 2010 15:06:57 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+X66chxLOX2zyiondi0s5HLQmoeJslWxUgeLapx/ WXVwdImSkUl7bQ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125632 Archived-At: > I know. Maybe we should "fix it", as you implicitly suggested, by > simply always doing a set-buffer. It's fairly risky, kind of like > replacing every (save-excursion (set-buffer foo) bar) with > (with-current-buffer foo bar) ;-) I haven't looked into the calls in xdisp.c but I hope you're right ;-) Vivisecting Fselect_window reveals at least three suspicious components. ------------------------------------------------------------------------ /* Store the current buffer's actual point into the old selected window. It belongs to that window, and when the window is not selected, must be in the window. */ if (!NILP (selected_window)) { ow = XWINDOW (selected_window); if (! NILP (ow->buffer)) set_marker_both (ow->pointm, ow->buffer, BUF_PT (XBUFFER (ow->buffer)), BUF_PT_BYTE (XBUFFER (ow->buffer))); } I suppose "current buffer" means the buffer displayed in the currently selected window which is not the window we are going to select. Why the heck do we care about storing `point' into that window's `window-point'? ------------------------------------------------------------------------ XBUFFER (w->buffer)->last_selected_window = window; IMHO it's a bug to not set last_selected_window when the selected window did not change but the buffer displayed in it did change. It means that when we remove the buffer from the window and display it in that window again Emacs will not go to the previous `window-point' but to `point'. ------------------------------------------------------------------------ /* Go to the point recorded in the window. This is important when the buffer is in more than one window. It also matters when redisplay_window has altered point after scrolling, because it makes the change only in the window. */ { register int new_point = marker_position (w->pointm); if (new_point < BEGV) SET_PT (BEGV); else if (new_point > ZV) SET_PT (ZV); else SET_PT (new_point); } It sets `point' to `window-point'. If the selected window didn't change but the buffer did, the buffer's `point' is not changed. Obviously, command_loop_1 will fix this eventually but any code running after the call of `select-window' will have `point' positioned as whether the selected window changed or not. ------------------------------------------------------------------------ Neither of these seems to have bothered anyone so far. But the problem Juri brought up wasn't noticed either - till now. martin