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

Previous Next

To reply to this bug, email your comments to 57837 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Sam Steingold <sds <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; fit-window-to-buffer should reposition the buffer
Date: Thu, 15 Sep 2022 13:31:48 -0400

Hi,

When the buffer is smaller than the window, move the point to the end
and do `C-x w -` (fit-window-to-buffer).
The window shrinks, but it is empty - the whole buffer is above.
One has to move the point to the beginning-of-buffer to make the buffer
visible.

I think this is a bug - the window should show the whole buffer; after
all this is the raison d'etre of `fit-window-to-buffer', right?

Basically, after `fit-window-to-buffer' is called, the following should
evaluate to t:

--8<---------------cut here---------------start------------->8---
(and (pos-visible-in-window-p (point-min))
     (pos-visible-in-window-p (point-max)))
--8<---------------cut here---------------end--------------->8---

Thank you.


In GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin21.6.0, NS
 appkit-2113.60 Version 12.5.1 (Build 21G83)) of 2022-09-13 built on
 3c22fb11fdab.ant.amazon.com
Repository revision: 7df898d532f922ea2a7acce4446bc35eec1da38e
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.5.1

Configured using:
 'configure 'LDFLAGS=-fsanitize=address -fno-omit-frame-pointer'
 'CFLAGS=-g -O0 -fsanitize=address -fno-omit-frame-pointer''

Configured features:
ACL GIF GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS
PDUMPER PNG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP ZLIB

Important settings:
  value of $LANG: C
  locale-coding-system: utf-8-unix

Major mode: Help

Minor modes in effect:
  outline-minor-mode: t
  pyvenv-mode: t
  shell-dirtrack-mode: t
  global-edit-server-edit-mode: t
  winner-mode: t
  which-function-mode: t
  url-handler-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  isearch-fold-quotes-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t


-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://camera.org https://www.dhimmitude.org https://fairforall.org
If you need to keep a secret, keep it a secret that you have a secret to keep.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: sds <at> gnu.org
Cc: 57837 <at> debbugs.gnu.org
Subject: Re: bug#57837: 29.0.50;
 fit-window-to-buffer should reposition the buffer
Date: Thu, 15 Sep 2022 21:03:33 +0300

> From: Sam Steingold <sds <at> gnu.org>
> Date: Thu, 15 Sep 2022 13:31:48 -0400
> 
> When the buffer is smaller than the window, move the point to the end
> and do `C-x w -` (fit-window-to-buffer).
> The window shrinks, but it is empty - the whole buffer is above.
> One has to move the point to the beginning-of-buffer to make the buffer
> visible.
> 
> I think this is a bug - the window should show the whole buffer; after
> all this is the raison d'etre of `fit-window-to-buffer', right?

Yes, but by having point at EOB (and assuming the last line ends in a
newline), you've made point be outside of the window's text.  Instead
of moving point to the end, move it to last line of the buffer, and
then "C-x w -" will leave the entire buffer text on display.

So I don't think there's a bug here.

> Basically, after `fit-window-to-buffer' is called, the following should
> evaluate to t:
> 
> --8<---------------cut here---------------start------------->8---
> (and (pos-visible-in-window-p (point-min))
>      (pos-visible-in-window-p (point-max)))
> --8<---------------cut here---------------end--------------->8---

No, because point-max is after the last newline, and thus effectively
one line beyond the window's text.

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

From: Sam Steingold <sds <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57837 <at> debbugs.gnu.org
Subject: Re: bug#57837: 29.0.50; fit-window-to-buffer should reposition the
 buffer
Date: Thu, 15 Sep 2022 14:30:36 -0400

> * Eli Zaretskii <ryvm <at> tah.bet> [2022-09-15 21:03:33 +0300]:
>
>> From: Sam Steingold <sds <at> gnu.org>
>> Date: Thu, 15 Sep 2022 13:31:48 -0400
>> 
>> When the buffer is smaller than the window, move the point to the end
>> and do `C-x w -` (fit-window-to-buffer).
>> The window shrinks, but it is empty - the whole buffer is above.
>> One has to move the point to the beginning-of-buffer to make the buffer
>> visible.
>> 
>> I think this is a bug - the window should show the whole buffer; after
>> all this is the raison d'etre of `fit-window-to-buffer', right?
>
> Yes, but by having point at EOB (and assuming the last line ends in a
> newline), you've made point be outside of the window's text.

Yes, this is a corner case.

> Instead of moving point to the end, move it to last line of the
> buffer, and then "C-x w -" will leave the entire buffer text on
> display.

Indeed, this function mostly works.

