From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Bastian Beischer Newsgroups: gmane.emacs.bugs Subject: bug#28645: Status: 26.0.50; semantic-ia-fast-jump jumps to a random place in buffer Date: Wed, 4 Oct 2017 13:11:13 +0200 Message-ID: References: <873770y3f9.fsf@gmail.com> <59D4A3D5.2030005@gmx.at> 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 1507115563 30774 195.159.176.226 (4 Oct 2017 11:12:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Oct 2017 11:12:43 +0000 (UTC) Cc: bug#28645 <28645@debbugs.gnu.org>, Brief Busters To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 04 13:12:13 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1dzhb3-0006oa-1W for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Oct 2017 13:12:13 +0200 Original-Received: from localhost ([::1]:34412 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzhbA-00082j-8q for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Oct 2017 07:12:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34834) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzhay-000822-FS for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2017 07:12:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzhas-0000G1-LJ for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2017 07:12:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38950) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dzhas-0000FF-Gk for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2017 07:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dzhas-0001EA-8o for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2017 07:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Bastian Beischer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Oct 2017 11:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28645 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28645-submit@debbugs.gnu.org id=B28645.15071154844671 (code B ref 28645); Wed, 04 Oct 2017 11:12:02 +0000 Original-Received: (at 28645) by debbugs.gnu.org; 4 Oct 2017 11:11:24 +0000 Original-Received: from localhost ([127.0.0.1]:47630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzhaE-0001DE-T8 for submit@debbugs.gnu.org; Wed, 04 Oct 2017 07:11:24 -0400 Original-Received: from mail-qt0-f195.google.com ([209.85.216.195]:35549) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzhaC-0001Cx-Bx for 28645@debbugs.gnu.org; Wed, 04 Oct 2017 07:11:21 -0400 Original-Received: by mail-qt0-f195.google.com with SMTP id p15so409852qtp.2 for <28645@debbugs.gnu.org>; Wed, 04 Oct 2017 04:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=43pQoEwMP/sVgVfKPHQDVpOtmAfcNbc+lepzU/fhcEA=; b=PpywK0/W1oKpa1AbAxVxahFEGvDm5KAUg9UFHvlU+LlIpVnhaE7iGz1iRavL7fkPoK isJoOomdvng7082JSal/KVuIDQko/rqpcH/LtQX1XsiuB+V0FB6JbNtSGw6FDBg7V6jf JjSvUs8aDcjQu9tnb/9p2SiGZidf+12AjpWQW5Fd+EBbdOzbhUJIU3TCra51tKW37gCi yrg5u+XO8GtqWKfcfaa/rAhv2F97OUWn30vtryuYY/2N+1WCeUe9xC9CVyhPz1u0sw4K ReOJahb+uC0z2dLs21wZwYgUEqwJbwS7udUEeSuND5rF+8vXbkTU0TQnqhk+MIyyfl2G 0/7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=43pQoEwMP/sVgVfKPHQDVpOtmAfcNbc+lepzU/fhcEA=; b=oVlz03MnHqy+Znj/SNcvGAwoMwPb5IgON3VlJInkSE0G+PLJWr8iDOjOSqGN2s4Yyv z2W0DKgtYVP63WxcwEuqCzlS4aY/PfCBVR//e9lExUdkEYx7cptc6OlwZAfhA5xdmm+Q LJs/vyEahyZgJNjwfM8cxCJvYpekG0ov9Dd4BfPZNp0sTixImQM1loeFPi8bF8M1wp1R hhTBwV1zP31khwOp5daL2BVFDdTrAH3aO7xheU8rQ0tTms0f4qGOjXiQ9Nx0hHx7of3g VtWMst6znOc0VTxj611FQqx0LFb19MwRWAI61ImD2InZdrJfk5YKRI/Jj0wktWPovVl6 bxZA== X-Gm-Message-State: AMCzsaXlQNq0dL3JfkzT3q0wZimawuosRbmkAsM/+sBZeSXRfDi9qrg/ 1DylUkYWavN5QqyfAWGVPoUIz+fYY3veYQg9FVQ= X-Google-Smtp-Source: AOwi7QBeJvs0VENyF+9CzXoNBEh0kb3P3sZ6vfUE2kj6zRwOpDkaigMbVkvMeK8AIfxuH0xqcDnHBLj4LuqEMVRyB6c= X-Received: by 10.37.195.4 with SMTP id t4mr3642158ybf.279.1507115474445; Wed, 04 Oct 2017 04:11:14 -0700 (PDT) Original-Received: by 10.129.99.7 with HTTP; Wed, 4 Oct 2017 04:11:13 -0700 (PDT) In-Reply-To: <59D4A3D5.2030005@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:137895 Archived-At: Hey Martin, On Wed, Oct 4, 2017 at 11:03 AM, martin rudalics wrote: >> I would also be grateful for a little bit of background information. At >> which point did it become necessary to use 'pop-to-buffer' instead of >> 'switch-to-buffer'? Apparently 'semantic-ia-fast-jump' et al worked fine >> in older emacs versions. >> >> When is it ok to use 'switch-to-buffer'? There are numerous occurences >> of it throughout emacs... > > Consider the following scenario: > > (1) =E2=80=98switch-to-buffer-preserve-window-point=E2=80=99 is t (it is = so by default). > > (2) An application explicitly sets point in a buffer that is currently > not displayed in the selected window to a value different from the > value of =E2=80=98window-point=E2=80=99 of that window at the last ti= me this buffer > was displayed there. > > (3) The application wants to switch to the buffer in the selected window > with =E2=80=98window-point=E2=80=99 at the position of point assigned= in (2). > > If the application used =E2=80=98switch-to-buffer=E2=80=99 in (3), then = =E2=80=98window-point=E2=80=99 > will be reset to the old location of =E2=80=98window-point=E2=80=99 which= is obviously > not what the application wants. So to get what it wants, an application > either has to bind =E2=80=98switch-to-buffer-preserve-window-point=E2=80= =99 to nil > around the =E2=80=98switch-to-buffer=E2=80=99 call or use =E2=80=98pop-to= -buffer-same-window=E2=80=99 > (=E2=80=98display-buffer-same-window=E2=80=99 if the window may remain un= selected) > instead. > > IMHO applications should never call =E2=80=98switch-to-buffer=E2=80=99. = They should > either call =E2=80=98pop-to-buffer=E2=80=99 - if the user is supposed to = now continue > working in the window showing the buffer - and =E2=80=98display-buffer=E2= =80=99 in all > other cases. Both allow the user to control how to display the buffer. > > Only if there is a clear preference that the buffer should be shown in > the _selected_ window, the =E2=80=98-same-window=E2=80=99 functions shoul= d be called. > And programmers should be aware that at the time they want to show a > buffer in the selected window, that window might be the minibuffer > window or a window dedicated to some other buffer. I understand. Then this must mean that the change in behavior in CEDET was triggered with this commit: commit ee297210cffb9e8d05912686a39fa158414ba050 Author: Mark Oteiza Date: Thu May 26 21:47:18 2016 -0400 Preserve buffer point in windows by default (Bug#4041). * doc/lispref/windows.texi: Mention new default. * etc/NEWS: Mention new default. * lisp/window.el (switch-to-buffer-preserve-window-point): Default to t. which is part of master and emacs-26 but was not part of any previous relea= ses. I also understand your other arguments. But the question is: While your recommendation makes sense, there clearly still is a lot of code which uses switch-to-buffer without binding switch-to-buffer-preserve-window-point to nil and it wasn't fixed when this variable's default was changed. This is true in lisp code shipped in emacs and it is probably also true for lots of third party code in the wild. Who is going to fix all this code? And if it turns out that the fixing all this code is too difficult / impossible, is it justified to fix bug #4041 at the cost of causing numerous other bugs (which arguably are due to misuse of switch-to-buffer, but they will have to be fixed either way)? > > martin > Cheers and thanks again for your answer. Bastian