GNU bug report logs - #57837
29.0.50; fit-window-to-buffer should reposition the buffer

Previous Next

Full log

Message #47 received at 57837 <at> debbugs.gnu.org (full text, mbox):

From: Sam Steingold <sds <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 57837 <at> debbugs.gnu.org
Subject: Re: bug#57837: 29.0.50; fit-window-to-buffer should reposition the
 buffer
Date: Fri, 16 Sep 2022 17:25:18 -0400

> * Gregory Heytings <tertbel <at> urlgvatf.bet> [2022-09-16 19:34:41 +0000]:
>
>>>>> (advice-add 'fit-window-to-buffer :after
>>>>> 	    (lambda () (and (= (count-lines (point-min) (point-max)) (1- (window-height)))
>>>>> 			    (or (< (point) (point-max)) (forward-line -1) t)
>>>>> 			    (set-window-start nil (point-min)))))
>>>>
>>>> Why shouldn't this be the default behavior?
>>>
>>> I think because fit-window-to-buffer isn't supposed to move point, and point
>>> would become invisible if it is not moved.
>>
>> Is that a problem? I mean, is it possible for the point to be invisible?
>
> No, Emacs does its best to ensure that point is always visible.

what does "does its best" mean?
is it possible for Emacs return nil from
(pos-visible-in-window-p (point))

> That's the reason of the scrolling you see: without scrolling (which
> hides the first half of the buffer) point would be invisible.

Both invisible point and point moved before the EOB are, IMO,
preferable over showing a half empty window after C-x w -.

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://www.peaceandtolerance.org/ https://fairforall.org
All extremists should be taken out and shot.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.