>> Basically, after `fit-window-to-buffer' is called, the following should
>> evaluate to t:
>> 
>> --8<---------------cut here---------------start------------->8---
>> (and (pos-visible-in-window-p (point-min))
>>      (pos-visible-in-window-p (point-max)))
>> --8<---------------cut here---------------end--------------->8---
>
> No, because point-max is after the last newline, and thus effectively
> one line beyond the window's text.

As I said, if `fit-window-to-buffer' has a "contract", it's the invariant
above.  Violating it, albeit in a corner case, is, IMO, a bug.

I am not sure how this should be fixed - either by allowing the point to
be outside of the window (if that is possible) or extending the window
by 1 extra line in this corner case - but it _should_ be possible to fix
it.

Thank you.

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://www.peaceandtolerance.org/ https://jihadwatch.org https://camera.org
I haven't lost my mind -- it's backed up on tape somewhere.

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

From: Sam Steingold <sds <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57837 <at> debbugs.gnu.org
Subject: Re: bug#57837: 29.0.50;
 fit-window-to-buffer should reposition the buffer
Date: Thu, 15 Sep 2022 14:55:16 -0400

On Thu, 15 Sept 2022 at 14:30, Sam Steingold <sds <at> gnu.org> wrote:
>
> >> Basically, after `fit-window-to-buffer' is called, the following should
> >> evaluate to t:
> >>
> >> --8<---------------cut here---------------start------------->8---
> >> (and (pos-visible-in-window-p (point-min))
> >>      (pos-visible-in-window-p (point-max)))
> >> --8<---------------cut here---------------end--------------->8---

replacing `poing-min` and `point-max` with beginning-of-text and
end-of-text, of course...

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: sds <at> gnu.org
Cc: 57837 <at> debbugs.gnu.org
Subject: Re: bug#57837: 29.0.50; fit-window-to-buffer should reposition the
 buffer
Date: Thu, 15 Sep 2022 22:00:36 +0300

> From: Sam Steingold <sds <at> gnu.org>
> Cc: 57837 <at> debbugs.gnu.org
> Date: Thu, 15 Sep 2022 14:30:36 -0400
> 
> >> Basically, after `fit-window-to-buffer' is called, the following should
> >> evaluate to t:
> >> 
> >> --8<---------------cut here---------------start------------->8---
> >> (and (pos-visible-in-window-p (point-min))
> >>      (pos-visible-in-window-p (point-max)))
> >> --8<---------------cut here---------------end--------------->8---
> >
> > No, because point-max is after the last newline, and thus effectively
> > one line beyond the window's text.
> 
> As I said, if `fit-window-to-buffer' has a "contract", it's the invariant
> above.  Violating it, albeit in a corner case, is, IMO, a bug.

I think you misunderstand the contract: the function fits the window
to the buffer text, which doesn't include the (imaginary) place beyond
the last character.

When you are are EOB, doesn't "C-x =" say something like

  point=N out of N-1 (EOB)

?  Do you see what I mean by "beyond the last character"?

> I am not sure how this should be fixed

It shouldn't be fixed, because it ain't broken.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sam Steingold <sds <at> gnu.org>
Cc: 57837 <at> debbugs.gnu.org
Subject: Re: bug#57837: 29.0.50;
 fit-window-to-buffer should reposition the buffer
Date: Thu, 15 Sep 2022 22:07:15 +0300

> From: Sam Steingold <sds <at> gnu.org>
> Date: Thu, 15 Sep 2022 14:55:16 -0400
> Cc: 57837 <at> debbugs.gnu.org
> 
> > >> --8<---------------cut here---------------start------------->8---
> > >> (and (pos-visible-in-window-p (point-min))
> > >>      (pos-visible-in-window-p (point-max)))
> > >> --8<---------------cut here---------------end--------------->8---
> 
> replacing `poing-min` and `point-max` with beginning-of-text and
> end-of-text, of course...

What are beginning-of-text and end-of-text?  I don't find such
functions in Emacs.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Sam Steingold <sds <at> gnu.org>
Cc: 57837 <at> debbugs.gnu.org
Subject: Re: bug#57837: 29.0.50; fit-window-to-buffer should reposition the
 buffer
Date: Thu, 15 Sep 2022 19:34:38 +0000

>
> When the buffer is smaller than the window, move the point to the end
> and do `C-x w -` (fit-window-to-buffer).
>
> The window shrinks, but it is empty - the whole buffer is above.
>

Is that with emacs -Q?  With emacs -Q the buffer is recentered after 
fit-window-to-buffer, and half of it (with your example) is visible.  If 
you want to see the whole buffer in that case, you can one of the 
following lines to your init file:

(advice-add 'fit-window-to-buffer :before (lambda () (or (< (point) (point-max)) (previous-line))))

(advice-add 'fit-window-to-buffer :after (lambda () (enlarge-window 1)))

But that still does not guarantee that after fit-window-to-buffer the 
whole buffer will be visible, if you press C-l and repeat 
fit-window-to-buffer only the second half of the buffer is visible.  If 
you want to handle that case as well, you can use this for example:

(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)))))

>
> Basically, after `fit-window-to-buffer' is called, the following should 
> evaluate to t:
>
> (and (pos-visible-in-window-p (point-min))
>     (pos-visible-in-window-p (point-max)))
>

