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 13:55:30 +0200 Message-ID: <83fsowyzt9.fsf@gnu.org> References: <87ilwd7zaq.fsf.ref@yahoo.com> <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> <83mtlaurxj.fsf@gnu.org> <87fsqh9o7s.fsf@yahoo.com> <878ruoqx0u.fsf@yahoo.com> <83h79cz0sm.fsf@gnu.org> <87leyonrp4.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12084"; 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 13:01:16 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 1nGgEF-00032c-WC for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Feb 2022 13:01:16 +0100 Original-Received: from localhost ([::1]:47062 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nGgEE-0007n3-KV for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Feb 2022 07:01:14 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35496) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGg8x-0005Ne-Kk for emacs-devel@gnu.org; Sun, 06 Feb 2022 06:55:47 -0500 Original-Received: from [2001:470:142:3::e] (port=55730 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 1nGg8x-0005mA-Ai; Sun, 06 Feb 2022 06:55:47 -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=HT+Q2q4zlePgtZOdWR41xgk/LozrvcYxvpSVWzco+70=; b=Sq9rZ45DUCBS h+ZKx7qQK7NkbXvqDBtQu1Q/lzg8JG+TKrzZRTJYF8K4h9/odbECpJPOBDi72sQ15gFxjpIBFWg1D sQ9ESDjB5lFu3xdYAOYQFnAa9KDBKhZGYd4zUxgSEYYSqSUGiw2uf/LYiV7LT6bB525e4J8FZVdjR OnBrTYB24kPaaM5JDIFDtfIkmgE/RPHR8MXkG6+cwKuyrChI/hpY1va2d0Vc/JD0SuZTu2bzTzV+4 FuHxlSeL+Dv1UHDSE5nnenVNgMxxGObmJK34ztii++yTkOjh0p2puZmq5EwYkrEBdz60gEzg3mSRX ZFpO6r1emEhXweLFiqsndA==; Original-Received: from [87.69.77.57] (port=4914 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 1nGg8w-0000EJ-R4; Sun, 06 Feb 2022 06:55:47 -0500 In-Reply-To: <87leyonrp4.fsf@yahoo.com> (message from Po Lu on Sun, 06 Feb 2022 19:46:15 +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:285961 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org > Date: Sun, 06 Feb 2022 19:46:15 +0800 > > >> +@vindex keep-point-visible > >> + If @code{keep-point-visible} is nil, redisplay will not move recenter > >> +the display when the window start is changed. > >> + > >> +@vindex scroll-move-point > >> + If @code{scroll-move-point} is nil, scrolling commands will not move > >> +point to keep it inside the visible part of the window. > > > Why do we need 2 flags? Are they indeed orthogonal, or can we have a > > single variable (perhaps with more than 2 states)? > > The first flag controls the behaviour of redisplay, while the second > controls that of the scrolling commands, so I think they are orthogonal. 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? > >> @@ -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; > > > What does it mean when you set the w->start point, but do NOT set the > > w->force_start flag? > > w->force_start will result in point being constrained inside window > start by the code under force_start: in redisplay_window. 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? > >> + /* Make sure beg_unchanged and end_unchanged are up to date. Do it > >> + only if buffer has really changed. The reason is that the gap is > >> + initially at Z for freshly visited files. The code below would > >> + set end_unchanged to 0 in that case. */ > >> + if (GPT - BEG < BEG_UNCHANGED) > >> + BEG_UNCHANGED = GPT - BEG; > >> + if (Z - GPT < END_UNCHANGED) > >> + END_UNCHANGED = Z - GPT; > > > I'm not sure I understand this part. Why do you need to change the > > values of BEG_UNCHANGED and END_UNCHANGED -- those are supposed to be > > changed only by code that modifies the buffer text. > > I saw the code do that in try_window_id, so even though I didn't really > understand it I thought it would be safer to do that here as well. But you aren't going to do anything that try_window_id does, are you? > > You want to display window around the change, but not bring point > > there? Is that a good idea? > > Yes, IMO. If the change is actually at point, then the window will be > recentered around point by the `PT != w->last_point' conditional. > > Otherwise, such surprising changes to point would be unwanted. No, I mean don't we want to force point to move to the locus of these changes? I thought other applications did that. > > Why do we need this maybe_try_window stuff? It seems to repeat > > existing code, doesn't it? > > It does. There was a reason I put it there last December, but I can't > remember it right now. Too bad.