From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Allowing point to be outside the window? Date: Thu, 09 Dec 2021 10:02:32 +0200 Message-ID: <83mtlaurxj.fsf@gnu.org> References: <87ilwd7zaq.fsf.ref@yahoo.com> <83pmqkwi6r.fsf@gnu.org> <87v90c5su6.fsf@yahoo.com> <83o864wg2a.fsf@gnu.org> <87ilwb68ck.fsf@yahoo.com> <83zgpnunfo.fsf@gnu.org> <87fsrf3xmd.fsf@yahoo.com> <83y257ulfp.fsf@gnu.org> <8735ne4e0e.fsf@yahoo.com> <87czmcvcs1.fsf@yahoo.com> <83sfv85y36.fsf@gnu.org> <87v904tsvv.fsf@yahoo.com> <83h7bo5m1x.fsf@gnu.org> <87ilw3ubfp.fsf@yahoo.com> <83h7bn4e55.fsf@gnu.org> <877dcipjmk.fsf@yahoo.com> <83mtld254e.fsf@gnu.org> <87lf0xjgxu.fsf@yahoo.com> <83ilw0zg38.fsf@gnu.org> <87mtlbgajq.fsf@yahoo.com> <83czm7vx0s.fsf@gnu.org> <87mtlad3sv.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33094"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 09 09:03:28 2021 Return-path: Envelope-to: ged-emacs-devel@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 1mvEOl-0008R5-Vh for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 09:03:28 +0100 Original-Received: from localhost ([::1]:60034 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mvEOk-0005Uf-Im for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 03:03:26 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50238) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvEOB-0004pR-20 for emacs-devel@gnu.org; Thu, 09 Dec 2021 03:02:51 -0500 Original-Received: from [2001:470:142:3::e] (port=33672 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 1mvEOA-0002ev-PI; Thu, 09 Dec 2021 03:02:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3lNAXqQU2Z33cbW0nnzGJ5Z6GqgbIl4AoIFcuYToIjo=; b=eykbZk+RYqum f82UB0WLDgfW4KrK7Bi/TSZ5EHmXai7gEZCfMoiaErJGDqgEshmqYwzxJ1MjET3E1Fx41E/A5G+Ks ao6EJUxOAI0qV+6JwWNGJSN8xyOpGMzjD0nf90zaVofKODgxZ/vpSD94dKofgoLhz+OT+ql4JEjRX 0LecZ8+b+bbwVgRcy8fxLBtRnQCdTSxnSnAsHDBncGGJnMLYD2mpvsR2xzzK03R4/dXOq5eY5RQ0j ov+1eQFM4iu81ufxPrPK3nH/9jXE/thmxJprl51YB9IEAtpG33+tHCAsQ7Wb/HSEGgNUB+gWX8Xvc 0RyvLq5X4AC+3duOQecKGA==; Original-Received: from [87.69.77.57] (port=3514 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvEOA-0007qE-GD; Thu, 09 Dec 2021 03:02:50 -0500 In-Reply-To: <87mtlad3sv.fsf@yahoo.com> (message from Po Lu on Thu, 09 Dec 2021 08:23:28 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:281457 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org > Date: Thu, 09 Dec 2021 08:23:28 +0800 > > Eli Zaretskii writes: > > > That's not what I had in mind. What I had in mind was the situation > > where point is outside of the window, and the portion of the buffer > > shown in the window changes due to something that Emacs does. If you > > are saying that in all such situation we will bring point back into > > the window, then my concern is addressed; but if not, we will not be > > able to use the final fallback of recentering the window around point, > > because that would move the window instead of redrawing the visible > > portion of the buffer. > > If point doesn't change, but something in the visible part of the buffer > does, that part will be redrawn, keeping point and window start in their > original locations. I'm saying that if some part of the window needs to be redrawn, "the last line of defense" we have there now, which is to center point in the window, will not necessarily be available, and we need to do something else if all the other methods in redisplay_window fail to find a good window-start point. > But maybe we should make it move point back into the window under this > situation. WDYT? I already provided an example where this could not be what users expect: some command inserts text before the window-start, which causes the text shown in the window to move if we use the same window-start position. Now, window-start is a marker, so theoretically we could use the same marker with the buffer position updated due to the insertion, in which case the stuff displayed in the window may stay unchanged. But is this what users will expect? And if this is not what users expect, i.e. if we will need to recompute window-start anew in that case, we cannot use the "recenter around point" fallback. Likewise with bringing point into the view: will this be what users expect in the described situation?