That would only be possible under the condition you mention: "when the 
buffer is smaller than the window".

Message #26 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: Thu, 15 Sep 2022 18:45:15 -0400

> * Gregory Heytings <tertbel <at> urlgvatf.bet> [2022-09-15 19:34:38 +0000]:
>
>>
>> When the buffer is smaller than the window, move the point to the end
>> and do `C-x w -` (fit-window-to-buffer).
>>
>> The window shrinks, but it is empty - the whole buffer is above.
>>
>
> (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)))))

Thank you.

Why shouldn't this be the default behavior?


-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://jihadwatch.org https://fairforall.org https://jij.org https://ffii.org
Don't hit a man when he's down -- kick him; it's easier.

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

From: Sam Steingold <sds <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57837 <at> debbugs.gnu.org
Subject: Re: bug#57837: 29.0.50; fit-window-to-buffer should reposition the
 buffer
Date: Thu, 15 Sep 2022 18:52:30 -0400

> * Eli Zaretskii <ryvm <at> tah.bet> [2022-09-15 22:07:15 +0300]:
>
>> From: Sam Steingold <sds <at> gnu.org>
>> Date: Thu, 15 Sep 2022 14:55:16 -0400
>> Cc: 57837 <at> debbugs.gnu.org
>> 
>> > >> --8<---------------cut here---------------start------------->8---
>> > >> (and (pos-visible-in-window-p (point-min))
>> > >>      (pos-visible-in-window-p (point-max)))
>> > >> --8<---------------cut here---------------end--------------->8---
>> 
>> replacing `poing-min` and `point-max` with beginning-of-text and
>> end-of-text, of course...
>
> What are beginning-of-text and end-of-text?  I don't find such
> functions in Emacs.

I meant something like this:

--8<---------------cut here---------------start------------->8---
(defun beginning-of-text ()
  (save-excursion
    (goto-char (point-min))
    (1- (re-search-forward "[[:graph:]]" nil t))))
--8<---------------cut here---------------end--------------->8---


-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://ij.org/ https://jij.org https://thereligionofpeace.com
What garlic is to food, insanity is to art.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Sam Steingold <sds <at> gnu.org>
Cc: 57837 <at> debbugs.gnu.org
Subject: Re: bug#57837: 29.0.50; fit-window-to-buffer should reposition the
 buffer
Date: Thu, 15 Sep 2022 22:59:57 +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.  The docstring says: 
"Note that even if this function makes WINDOW large enough to show _all_ 
parts of its buffer you might not see the first part when WINDOW was 
scrolled."

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: sds <at> gnu.org
Cc: 57837 <at> debbugs.gnu.org, gregory <at> heytings.org
Subject: Re: bug#57837: 29.0.50;
 fit-window-to-buffer should reposition the buffer
Date: Fri, 16 Sep 2022 08:45:57 +0300

> Cc: 57837 <at> debbugs.gnu.org
> From: Sam Steingold <sds <at> gnu.org>
> Date: Thu, 15 Sep 2022 18:45:15 -0400
> 
> > * Gregory Heytings <tertbel <at> urlgvatf.bet> [2022-09-15 19:34:38 +0000]:
> >
> >>
> >> When the buffer is smaller than the window, move the point to the end
> >> and do `C-x w -` (fit-window-to-buffer).
> >>
> >> The window shrinks, but it is empty - the whole buffer is above.
> >>
> >
> > (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)))))
> 
> Thank you.
> 
> Why shouldn't this be the default behavior?

I thought I explained that it wasn't needed?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: sds <at> gnu.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 08:53:44 +0300

> From: Sam Steingold <sds <at> gnu.org>
> Cc: 57837 <at> debbugs.gnu.org
> Date: Thu, 15 Sep 2022 18:52:30 -0400
> 
> > * Eli Zaretskii <ryvm <at> tah.bet> [2022-09-15 22:07:15 +0300]:
> >
> >> > >> --8<---------------cut here---------------start------------->8---
> >> > >> (and (pos-visible-in-window-p (point-min))
> >> > >>      (pos-visible-in-window-p (point-max)))
> >> > >> --8<---------------cut here---------------end--------------->8---
> >> 
> >> replacing `poing-min` and `point-max` with beginning-of-text and
> >> end-of-text, of course...
> >
> > What are beginning-of-text and end-of-text?  I don't find such
> > functions in Emacs.
> 
> I meant something like this:
> 
> --8<---------------cut here---------------start------------->8---
> (defun beginning-of-text ()
>   (save-excursion
>     (goto-char (point-min))
>     (1- (re-search-forward "[[:graph:]]" nil t))))
> --8<---------------cut here---------------end--------------->8---

