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: Sun, 06 Feb 2022 20:21:11 +0800 Message-ID: <87pmo0mbig.fsf@yahoo.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35105"; 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 Sun Feb 06 13:23:21 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 1nGgZc-0008zN-Hq for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Feb 2022 13:23:20 +0100 Original-Received: from localhost ([::1]:34908 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nGgZa-0003pn-Vs for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Feb 2022 07:23:19 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38856) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGgXj-0002yW-OS for emacs-devel@gnu.org; Sun, 06 Feb 2022 07:21:23 -0500 Original-Received: from sonic317-34.consmr.mail.ne1.yahoo.com ([66.163.184.45]:33247) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nGgXh-00022U-NZ for emacs-devel@gnu.org; Sun, 06 Feb 2022 07:21:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644150080; bh=vASthf+lAlP9ARmpBwU2v1IedQRLnq0bFHsk+FlaNwg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=k2OSDgP93mu0g7AdS1wN4YfsBwEPHZSMSepHCQGUI6+Pk1FJ2AsZOiDR+EW5DnW1o6c96EsCLgt/HXJ4Rvm2MDTo5JF8GynB0CAAKCW3Wz/e5hoJtH5nz9/yz9rWDVS9qASdA6TnxUlzcjLktSXVORCpE5pdPL1QR48SKoj+DgZsQuYY5HMSFiNkM2JO0XkEWy6pb42g7maycElK1AsIUu8oeCdO/rt+kqEbKZ30q0dyxSWQwlK4ZeF0yDWV8OgNfoWDQOnMisyVRohCHi8QHkDpGZVdO70u/qS4a+UuFkw+T1qYPCryqAhp9gerVe1fpnw5kUQOkeTic4gRrHW0iw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644150080; bh=OIOHVocLpYUN5hZ5zkzhGfwD/AM6PN7fMyVpMHzy41C=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=UG5q36bC0JLj+WmlioUftizgoLyX+23plLq22hPeVIJDPsqkv3ZtahO/UINm7aQJ5PXyrth9sGWYUCLvHSKX3cfhJM5Q93bxiLRZt3Tb5Y1LF4zjPhJIaFQC1JuX92Iw5y13sgiq5u/zgANF++DFJQYJEnKIu7QNyNXLZ40u2h/UMGPQ3HHQZO6qX+Cga/BLVtZrt5TTvuhvzDE92aSGJJ2bPIIjGLGQ12dGtA8x3yTKyANl6ZdITEEBJ1Izvab7pgbIpDE4Wllip5gyUNm8PG4AodN73/uBIBNPSCajgsjyjzta2zQzzs1COMiSn0H+12elZyrJ+wOaD/926ydpzg== X-YMail-OSG: DDg4AIoVM1kIxhdc24LD06Dgg494FashDyHewiSYEd6Zchr7BgyXeX2jakuqrbM dXl5VPpAg2IBDcYDQ8VifsKurBFn39gkglZV7hcFTPjW_sOCH8XJELZ6IsE2oy3vjKKNGiawqcxL pB51MMbrRVLhxG1.W_IpIJhnHHaqXpJbXJUs_E8uEcRJ9f2Ai2c1eEKG_64604_LsnFp7Ookamba 5Z0OKiy4R.0.4nkqWCM0GPAx.GRHVhCxthv0.Oqt7qqWGpoMyDPnpF3oNb70tCxc_LRSJ.6clY6z mxTNdJHnlGPsWIAqhXS6AYZdK149XVhtvcwyQXjjm9w4HydnA838VI2ImqTNwRsYfg2OBknAKzl2 IxMWsiVP10yeXdQU2Z.IgLIoXK9Xc_4P9IU5RKYI7AQFREPam.1rrWqR6A9rhn3zI0l2o_jRFf1N 0rPMnuZ.mN0u2QrXTiaJd_sNfAt.sJ8Xh8ieIq6oMJIn3RWpufkhCyO_8D3rs7CS85bX2p9oyHqt 5fm6UnFsGm6lRWmW_JN56IomFlS_7cySwNzsf_nPBEQOq_fcP11NFuuLp9RiPXfvHBidLE9Lnamd Ta9RZBfLfvMPXf7reQOFutZ5e4u0B2vBDc5yRIghmOsowEU5R8ZgCBj1dGhpj4RfE9HunZhIpUOT S_VXGwu5ewA3MWl4VTFwUrdfsXxzK3IvLOVMilbTci9Wjwq6pwqf0l7JXMIJmVSzbFHdHts33CWL 25Sfx59sLMbl7n2qq.DEEVAI_N14jPgHY05ESTW1SYLT3nkN_HL2KaEV9evPiy_2vQrPM2RNI.d1 ejQ9AE66B1WT1w0j26hVmwBGz0JaVlmsJdtGieCGVG X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Sun, 6 Feb 2022 12:21:20 +0000 Original-Received: by kubenode510.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fa7fc1d5a67c0f85eaec3c7576be9cf5; Sun, 06 Feb 2022 12:21:15 +0000 (UTC) In-Reply-To: <83fsowyzt9.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 06 Feb 2022 13:55:30 +0200") X-Mailer: WebService/1.1.19711 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.184.45; envelope-from=luangruo@yahoo.com; helo=sonic317-34.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, T_SCC_BODY_TEXT_LINE=-0.01 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:285969 Archived-At: 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. >> >> @@ -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.) > But you aren't going to do anything that try_window_id does, are you? No, so it's probably safe to remove then. Thanks. > 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"))