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: Sun, 06 Feb 2022 18:15:38 +0200 Message-ID: <8335kwynrp.fsf@gnu.org> References: <87ilwd7zaq.fsf.ref@yahoo.com> <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> <83mtlaurxj.fsf@gnu.org> <87fsqh9o7s.fsf@yahoo.com> <878ruoqx0u.fsf@yahoo.com> <83h79cz0sm.fsf@gnu.org> <87leyonrp4.fsf@yahoo.com> <83fsowyzt9.fsf@gnu.org> <87pmo0mbig.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31628"; 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 Sun Feb 06 17:18:25 2022 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 1nGkF7-00082c-6i for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Feb 2022 17:18:25 +0100 Original-Received: from localhost ([::1]:32788 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nGkF5-000195-E1 for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Feb 2022 11:18:23 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51078) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGkCw-0007z3-LZ for emacs-devel@gnu.org; Sun, 06 Feb 2022 11:16:11 -0500 Original-Received: from [2001:470:142:3::e] (port=59760 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 1nGkCu-0003hG-P1; Sun, 06 Feb 2022 11:16:10 -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=P8bTEtw9oL5tSFLdf4EfaguYRGRrTaVW9mtc1kyGQWs=; b=Wfy695/pdpE9 3Whc2gBzioG7XH+pXTviO8I8cL0sZAnA1wkaWqbr5n/DfFPlrM9zhfQ+Z6facEWr02R+RmPUXBIkx f8Gsmo1yixHs3g4iJozRKty5vH57zUAYnZdIjGi72WZFY3I5e+uWnxcwlyki7psI3O1jX5+JPuUMA VqrL2V0K70JB46+ap6sFNfS3cOLzE2/IfgI4Iwb69UBNWykQ+It2riNn1j1EtS1+a0IkVaIavemLe dkdILuUq35QzUouoa1akSKZGJXrsqFpvdkelJ/FmAaSkLrSQkBGuQfWfUmTzMG+mE/gXT8CQYNM3B sqHasqnUBnMkr7gLEkTk+Q==; Original-Received: from [87.69.77.57] (port=4940 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 1nGkCr-00025X-Kb; Sun, 06 Feb 2022 11:16:07 -0500 In-Reply-To: <87pmo0mbig.fsf@yahoo.com> (message from Po Lu on Sun, 06 Feb 2022 20:21:11 +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:285981 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org > Date: Sun, 06 Feb 2022 20:21:11 +0800 > > Eli Zaretskii writes: > > > Since scrolling is basically implemented in redisplay, I don't think > > this answers my question. > > > > Let's look at this from another aspect: which combinations of values > > of these two variables make sense, and what would be the behavior > > under each one of these reasonable combinations? > > It makes sense to have `scroll-move-point' to t, and > `keep-point-visible' set to nil or t, and `scroll-move-point' set to nil > when `keep-point-visible' is nil. > > The behaviour under the first and combinations would be that scrolling > moves point to fit inside the visible portion of the buffer. With the > third, scrolling will not move the point at all. So we have at most 3 states, and could have a single tri-state variable. And I question the validity of the combination scroll-move-point = nil with keep-point-visible = t. The problem with your implementation is that scroll-move-point = nil disables scrolling in redisplay_window, but scrolling there is used not necessarily as result of scrolling commands, but also when redisplay_window decides that the optimal method of updating a window is to scroll its previous contents. Thus, disabling scrolling on that level will cause confusing results, because users will expect that to affect only scrolling commands: they are unaware that redisplay sometimes scrolls the window for other reasons. > >> >> @@ -5659,8 +5660,9 @@ window_scroll_pixel_based (Lisp_Object window, int n, bool whole, bool noerror) > >> >> w->start_at_line_beg = true; > >> >> wset_update_mode_line (w); > >> >> /* Set force_start so that redisplay_window will run the > >> >> - window-scroll-functions. */ > >> >> - w->force_start = true; > >> >> + window-scroll-functions, unless scroll_move_point is false, > >> >> + in which case forcing the start will cause recentering. */ > >> >> + w->force_start = scroll_move_point; > > > That doesn't really answer my question. I was asking what is the > > semantics of setting the window-start, but not the force_start flag? > > What is expected from redisplay in this case? should it obey > > window-start? > > It's expected that it will obey window-start (unless some text changed > before it, in which case it will recenter around the first change > position.) For that, you must set the force_start flag. If you don't set it, redisplay cannot know whether the value of w->start is just the result of the previous redisplay cycle or was set by some user command which wants to scroll the window. Perhaps you want to explore using w->optional_new_start instead? > > No, I mean don't we want to force point to move to the locus of these > > changes? I thought other applications did that. > > They provide no way to make changes without point already being at the > locus of the change. (In which case it will be caught either by the `PT > != w->last_point' conditional, and redisplay will recenter around point > as usual, or if point did not move, then it will recenter around the > change, which would be near the point in that case.) > > IOW, there's no way in most other editors to do something like this: > > (save-excursion > (goto-char (point-min)) > (insert "foo")) Maybe so should we, at least as an option.