Thanks, but your problem wasn't with beginning-of-text, it was with
end-of-text.  And you haven't explained what you consider end-of-text.

Moreover, the assumption that fit-window-to-buffer ignores
non-[:graph:] characters is false.  This function counts everything
that's displayed as some kind of glyph, no matter what kind of
character that is.

What you see in the case you described, when this function is called
with point at EOB, is the normal Emacs display operation: after the
command completes, if point is outside the window, Emacs scrolls the
display to bring point back into view.  The trigger for that scrolling
is the fact that you positioned point at EOB.  So don't.

Message #41 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 14:52:13 -0400

> * Gregory Heytings <tertbel <at> urlgvatf.bet> [2022-09-15 22:59:57 +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?

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://www.memritv.org https://memri.org https://ffii.org https://jij.org
If you want your advice to be appreciated, write it on a $100 bill.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Sam Steingold <sds <at> gnu.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 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.  That's 
the reason of the scrolling you see: without scrolling (which hides the 
first half of the buffer) point would be invisible.

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.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Sam Steingold <sds <at> gnu.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 21:34:01 +0000

>
> is it possible for Emacs return nil from (pos-visible-in-window-p 
> (point))
>

It is not impossible, but if it happens, it's a bug.

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

I get that that's your preference, but I hope you understand that this is 
a corner case, and that what the code does is not a bug.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 57837 <at> debbugs.gnu.org, sds <at> gnu.org
Subject: Re: bug#57837: 29.0.50;
 fit-window-to-buffer should reposition the buffer
Date: Sat, 17 Sep 2022 09:48:43 +0300

> Cc: 57837 <at> debbugs.gnu.org
> Date: Fri, 16 Sep 2022 21:34:01 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> 
> > is it possible for Emacs return nil from (pos-visible-in-window-p 
> > (point))
> 
> It is not impossible, but if it happens, it's a bug.

Actually, it _is_ possible and is not a bug, but only as long as
redisplay didn't happen.  IOW, you can, for example, write a command
that moves point in a way that would make point be outside of the
window, and then pos-visible-in-window-p will return nil for it.  But
as soon as the command finishes, redisplay will scroll the window to
bring point into view.

This is exactly what you see in this case.

> I get that that's your preference, but I hope you understand that this is 
> a corner case, and that what the code does is not a bug.

Right.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57837 <at> debbugs.gnu.org, sds <at> gnu.org
Subject: Re: bug#57837: 29.0.50; fit-window-to-buffer should reposition the
 buffer
Date: Sat, 17 Sep 2022 07:10:30 +0000

>>>>>> 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.
>>>
>>> is it possible for Emacs return nil from (pos-visible-in-window-p 
>>> (point))
>>
>> It is not impossible, but if it happens, it's a bug.
>
> Actually, it _is_ possible and is not a bug, but only as long as 
> redisplay didn't happen.
>

Indeed, I wrote too fast.  What I meant, in the context of the discussion, 
was: It is not impossible after redisplay, but if it happens, it's a bug.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 57837 <at> debbugs.gnu.org, sds <at> gnu.org
Subject: Re: bug#57837: 29.0.50; fit-window-to-buffer should reposition the
 buffer
Date: Sat, 17 Sep 2022 10:25:37 +0300

> Date: Sat, 17 Sep 2022 07:10:30 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: sds <at> gnu.org, 57837 <at> debbugs.gnu.org
> 
> > Actually, it _is_ possible and is not a bug, but only as long as 
> > redisplay didn't happen.
> 
> Indeed, I wrote too fast.  What I meant, in the context of the discussion, 
> was: It is not impossible after redisplay, but if it happens, it's a bug.

Right.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Sam Steingold <sds <at> gnu.org>
Cc: 57837 <at> debbugs.gnu.org
Subject: Re: bug#57837: 29.0.50; fit-window-to-buffer should reposition the
 buffer
Date: Sun, 18 Sep 2022 08:34:09 +0000

>> Both invisible point and point moved before the EOB are, IMO, 
>> preferable over showing a half empty window after C-x w -.
>
> I get that that's your preference, but I hope you understand that this 
> is a corner case, and that what the code does is not a bug.
>

By the way, I forgot to mention that a way to get (almost) the behavior 
you want is to set scroll-conservatively to 101.  With that value, and 
with point at EOB, after fit-window-to-buffer only the first line of the 
buffer will not be visible.

Previous Next

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