From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jose A Ortega Ruiz Newsgroups: gmane.emacs.bugs Subject: bug#53398: 29.0.50; narrow-to-region induces buffer recentering Date: Sat, 22 Jan 2022 19:13:21 +0000 Message-ID: <87czkj8tym.fsf@gnus.jao.io> References: <87tudy9l8y.fsf@gnus.jao.io> <87fsphv1t7.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31919"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53398@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 22 20:23:09 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 1nBLye-0008C6-UH for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Jan 2022 20:23:09 +0100 Original-Received: from localhost ([::1]:52950 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nBLyd-00072S-Uc for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Jan 2022 14:23:07 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:42690) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nBLpq-0001I4-Cf for bug-gnu-emacs@gnu.org; Sat, 22 Jan 2022 14:14:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45012) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nBLpq-00079r-2Z for bug-gnu-emacs@gnu.org; Sat, 22 Jan 2022 14:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nBLpp-0003sU-Pw for bug-gnu-emacs@gnu.org; Sat, 22 Jan 2022 14:14:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jose A Ortega Ruiz Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Jan 2022 19:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53398 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 53398-submit@debbugs.gnu.org id=B53398.164287881314863 (code B ref 53398); Sat, 22 Jan 2022 19:14:01 +0000 Original-Received: (at 53398) by debbugs.gnu.org; 22 Jan 2022 19:13:33 +0000 Original-Received: from localhost ([127.0.0.1]:37915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nBLpN-0003rf-7I for submit@debbugs.gnu.org; Sat, 22 Jan 2022 14:13:33 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41886) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nBLpK-0003rR-ND for 53398@debbugs.gnu.org; Sat, 22 Jan 2022 14:13:31 -0500 Original-Received: from [2001:470:142:3::e] (port=56970 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nBLpF-0005ME-1Y; Sat, 22 Jan 2022 14:13:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=X/sg//T9Hyp3zitZ8yxbOtEUcG6pql/b4bgMklztxMs=; b=SN2NFR5apH76ZcotsWG2 l4KlEAacQe03GsTPD7ph7sRof9wcxAACK4B7+ybKy7Xi/2iBtRBkneLTXv67dVoCeDR1w95Y5GQIY 1kFCKW+zMN0cD9Nv31hMQBYucy5qp4nA1EFWZyiu4KtpaZ5NXmpwp5cwYIuArt5iETtBuqijMa0GE VtQWhd1dVNpK7KCklf1HI41ExnSWA88y9pv8R/hMlcjiCc1RFgJ+ljipakpekTPrq6bCHtL+3Ze6X 62YlQqWaEpJb5U8m1aG6Y6Q7SK/rUVUcpTv1winnJvvDQ2g/4pbUGHJR8RJ/6xEFRPrpvgJEBF+mx 5aBUh3oUrJ/ZDg==; Original-Received: from cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net ([92.233.85.247]:50366 helo=rivendell.localdomain) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nBLpE-0003Ql-Of; Sat, 22 Jan 2022 14:13:24 -0500 Original-Received: from localhost (rivendell.localdomain [local]) by rivendell.localdomain (OpenSMTPD) with ESMTPA id dcde4830; Sat, 22 Jan 2022 19:13:21 +0000 (UTC) In-Reply-To: <87fsphv1t7.fsf@gnus.org> X-Attribution: jao X-Clacks-Overhead: GNU Terry Pratchett X-URL: 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" Xref: news.gmane.io gmane.emacs.bugs:224858 Archived-At: On Fri, Jan 21 2022, Lars Ingebrigtsen wrote: > Jose A Ortega Ruiz writes: > >> - start composing a message, e.g. a reply, so that the current window >> shows only a portion of the buffer, and not the signature >> >> - with point somewhere on the lower half of the window, C-c C-z >> (message-kill-to-signature) >> >> - the text from point to signature is deleted alright, but the buffer >> contents is recentered, as if one had invoked recenter /twice/, so >> the window gets scrolled up. previous behaviour was that the window >> wouldn't scroll at all, one would just see the contents of the >> buffer below point change (and show the signature). > > I've tried reproducing this in Emacs 29 with various contents in the > buffer and with various window sizes, but `C-c C-z' doesn't seem to do > any recentring for me. > > Can you create a test recipe, starting from "emacs -Q", that > demonstrates the problem? Yes, i finally managed to create a recipe. It's kind of exotic and involves setting a custom set-message-function that adds properties to the displayed message (!). More concretely, with emacs -Q, eval this code: (defun text-with-right-padding (text) (let* ((len (+ (string-pixel-width text) (string-pixel-width " "))) (padding (propertize "-" 'display `(space :align-to (- (+ right right-margin) (,len)))))) (concat padding text " "))) (defun custom-set-message (msg) (when msg (concat msg (text-with-right-padding (buffer-name))))) (setq set-message-function #'custom-set-message) text-with-right-padding is copied directly from a message in emacs-devel and i don't fully understand it (in particular, i cannot make sense of the parens around (,len)), but it does its intended job: with custom-set-message one sees messages displayed with the current buffer name attached and padded to the right. That triggers the recentering for me. I just create a file with a bunch of lines containing, e.g. --8<---------------cut here---------------start------------->8--- slkdfjsldkfj slkdfjsldkfj slkdfjsldkfj slkdfjsldkfj slkdfjsldkfj slkdfjsldkfj slkdfjsldkfj slkdfjsldkfj ;; ^^ repeat the above a bunch of times so that you don't ;; see the signature part below -- slkdfjsldkfj slkdfjsldkfj slkdfjsldkfj slkdfjsldkfj --8<---------------cut here---------------end--------------->8--- Then load-library message, just move somewhere in the buffer without the signature being visible and M-x message-kill-to-signature. In my real case, i have a set-message-function that adds a varied amount of extra status information aligned to the right. I have a previous version with adds the padding by computing manually the needed width and simply concatenating in the middle with format and width spec, no fancy 'display properties. With that function, the recentering does not happen. Hope this helps! Cheers, jao -- What sane person could live in this world and not be crazy? -Ursula K. Le Guin, author