From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Laurence Warne Newsgroups: gmane.emacs.bugs Subject: bug#60381: [PATCH] Preserve Window Position with Proced Date: Thu, 29 Dec 2022 12:52:20 +0000 Message-ID: References: <83v8lv8n7u.fsf@gnu.org> <83pmc291xe.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000046d32405f0f6f5d8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37720"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60381@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 29 13:53:23 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pAsPS-0009d2-LL for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 29 Dec 2022 13:53:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pAsPA-0005i8-Oj; Thu, 29 Dec 2022 07:53:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pAsP9-0005he-CA for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2022 07:53:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pAsP8-0000fN-U4 for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2022 07:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pAsP8-0004hP-Bp for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2022 07:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Laurence Warne Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Dec 2022 12:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60381 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 60381-submit@debbugs.gnu.org id=B60381.167231835918032 (code B ref 60381); Thu, 29 Dec 2022 12:53:02 +0000 Original-Received: (at 60381) by debbugs.gnu.org; 29 Dec 2022 12:52:39 +0000 Original-Received: from localhost ([127.0.0.1]:59448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pAsOl-0004gm-De for submit@debbugs.gnu.org; Thu, 29 Dec 2022 07:52:39 -0500 Original-Received: from mail-vk1-f178.google.com ([209.85.221.178]:44725) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pAsOi-0004gZ-S3 for 60381@debbugs.gnu.org; Thu, 29 Dec 2022 07:52:37 -0500 Original-Received: by mail-vk1-f178.google.com with SMTP id w26so310386vkm.11 for <60381@debbugs.gnu.org>; Thu, 29 Dec 2022 04:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=c3UXaJJk2c7ln44JRQixtA9djmHSt/8rSmY2Dg5Q6Is=; b=QQRoP7ijAzZDIfZXNzLPFDaQzUt1nh/RY2sEuXv4whtDZUSjWjnFtAMkqHkrsv8tdf fYiTNvJmBXCXsJ39uDoWOzEIFM2mjHwaY2tkTEZ3lNj49soxhMVa/ozrMmKK7DD2zhVx jPQ+j0meToElpOq6/EcwCaAc2xJ8gUVUrcLp96jQRph4HV25PPgIkCiFGhfMcpqQC/Tk wfW3eo7eIdzu+kE6xu3e21H404siG3stJ1iCFGuYtDqCSf5gobTCK0z+JynAAaCT1uXP yCALepr6zkvUUMUgcgADHDVbrCVrc83tXgoJa27d0HUzQIWW78FFYHBb6H5VzSOET4+D EKug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=c3UXaJJk2c7ln44JRQixtA9djmHSt/8rSmY2Dg5Q6Is=; b=AE2d3Ss5FxUzu3RPaQW69hdJL8JqklhbGFT3hwCL1FmqCLsG7hp9+dBpnJR9BiQw0i fW22pqusWa9iQQWgf1/efl6WLXLptPIej6kV3/O8kdaGPBLGO28m9+d5GV3LhZIcOAKr sPDZBtrT02kccO86BDYlW3ywgdoLzoMg2Bs5CpEjjt5HQPTFpw0BwQdRvqO0UfxPqSgW CT4eU/9oER1iFqZ5a3hDZO8BioQaSMu5qOtnFmqu78UIjXmO1dglJPl50YsoCnlyatEF KKS4hVQ6DLxOAPzjrnxSwwRtSE4k8QIeoRc2hpstw4BRzzVZxSlnJ6T/tQ/65zz8832R waBA== X-Gm-Message-State: AFqh2kqhSactIheGcanjUpMzOWizNbEyDLnKh4LEmxEngw6/Hf1lO60n 5xa5VRr9iB7CvsrBOP8IksXxOZ/SBb1rZ3tyEQfvo8x3cy4= X-Google-Smtp-Source: AMrXdXuGgaPrCI+snai9aYFWZ1Z5NpE/P/q3yhnobyPTj+WH1m2v/ixZVsIht5WoTtbx90ecHAXaMlU1DvarOdm9l1Q= X-Received: by 2002:a1f:9054:0:b0:3d5:77ce:27a4 with SMTP id s81-20020a1f9054000000b003d577ce27a4mr956297vkd.26.1672318351232; Thu, 29 Dec 2022 04:52:31 -0800 (PST) In-Reply-To: <83pmc291xe.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:252033 Archived-At: --00000000000046d32405f0f6f5d8 Content-Type: text/plain; charset="UTF-8" I've logged the buffer and window point at certain lines (most important is before/after erase-buffer on line 1911) in a few run throughs of proced-update, first when the selected window displays a proced buffer: before update: window point: 20121, buffer point: 20121 after goto-char min: window point: 1, buffer point: 1 before erase buffer: window point: 1, buffer point: 1 after erase buffer: window point: 1, buffer point: 1 after update: window point: 20121, buffer point: 20121 So this is expected since buffer point always mirrors window point for the selected window's displayed buffer. Next, when the selected window doesn't display a proced buffer, but there does exist a window displaying a proced buffer (the window point logged corresponds to the window point of the window containing the proced buffer): before update: window point: 20235, buffer point: 20235 after goto-char min: window point: 20235, buffer point: 1 before erase buffer: window point: 20235, buffer point: 1 after erase buffer: window point: 1, buffer point: 1 after update: window point: 1, buffer point: 20235 So my understanding is since the selected window does not display a proced buffer, the window point is not updated in line with the buffer point, but the erase-buffer call sets the window point to start of the buffer, and so this is not updated in line with the buffer point in the subsequent insertion of processes. The last case (the second issue) where no window shows a proced buffer is similar to the previous, but erase buffer instead appears to set pos for the proced buffer's value in (window-prev-buffers) if it's the case a window has shown a proced buffer previously. --00000000000046d32405f0f6f5d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've logged the buffer and window point at certai= n lines (most important is before/after erase-buffer on line 1911) in a few= run throughs of proced-update, first when the selected window displays a p= roced buffer:

before update: window point: 20121, = buffer point: 20121
after goto-char min: window point: 1, buffer point: = 1
before erase buffer: window point: 1, buffer point: 1
after erase b= uffer: window point: 1, buffer point: 1
after update: window point: 2012= 1, buffer point: 20121

So this is expected since b= uffer point always mirrors window point for the selected window's displ= ayed buffer.=C2=A0 Next, when the selected window doesn't display a pro= ced buffer, but there does exist a window displaying a proced buffer (the w= indow point logged corresponds to the window point of the window containing= the proced buffer):

before update: window point: = 20235, buffer point: 20235
after goto-char min: window point: 20235, buf= fer point: 1
before erase buffer: window point: 20235, buffer point: 1after erase buffer: window point: 1, buffer point: 1
after update: win= dow point: 1, buffer point: 20235

So my understand= ing is since the selected window does not display a proced buffer, the wind= ow point is not updated in line with the buffer point, but the erase-buffer= call sets the window point to start of the buffer, and so this is not upda= ted in line with the buffer point in the subsequent insertion of processes.=

The last case (the second issue) where no window = shows a proced buffer is similar to the previous, but erase buffer instead = appears to set pos for the proced buffer's value in (window-prev-buffer= s) if it's the case a window has shown a proced buffer previously.
<= /div>
--00000000000046d32405f0f6f5d8--