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: Wed, 08 Dec 2021 19:14:59 +0200 Message-ID: <83czm7vx0s.fsf@gnu.org> References: <87ilwd7zaq.fsf.ref@yahoo.com> <83zgpowu23.fsf@gnu.org> <87zgpo5tws.fsf@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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24985"; 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 Wed Dec 08 18:18:22 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 1mv0aD-0006ID-Ot for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Dec 2021 18:18:21 +0100 Original-Received: from localhost ([::1]:48552 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mv0aC-0006yI-Mc for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Dec 2021 12:18:20 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:54236) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mv0XH-0004eX-23 for emacs-devel@gnu.org; Wed, 08 Dec 2021 12:15:26 -0500 Original-Received: from [2001:470:142:3::e] (port=38012 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 1mv0XG-0007D0-PB; Wed, 08 Dec 2021 12:15:18 -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=9s0RhDt9hUQrKidEYtQKjIs4DUHXoRQpooEVA9ksDBk=; b=ZB8CuOBlKFoh hRGtbCwF3Hlld11Nh3DZCtIIdKTiGpofjO7qr2egqWYAJfQuamjxVK01E/Cgw5XQzZ93h5y1P3xtt sLk2GtIwIZDudFZrx4VW8ldCWZrNLJs5hknjhvYxi9o3o/bzIrn84gUgQnChx8BRqknBu1Nl9kC/0 SZz6mc41qBK0DqCaOxy66Gr+G14q+5L4Vlf1nv3RH7XnXYiO2FG2QQvbuSuzkXehX0KU+MUpA40zB lrQM+ml6SzW/r7quLhnrK48Or8AngPO5M7lL9Ub0d7lv0lKCbk+3dstsii+kbZJYQXg2JkVH/Cn3y SvACnzkMx4bpqC35fTOqRg==; Original-Received: from [87.69.77.57] (port=4869 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 1mv0XG-0002OX-A5; Wed, 08 Dec 2021 12:15:18 -0500 In-Reply-To: <87mtlbgajq.fsf@yahoo.com> (message from Po Lu on Wed, 08 Dec 2021 09:17:13 +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:281372 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org > Date: Wed, 08 Dec 2021 09:17:13 +0800 > > /* We used to issue a CHECK_MARGINS argument to try_window here, > but this causes scrolling to fail when point begins inside > the scroll margin (bug#148) -- cyd */ > clear_glyph_matrix (w->desired_matrix); > if (!try_window (window, startp, 0)) > { > w->force_start = true; > clear_glyph_matrix (w->desired_matrix); > goto need_larger_matrices; > } > > Why does it have to force start? Because the place for the window-start was given to us (this code is under the 'if (w->force_start)' condition), but we've reset the flag after checking the condition, so now we are putting the flag back, for the next redisplay cycle -- since we are abandoning this cycle. > Doesn't need_larger_matrices take care of resizing the matrix when, > for instance, fonts change? need_larger_matrices indeed resizes the glyph matrices, after aborting the redisplay cycle with the old matrices, but that doesn't mean that window-start is invalid, it just means the previous glyph matrices were not large enough, e.g., because some part of the displayed text now has a different face that uses a smaller font. Basically, the strategy of redisplay_window, after some initial bookkeeping, is to go through a series of steps, whereby if a step succeeds, we are done, otherwise we go to the next step. The steps are: . if nothing's changed except point, and point is still inside the same window, no need to do anything except redisplay the cursor; . try using the window-start that someone else told us to use . try using the same window-start as the previous redisplay, reusing as much of the current glyph matrix as possible . try using the same window-start as the previous redisplay, after correcting it in small ways (like, for example, to move point out of the scroll margin) . recompute the window-start anew using point as the reference . in each case, redisplay the parts of the window using the window-start we found So, as you see, a lot of the processing is dedicated to finding a good window-start point, which is why if someone told us where to put it, we prefer to stick to that. Besides, that someone could be the user via one of the scroll commands, and in that case the window-start we were given is mandatory. > > Yes. I'm saying that if point is allowed to be outside of the window > > during some redisplay cycle, we'd need a different criteria for when > > and how to change w->start. > > Why is that so (for the "how to change w->start" part)? Making point > display in the center of the screen in that case will be intuitive for > most users. 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.