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: Fri, 03 Nov 2017 15:35:06 -0400 Message-ID: <87zi83xij9.fsf@gmail.com> References: <87inetcppp.fsf@gmail.com> <59FAEA9C.1050608@gmx.at> <877ev7zz3e.fsf@gmail.com> <59FC21B8.5030508@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 1509737775 6093 195.159.176.226 (3 Nov 2017 19:36:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 3 Nov 2017 19:36:15 +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 Fri Nov 03 20:36:10 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 1eAhl8-0000rs-BJ for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Nov 2017 20:36:06 +0100 Original-Received: from localhost ([::1]:38190 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAhlF-00045v-Q3 for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Nov 2017 15:36:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAhl9-00045d-US for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2017 15:36:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAhl4-0007mr-Ny for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2017 15:36:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41180) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eAhl4-0007mV-Jj for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2017 15:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eAhl4-0001d4-8z for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2017 15:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jay Kamat Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Nov 2017 19:36:02 +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.15097377166199 (code B ref 29111); Fri, 03 Nov 2017 19:36:02 +0000 Original-Received: (at 29111) by debbugs.gnu.org; 3 Nov 2017 19:35:16 +0000 Original-Received: from localhost ([127.0.0.1]:49861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAhkK-0001bu-7T for submit@debbugs.gnu.org; Fri, 03 Nov 2017 15:35:16 -0400 Original-Received: from mail-yw0-f169.google.com ([209.85.161.169]:54461) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAhkI-0001bh-B6 for 29111@debbugs.gnu.org; Fri, 03 Nov 2017 15:35:14 -0400 Original-Received: by mail-yw0-f169.google.com with SMTP id w5so3293026ywg.11 for <29111@debbugs.gnu.org>; Fri, 03 Nov 2017 12:35:14 -0700 (PDT) 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:content-transfer-encoding; bh=4wAbZnXazAcj/PZEOInMQEuSwl3cV49U3kjV4TBM+Q8=; b=uXBvxf1/lakK35oDOoIQ90hy276224iErDSgWugFuAbyW6SWQvysPiqhsRiQWJ1vq+ wWOoMNaoml62I+ZCtlXE1fGg5yBPWL8mOH872GRkA6DCX+E9VsP5l9Wi038Sug981vUS oHItG/Iwwtr6oGE0kVFdWfokHPtA0DzxdpzpQdHcQsthdKROUPSUPHF9DHIX9GWBHp17 MVXqQrUNmhovbgSyMZm97/D20h1bEX4djDqIs8+55JIfyZmBlpYDvk0dAv9yLILv5LLe i+T9czghdC3waQwUejI7nntMCBxcW2oBsM8OQobXTjL1YSntvoZo0IAzZQ8pZuBjPGDJ rqxg== 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:content-transfer-encoding; bh=4wAbZnXazAcj/PZEOInMQEuSwl3cV49U3kjV4TBM+Q8=; b=mVWOOmLuRIlnmw1zZVsKmWdnwtONb6WHORVbJFo8r7jTspm/b2NLFOf9HP8n9OsF33 DrzKHUBWqeXVHM+Mo0eOx06mzxQ10qhFfKytwcZIR3BnXNTM4WUF4ccWY4y4mzi8PsfP 23iy2S+RGGVytmmnRXlLHMRoq+ojknPHn8Pp/B5Ng/stILejeaB6bVkRFfqlA2xXWYdD Flx1M/dxuuSzhY8Iyi6obhl/3kC54CGnZXR5qKpEeLz3N9ccE+4gybw7yGklX/QefKFf ZoAB8jCJr963nVEhhOz5uRulHnA/o/B5/JuHrttEQ0ecb/8rRdtbTEM/rqe5WNLBEfID 6Q9Q== X-Gm-Message-State: AMCzsaX7spT+j1j0Y0r/KSzAR1n3x+BtsvRfauasjnEY7WhVaYm9F7b8 duP24eU+JD8BOiCI9tffeZB4dH0W X-Google-Smtp-Source: ABhQp+SQrne7WbwjT12GfiVK9heYJHiF9TGNic7NKaqlArBgCSgDtVS40NfbseJNbfxo1gMK95pEgA== X-Received: by 10.37.162.193 with SMTP id c1mr5385800ybn.57.1509737708007; Fri, 03 Nov 2017 12:35:08 -0700 (PDT) Original-Received: from laythe (lawn-128-61-48-114.lawn.gatech.edu. [128.61.48.114]) by smtp.gmail.com with ESMTPSA id a144sm3151668ywh.35.2017.11.03.12.35.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 Nov 2017 12:35:06 -0700 (PDT) In-Reply-To: <59FC21B8.5030508@gmx.at> (martin rudalics's message of "Fri, 03 Nov 2017 08:58:48 +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:139423 Archived-At: Hi, > "keep place" means "preserve point" so it's somewhat surprising that > this is a problem in the first place. Can you explain why and how the > keep place mechanism and the =E2=80=98switch-to-buffer-preserve-window-po= int=E2=80=99 > mechanisms differ? Is =E2=80=98window-point-insertion-type=E2=80=99 invo= lved somehow? I'm not very familiar with emacs internals, so all of this could be wrong, but here's my best shot of explaining why this is a problem. By default, point stays at the bottom of erc buffers as new messages come in. If point is not at the bottom, point stays where it is (so even when new messages come in, point wont move). 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))) 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))) >> Alternatively, we could allow =E2=80=98switch-to-buffer-preserve-window-= point=E2=80=99 >> have a buffer local value which would override the customizable value >> and add a new value, say 'always', which would allow the user to >> override a local 'nil' while the default 't' would have the local 'nil' >> prevail. Maybe we'd then need a 'never' too ... > >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). > Since =E2=80=98keep-place=E2=80=99 is some sort of a minor mode, enabling= 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? Thanks for the responses so far! -Jay