From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jay Kamat Newsgroups: gmane.emacs.bugs Subject: bug#29111: 26.0.90; Erc keep-place module broken with new default of switch-to-buffer-preserve-window-point Date: Sat, 18 Nov 2017 16:57:01 -0500 Message-ID: <87po8fqmhe.fsf@gmail.com> References: <87inetcppp.fsf@gmail.com> <59FAEA9C.1050608@gmx.at> <877ev7zz3e.fsf@gmail.com> <59FC21B8.5030508@gmx.at> <87zi83xij9.fsf@gmail.com> <59FD7C27.7090803@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: blaine.gmane.org 1511042299 20076 195.159.176.226 (18 Nov 2017 21:58:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 18 Nov 2017 21:58:19 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) Cc: 29111@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 18 22:58: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 1eGB7m-0004Pb-Cr for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Nov 2017 22:58:06 +0100 Original-Received: from localhost ([::1]:51217 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGB7r-0003T3-Pt for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Nov 2017 16:58:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGB7l-0003Sx-MG for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 16:58:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGB7i-00029N-GY for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 16:58:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37903) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eGB7i-00029J-9b for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 16:58:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eGB7h-0003aX-Vi for bug-gnu-emacs@gnu.org; Sat, 18 Nov 2017 16:58:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jay Kamat Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Nov 2017 21:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29111-submit@debbugs.gnu.org id=B29111.151104223113732 (code B ref 29111); Sat, 18 Nov 2017 21:58:01 +0000 Original-Received: (at 29111) by debbugs.gnu.org; 18 Nov 2017 21:57:11 +0000 Original-Received: from localhost ([127.0.0.1]:46584 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGB6t-0003ZQ-AI for submit@debbugs.gnu.org; Sat, 18 Nov 2017 16:57:11 -0500 Original-Received: from mail-yb0-f180.google.com ([209.85.213.180]:43878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGB6r-0003ZD-A7 for 29111@debbugs.gnu.org; Sat, 18 Nov 2017 16:57:09 -0500 Original-Received: by mail-yb0-f180.google.com with SMTP id s65so1721515ybb.10 for <29111@debbugs.gnu.org>; Sat, 18 Nov 2017 13:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=aeOj6X8bS60By0TLJGUbhnQ/Rwjt2eKUqSMpyw2ZsA8=; b=mqICMqjQCGjTAs5B6AtxMYeZqQZR0YabQPTPn3yQWoEv4aAuoXS2E7OkuJhDhIXgvW SdANvklXsaB1GHO3qk5YnKZ5ALUdssiRfhJikhQPqbwkKkf+1lv9b4m5w2jlnSQ8OJni ODonzxTqlC7lKMtRv01IWouEw4eAuwh/T9iqgS8g5XJMoGOMnIkHPx80tfIKpUgtFCgJ fACtdlZV0Ns41r9esSeNLZrM6L5hjjPD2VB2Nm059xWF44HuGaE7HCBynbTmjCr1guw2 a1qe5AAKZZIEipcpT6VQjqjqWTl5HFgie/WB7SYCnmKaebcN5Kt4n/Yji9pDlzlkU+Bh M1Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=aeOj6X8bS60By0TLJGUbhnQ/Rwjt2eKUqSMpyw2ZsA8=; b=mV6kCb83OvVng5epg62TdI8GQayV0rIMkl5kQ4zuz8p0E+lB21hxisTJWHUGHLSf48 WGiNqh0I9CLptWXkFmtHnhSbQ+jx+Jl8iqC7I4Nv9+T3RU0vGqGJ+hUQTkmVNFgvSLFp tbFLER1Vk/QKhkjnmH7PlarYcdy6Bl75nQGTNgBKnN0sscX/AaIxRpmR9/zuWqNLf/Ol I1ad+D31S5jDOsmU6HK31TE5mVFS32t5Kl/vqivqNyBgNe3gxDXVshE9BbaZKlbvLGMz zd5mvQhfmCiBBrblG2xJj0/G8gdEfYD0GM450wNkWpoJkv5heyiWxzXe5EhCvaa/3DKV qOGw== X-Gm-Message-State: AJaThX45eMDXGzrLzFJpNZpWpPu/l7NxmrNhhydNpZ4OfhTvZIjVXjZP DrKPLem4cKr8I9TOeqrYXdHKTX3v X-Google-Smtp-Source: AGs4zMZG095oNGf9UysvvRaWq+OBIMp568BWk+3CnS6i3z/G3YiaPAtinz7fZ7c2uPCBn9IIqZvCRg== X-Received: by 10.37.219.209 with SMTP id g200mr5483478ybf.508.1511042223371; Sat, 18 Nov 2017 13:57:03 -0800 (PST) Original-Received: from laythe ([2610:148:1f00:3000:193b:be3d:8015:34ac]) by smtp.gmail.com with ESMTPSA id c190sm3012230ywd.39.2017.11.18.13.57.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 18 Nov 2017 13:57:02 -0800 (PST) In-Reply-To: <59FD7C27.7090803@gmx.at> (martin rudalics's message of "Sat, 04 Nov 2017 09:36:55 +0100") 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:140067 Archived-At: --=-=-= Content-Type: text/plain Hi, Sorry for the delay, I've been a bit busy for the last couple of weeks. The code that Martin provided worked perfectly, and solves the issue! I removed a few unneeded lines (`window-next-buffers' need not be modified, as it is not used when setting point) and wrapped it so it only runs when `switch-to-buffer-preserve-window-point' is set, and created a patch, which is attached. Let me know if you think another approach is better or if there are other issues with the patch that I can help resolve. Thanks, -Jay --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Fix-erc-keep-place-module-with-new-defaults-bug-2911.patch >From 1ccb3110be45a9492a53bc149ff7f824dc132479 Mon Sep 17 00:00:00 2001 From: Jay Kamat Date: Sat, 18 Nov 2017 16:41:34 -0500 Subject: [PATCH] Fix erc keep-place module with new defaults (bug#29111) Allows erc keep-place to continue working with switch-to-buffer-preserve-window-point set to t, the new default. --- lisp/erc/erc-goodies.el | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/lisp/erc/erc-goodies.el b/lisp/erc/erc-goodies.el index a655d48a6a..8906da1e47 100644 --- a/lisp/erc/erc-goodies.el +++ b/lisp/erc/erc-goodies.el @@ -147,7 +147,19 @@ erc-keep-place (>= (point) erc-insert-marker)) (deactivate-mark) (goto-char (erc-beg-of-input-line)) - (forward-line -1))) + (forward-line -1) + ;; if `switch-to-buffer-preserve-window-point' is set, + ;; we cannot rely on point being saved, and must commit + ;; it to window-prev-buffers. + (when switch-to-buffer-preserve-window-point + (dolist (frame (frame-list)) + (walk-window-tree + (lambda (window) + (let ((prev (assq (current-buffer) + (window-prev-buffers window)))) + (when prev + (setf (nth 2 prev) (point-marker))))) + frame nil 'nominibuf))))) ;;; Distinguish non-commands (defvar erc-noncommands-list '(erc-cmd-ME -- 2.11.0 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable martin rudalics writes: >> Keep place adds a hook so that, when a new message comes in on a >> non-visible buffer *and* point is at the bottom, point is moved up by >> one line. Doing this means that point stays on the last 'read' >> message. Here's the relevant code from keep-place: >> >>> (defun erc-keep-place (ignored) >>> "Move point away from the last line in a non-selected ERC buffer." >>> (when (and (not (eq (window-buffer (selected-window)) >>> (current-buffer))) >>> (>=3D (point) erc-insert-marker)) >>> (deactivate-mark) >>> (goto-char (erc-beg-of-input-line)) >>> (forward-line -1))) > > You could try to pretend that the position at which the buffer was > previously shown in a window is the position calculated here. Add after > the > > (forward-line -1) > > something like > > ;; For all non-minibuffer windows on all frames check whether the > ;; current buffer was shown in that window before. If so, update the > ;; window point positions stored for the buffer to the position we just > ;; calculated. > (dolist (frame (frame-list)) > (walk-window-tree > (lambda (window) > (let ((prev (assq (current-buffer) (window-prev-buffers window))) > (next (assq (current-buffer) (window-next-buffers window)))) > (when prev > (setf (nth 2 prev) (point-marker))) > (when next > (setf (nth 2 next) (point-marker))))) > frame nil 'nominibuf)) > > Completely _untested_ so you may have to tweak it appropriately! > >> Previously, this worked fine, since moving point on non-visible buffers >> meant the movement persisted till the buffer was next 'shown'. However, >> the new default of `switch-to-buffer-preserve-window-point' ensures that >> point stays wherever it was 'last seen'. I'm not sure how it does it, >> but I think it's saving point when a buffer is hidden and restoring it >> when it's seen again >> >>> (when (and entry >>> (or (eq switch-to-buffer-preserve-window-point t) >>> displayed)) >>> ;; Try to restore start and point of buffer in the selected >>> ;; window (Bug#4041). >>> (set-window-start (selected-window) (nth 1 entry) t) >>> (set-window-point nil (nth 2 entry))) > > Right. So with the hack above you would set (nth 2 entry) to the value > keep-place calculated. > >>> That's a possibility, but it would be too radical to go into 26.1, so >>> I think we should explore the less drastic alternatives first. >> >> I agree with Eli that this is too big of a change at this point, but I >> think this is the best long term solution. Perhaps we could >> `make-variable-buffer-local' on `switch-to-buffer-preserve-window-point' >> when enabling keep-place (later, of course). > > I can't yet assess all implications of such a solution so I'd certainly > defer it until all other measures have been exhausted. > >>> Since =E2=80=98keep-place=E2=80=99 is some sort of a minor mode, enabli= ng it should warn >>> the user about the =E2=80=98switch-to-buffer-preserve-window-point=E2= =80=99 >>> incompatibility. But I'm not familiar with =E2=80=98define-erc-module= =E2=80=99 so we'd >>> probably need someone knowledgeable to do that. >> >> I think this is probably the best idea before the emacs 26 release. The >> definition of 'keep-place' is currently >> >>> (define-erc-module keep-place nil >>> "Leave point above un-viewed text in other channels." >>> ((add-hook 'erc-insert-pre-hook 'erc-keep-place)) >>> ((remove-hook 'erc-insert-pre-hook 'erc-keep-place))) >> >> I think we should be able to simply do something like >> >>> (define-erc-module keep-place nil >>> "Leave point above un-viewed text in other channels." >>> ((add-hook 'erc-insert-pre-hook 'erc-keep-place) >>> ;; poor name, but just an example >>> (erc-check-if-switch-to-buffer-preserve-and-warn)) >>> ((remove-hook 'erc-insert-pre-hook 'erc-keep-place))) >> >> I would be happy to submit a patch for this, if the Erc maintainer is >> busy. Does this seem like a good solution, or does anyone see a better >> way around this? > > If all else fails let's do that. First please try the proposal above. > > martin --=-=-=--