From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Allowing point to be outside the window? Date: Thu, 09 Dec 2021 08:23:28 +0800 Message-ID: <87mtlad3sv.fsf@yahoo.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26144"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 09 01:24:38 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 1mv7Ej-0006VU-Ps for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 01:24:37 +0100 Original-Received: from localhost ([::1]:47992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mv7Eg-00034A-4l for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Dec 2021 19:24:34 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60648) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mv7Dr-0002PI-QC for emacs-devel@gnu.org; Wed, 08 Dec 2021 19:23:43 -0500 Original-Received: from sonic301-30.consmr.mail.ne1.yahoo.com ([66.163.184.199]:37988) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mv7Dp-0007Tn-K9 for emacs-devel@gnu.org; Wed, 08 Dec 2021 19:23:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639009419; bh=mpuAOu9iISP30KGTcDQoWEWPfdV5SNWuvXVjnTORoFo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=Ug9eOjRW/xSzJVhLskb0j1BF4mZe4pVzmVBnbTTPaj3UkYtA220Bs1lGNYqD/z2XB50vi1Ny66hnXqyeStSMrC+77SyHlwm4tDdqHkjsjwD0yytCVxjOH+q20KwfA2AtlCRZpDq3MHPCmQK+v29F1y4+VmAXx9RHZAL8RRabrL2dsMN6airJ+iXi7i57inK1joaR7sbInJ2qiVKl5kIXXZ5NSr9mdMjvdk66w7F3B142fCj4uRg/GMxB1qo0A4xEVqqL8zuKm9V1VsDHVqkAbek4KmDdDqPMY3cPhz2R9psKz02iAi9hGvRa+0z1hvVr+vn02d0yZnN/TtinuTHKRg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639009419; bh=v7ev7WNH2LZmRYkSBslL4kxSExz58poJf0vbsqdu3zn=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=s6Gy1IogrEdILm9dvSP2Q8kNRhxnWELpUyrt6zt0z6damGPunyzLASUamUvzn0wdJOTD7B8XxgKFznrc7HK1N2y+cMQyFwHHRyftiz3rwXD8aR/9y3UeivDlk4BWQ22blAsWjbs/t/1UDbAjsOAZakQAh++yeJNuDukZy40jekwvpva2OgfSvBCRfbYEnymA1ZFBB6WlICIP2kCtDwy90LZBw0rKPd7BPwp8jbI3XbpZOd3nDEb/FgXR9MKzoaY+XT4GHF05DdGvvPSUfzs2+xEP4pdcMkSNqeHmjO8jC5/FreQhH+Xhj75QT8bi50E6vODKQOD9Je5U01DwfH6Eog== X-YMail-OSG: 538ro2gVM1k3sggwXMsPKB0anHr.b6WwZGXOoi6_KD_RyHkJ6_2SOGHnvNNP3PW .OanyqcbZZtwu7MTHhFZQhi1ThWfW_XKhr8mVc9DanztRI2Aw7aC1s8D_kKHBsL2buB0C3fagSKH XhSp5zVO6XkMz8nY7vdPiKe9U6Eqc..p.Nf10NdbM1IDLjA8IXDc6bcn5WrH3_1WGokjniH4bdaT DRu2o.zo6Lo5ouNT9._wr4m8RDSAiMEWTDaFnQNkyPgJ1AK23HR1f3KvNfA8qH0qQzpCM3EHrReO o.69PaXvcROVhcQ5kQlYuEW8VMQMhyOkhgpYNVhh89Bu3mcBb4YcVRExeKMFo0RslD50G5ig.WCT c0ijdaCI1599vYCClepoxNUCQHw3wJHBrLMHUnKnp.V716wVGyPqDvhY_uAQCMtj5tyrxoxV5IZa HOo84bCC6hNKuEkRxNqsK0_N_win5JDgETyCX1rUlrDJakHaMteYnyT39PgQFDjZtW1ke_H.iX0C e8IYt9gfwVXCLW4i1Iukun.a3HTeFSPpdpRmfZJswj.Qnt924pMXuu6utMesTipRyuAzNxZ7wUT_ ebq7C5M7lZZZG9gW57oELl2qKrx9dDJn3eyDQhQICyLR2Z8MfmlAyz09hYpjUE50Hq7a1gll.XdF tDxzWkGv1iqyML95WfUqGrtJLCADcxMxSeA6L6wHrCZvfoLtfoNA.XkNzE3Q5S4FO.c7orBfJ_.1 WGCC0OXPml.QjHh1d84OymTt7iIi8Oa1IV4h8s4asz.W_Rc7WSZgosDB8cf8XaWgGr43GO120Zp4 wPjme_OE8uYLBHNJGC_XUgcqY43fWblGwSeAoL4bCL X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Thu, 9 Dec 2021 00:23:39 +0000 Original-Received: by kubenode517.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID dd35cb917df966f9304045f5aea13213; Thu, 09 Dec 2021 00:23:32 +0000 (UTC) In-Reply-To: <83czm7vx0s.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 Dec 2021 19:14:59 +0200") X-Mailer: WebService/1.1.19415 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.184.199; envelope-from=luangruo@yahoo.com; helo=sonic301-30.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:281410 Archived-At: Eli Zaretskii writes: >> 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. > 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. But maybe we should make it move point back into the window under this situation. WDYT?