From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steve Yegge Newsgroups: gmane.emacs.bugs Subject: bug#4041: 23.0.92; Emacs 23: buffer point is no longer frame-local Date: Tue, 11 Oct 2011 17:35:25 -0700 Message-ID: References: <20090805001735.1CC041E844E@localhost> <4E745DAE.5040808@gmx.at> <4E8EA522.9090300@gmx.at> <4E8F3040.1060409@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0cd58e6c3a630504af0f33dc X-Trace: dough.gmane.org 1318379756 15945 80.91.229.12 (12 Oct 2011 00:35:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 12 Oct 2011 00:35:56 +0000 (UTC) Cc: Lars Magne Ingebrigtsen , 4041@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 12 02:35:49 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RDmnU-00089q-2Y for geb-bug-gnu-emacs@m.gmane.org; Wed, 12 Oct 2011 02:35:48 +0200 Original-Received: from localhost ([::1]:36582 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDmnT-0006Tt-0F for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Oct 2011 20:35:47 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDmnP-0006Tb-OO for bug-gnu-emacs@gnu.org; Tue, 11 Oct 2011 20:35:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDmnO-0001kW-Kr for bug-gnu-emacs@gnu.org; Tue, 11 Oct 2011 20:35:43 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60059) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDmnO-0001kQ-Cx for bug-gnu-emacs@gnu.org; Tue, 11 Oct 2011 20:35:42 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RDmnh-0005je-Ks for bug-gnu-emacs@gnu.org; Tue, 11 Oct 2011 20:36:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Steve Yegge Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Oct 2011 00:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 4041 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 4041-submit@debbugs.gnu.org id=B4041.131837975722035 (code B ref 4041); Wed, 12 Oct 2011 00:36:01 +0000 Original-Received: (at 4041) by debbugs.gnu.org; 12 Oct 2011 00:35:57 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RDmnc-0005jM-AT for submit@debbugs.gnu.org; Tue, 11 Oct 2011 20:35:56 -0400 Original-Received: from smtp-out.google.com ([216.239.44.51]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RDmnZ-0005j1-Ez for 4041@debbugs.gnu.org; Tue, 11 Oct 2011 20:35:54 -0400 Original-Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p9C0ZREE004596 for <4041@debbugs.gnu.org>; Tue, 11 Oct 2011 17:35:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318379728; bh=WwAXFLJqm+kDcHJ6FVF2vAtoUSY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=XIojb+FannusXO3Dxc0EPXaJ6qvAYzTfKSVKsT7gqTcgmWYahB6gHC8mhntVUJRKX zv/Q9HWFQuPru1aNYZHRw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type; b=hXPTKo1f2qf7VxAfIlDEGVDy4hmaDYfmaVRJVpoG3zJiQ97ps1h4EAu1D/8ct1rpX wkdLnVw0oh5qEFu9Wkm/A== Original-Received: from qadb15 (qadb15.prod.google.com [10.224.32.79]) by hpaq11.eem.corp.google.com with ESMTP id p9C0ZQGI025493 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <4041@debbugs.gnu.org>; Tue, 11 Oct 2011 17:35:27 -0700 Original-Received: by qadb15 with SMTP id b15so472545qad.1 for <4041@debbugs.gnu.org>; Tue, 11 Oct 2011 17:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fVvO26ZipfYX1fBAcPZ8C1Q/cjrQ6dP6NYjaH+tzASc=; b=Sdnlzz3tRn+5Bpi4qL+yoUShItLci7gNoSr3rQStz1d72LTYATcWxxBmsrmXFvoHb1 nFoTxw0vzVn5ewr7szpA== Original-Received: by 10.150.73.39 with SMTP id v39mr12520741yba.96.1318379725828; Tue, 11 Oct 2011 17:35:25 -0700 (PDT) Original-Received: by 10.150.73.39 with SMTP id v39mr12520729yba.96.1318379725677; Tue, 11 Oct 2011 17:35:25 -0700 (PDT) Original-Received: by 10.151.43.13 with HTTP; Tue, 11 Oct 2011 17:35:25 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 11 Oct 2011 20:36:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:52554 Archived-At: --000e0cd58e6c3a630504af0f33dc Content-Type: text/plain; charset=ISO-8859-1 I don't know if anyone's expecting me to weigh in, as I've already used way too many words to explain how I think it should work, and none of the intervening discussion has given me a reason to reconsider that position. But I'll add that defending the current behavior of switch-to-buffer is a bit odd, since it doesn't do anything meaningful or useful as-is. In particular, if you are switching to a buffer that is already showing in another window, it currently takes you to to a location in that buffer that can best be described as "arbitrary". I was generously assuming that it was some deterministic function of how the buffer is already being displayed in other windows, but Martin claims that no, it just shows you "somewhere" in the buffer, wherever that window-point happens to be. It's certainly not semantically meaningful to the contents of the buffer. My proposal -- which people sound like they agree with, and Leo has even implemented as an add-on -- takes the default behavior from arbitrary to not only predictable but in fact useful. The only way anyone would even notice that you've changed something is if they were somehow relying on the arbitrary default behavior, but as we've determined that it's not especially predictable, I don't see how anyone could have been relying on it. If we're really worried about it, we can make a compatibility variable. -steve --000e0cd58e6c3a630504af0f33dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't know if anyone's expecting me to weigh in, as I've alre= ady used way too many words to explain how I think it should work, and none= of the intervening discussion has given me a reason to reconsider that pos= ition.

But I'll add that defending the current behavior of swit= ch-to-buffer is a bit odd, since it doesn't do anything meaningful or u= seful as-is.

In particular, if you are switching t= o a buffer that is already showing in another window, it currently takes yo= u to to a location in that buffer that can best be described as "arbit= rary". =A0I was generously assuming that it was some deterministic fun= ction of how the buffer is already being displayed in other windows, but Ma= rtin claims that no, it just shows you "somewhere" in the buffer,= wherever that window-point happens to be. =A0It's certainly not semant= ically meaningful to the contents of the buffer.

My proposal -- which people sound like they agree with,= and Leo has even implemented as an add-on -- takes the default behavior fr= om arbitrary to not only predictable but in fact useful. =A0The only way an= yone would even notice that you've changed something is if they were so= mehow relying on the arbitrary default behavior, but as we've determine= d that it's not especially predictable, I don't see how anyone coul= d have been relying on it. =A0If we're really worried about it, we can = make a compatibility variable.

-steve
--000e0cd58e6c3a630504af0f33dc--