From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Strange behavior editing a file from Dired Date: Fri, 9 Dec 2016 14:32:23 -0800 (PST) Message-ID: References: < <87d1h1tpyq.fsf@linux-m68k.org>> <<6f523b1f-71ab-4147-8d9d-7e7f1cb2b07d@default>> <> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1481322762 16248 195.159.176.226 (9 Dec 2016 22:32:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Dec 2016 22:32:42 +0000 (UTC) Cc: schwab@linux-m68k.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 09 23:32:39 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cFTiX-0003cf-CB for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2016 23:32:37 +0100 Original-Received: from localhost ([::1]:49250 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFTib-0002DG-HB for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2016 17:32:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFTiU-00026K-68 for emacs-devel@gnu.org; Fri, 09 Dec 2016 17:32:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cFTiR-0004K9-1P for emacs-devel@gnu.org; Fri, 09 Dec 2016 17:32:34 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:25414) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cFTiQ-0004Ic-OU; Fri, 09 Dec 2016 17:32:30 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uB9MWPZ8004219 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 Dec 2016 22:32:26 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uB9MWP00020063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 Dec 2016 22:32:25 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uB9MWO1K006188; Fri, 9 Dec 2016 22:32:25 GMT In-Reply-To: <> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:210205 Archived-At: > > My thought exactly. It's a gotcha that I still fall into, > > even though I've been using many frames for a long time. >=20 > > You put the cursor back where it was, and after trying to > > do something that depends on where it was, you see that it > > was moved somewhere else. >=20 > If it depends on multiple frames, it can't be the same bug I > experience, but it might be another bug. If you see it again, > please report it. I think it comes from having different window points when the same buffer is displayed in different windows. I'm not sure that multiple _frames_ need to be involved, but perhaps Andreas has an idea about that. I use different frames, so I can't really tell whether different windows are sufficient. Possibly it's a bug in Dired. What I think I see (sometimes) is that Dired seems to be checking the window point in some other window than the window that is selected when I request the action. It gets the buffer right, but not the window. And by the end of the action it has moved point in the window that was originally selected to the position it has in the other window. I'll try to pay more attention when it happens again and see if I can notice what's involved. In any case, I don't think what I have seen is a new problem. Dunno if it's the same thing you're seeing.